eBox package dependency list

[Saturn2888]

I was hoping I could find a list of each eBox package and the dependencies therein such that the DHCP server uses dhcpd3 as the backbone and the DNS server uses bind9. If I can gather all of this information, I'd like to do a usability report with another similar distribution with a completely different audience. I wanna see where the differences lie and then write back to everyone of my findings. Before I can do that though, I need to have someone help me develop a list of what I'd need to download on the other machine. I have configured eBox so many times but I've only one configured this other platform. I even already have two VMs setup already designed for me to emulate the setup of my own two current eBox machines so that I may make a reasonable comparison between the two platforms.

[naelq]

hi,
since eBox is based on Ubuntu (Debian..) you can use the apt-rdepends utility to list the dependencies you want.. but you must install it 1st!

install apt-rdepends

Code: [Select]

#apt-get -V install apt-rdepends
do the magic

Code: [Select]

#apt-rdepends ebox
man page: http://www.debianadmin.com/manpages/aptrdependsmanpage.htm
tutorial: http://www.ubuntugeek.com/how-to-check-package-dependencies-with-apt-rdepends-on-ubuntu.html

[Saturn2888]

Ee! So many, haha, and so useful! I'll take a look at this list for a while.

Since most of these here list the dependencies of each package, wouldn't being able to install apache2 mean all dependencies are validity? Maybe it's best to look at it differently. apt-rdepends is far more robust than I need and goes into tiny details which may not be worth knowing because if the big package doesn't install, it means the smaller one is missing; but I am assuming all dependencies are verified, I just need the package names.

Here's my list of them, tell me if I've missed anything or I'm wrong
- Network (basic OS network functionality)
- Firewall (IP tables)
- DHCP (dhcpd3)
- DNS (bind9)
- IDS ()
- NTP ()
- VPN (OpenVPN)
- Users & Groups (Samba domain controller)
- File Sharing (Samba)
- Web Server (apache2)

[alemartini]

Hi Saturn, I'm not sure that I understand what you're asking, but I guess this could be what you need:

http://trac.ebox-platform.com/wiki/Document/Documentation/Software

There you'll find the complete list of the products used by eBox to implement its features (Samba, OpenLDAP, Dansguardian, Snort, etc.)

Taking that list as a starting point, you could eventually build an "eBox from scratch" on whatever distribution you choose. Would that be possible? Definitely. Would it be easy? I don't think so ;-) Anyway, it would surely be a terrific learning experience.

Don't forget to keep us posted about your findings!

Best regards,
Alex.

[Saturn2888]

That's exactly what I needed! Now I just need to see which of those go along with the modules I have installed. I'm wanting to build eBox functionality into OpenWrt to do some comparisons. I'm really curious because I'm wanting to move to ARM and OpenWrt is able to be easily compiled for ARM. Ubuntu on ARM is still fairly spotty so eBox might not work there, but it's been discussed in the forums before, and I think it's the next step. 5W total power usage? Who wouldn't love that?

First thing I'm doing is seeing if it's possible to mimic eBox in OpenWrt using the x86 build and opkg (like aptitude). I have two eBox machines and both are on hardware that's far too expensive to support. I want to move to x86/x64 Atom server boards like my NAS or the Guruplug Plus which is based on the ARM Marvell Kirkwood chipset.

Since eBox doesn't support 64-bit Ubuntu as far as I know, that means I could easily compare it against OpenWrt which also has a web interface. OpenWrt is designed for SOHO routers, wireless routers, and access points, but that also means it makes great competition for eBox. Since it acts more like a router and basically fits in flash memory, it'll be quick and easy to upgrade and doesn't have the full Ubuntu Server OS behind it. Unlike Ubuntu, it's also designed to be loaded from USB drives or very little on-board flash into very little on-board memory (4MB). From my perspective, the perfect competition is OpenWrt. If the x86 version can mimic eBox, then I'm sure the ARM version can have the same programs working in it. This will save me a lot of time and might make me switch to this implementation if it proves better than eBox for the long term.

Note, eBox is an all-in-one and while you lose some functionality of editing config files and upgrading your OS when you want, it is a pretty sound base of operations for a server/router. It would take a lot to move me off of eBox, but that's why this is the perfect idea.

[alemartini]

Yes... I connected the dots after stumbling upon some of your other posts...  

An eBox clone on ARM... wow... that would be awesome! And that would truly be an "eBox in a (tiny) box"...  

From my perspective, it's a pitty that the development team changed course on the middle of the project and switched from Debian to Ubuntu, which I think was a huge step backward. Had they continued developing on Debian, we would be pretty close to having eBox running on tiny ARM  devices by now. I'm not an expert in that field, but watching Martin Michlmayr's presentation at last year's Debconf blew my mind.

I wish you the best in your endeavour and I think that achieving something like that would be something really useful and remarkable.

[Saturn2888]

Already, OpenWrt in the normal 60MB partition with about 8MB of stuff has everything I need. There are some control features you can add to LuCi, their admin interface, and tons of customization options. One thing it already tops eBox on is DDNS. I've complained a lot, but eBox is lacking a method of contacting a custom DDNS server. My friend hosts my DNS, and I don't want any other company having a hold of that; but my IP address is only static bc my ISP hasn't issued me a new one. The problem is, what if my Internet connection goes out? Then I plugin my RNDIS phone and use it as the WAN-side adapter (kinda easy to do in eBox maybe). Problem is, the public IP changes this way.

I really dislike eBox's Traffic Shaping methodology as if all adapters are somehow permanent and could go offline, but they're not intended to. What I'd like is if all WAN adapters were treated as temporary adapters so I could just plug one in, the traffic shaping takes affect, and everyone's happy. When I unplug that device, traffic shaping returns to just one adapter. If that adapter goes down, I can just as easily plug back in the other device and have good times with it. The one thing that could be a problem is if I plug in my phone (alongside my wired Internet) and want to play games online. I don't want to worry about a 360ping bc eBox is sending some packets through the phone. In those cases, it'd be nice to setup my rig to not send certain traffic or all traffic through both ports. It'd be most convenient if there was a switch for it so I could more-easily choose which WAN device I want when I want it; but that's going into the extra feature area.

OpenWrt supports bridging right out of the box so there's so much more flexibility there for instance if I wanted to have one of my 5 public IPs designated to a single machine or a group of them.

I also noticed OpenWrt's awesome QoS feature. I remember QoS was talked about, but was never integrated into eBox; at least not up to 1.5. OpenWrt's got some obvious issues with Samba. I installed and configured it yet I cannot access it. That right there is proof of things gone wrong.

[Saturn2888]

eBox on ARM is going to be my next challenge. I'm gonna somehow get a hold of Ubuntu Lucid for ARM and run it in Qemu to see what happens. If anyone know where I can get these materials, I'll go ahead and try it.

The whole OpenWrt thing is sadly not going to pan out. I like eBox and am familiar with it. In comparison, OpenWrt uses up at most, 13MB of space to emulate most all of eBox's current functionality. It boots into memory so it would work great off a cheapo 64MB USB drive you have laying around, and will kinda sorta do exactly what you want. Might I mention it's an extremely fast interface that just loads everything instantly.

The problem is, it's not all interconnected, not everything is as easy to use as eBox, and who knows what features it's lacking. It's much easier to maintain and manage though because all you have to do is modify config files if you can't work with the interface instead of having no way of really backing up your eBox configuration in any portable manner. opkg isn't nearly as good or vibrant as aptitute, the repos are lacking some of my favorite CLI programs, and both cpan and cpanplus are heavily broken if I wanted to run perl scripts. That also rules out trying to fudge eBox on OpenWrt instead of Ubuntu, haha.

Personally, I prefer web interfaces that directly work with and manage config files because all of the functionality you could do without the interface you could do with it. There are always some limitations, but I think BackupPC is by far the best at giving you a fully-featured WUI which is basically just the config file in a nice wrapper. If eBox included a SysAdmin interface like that, I think I'd be overjoyed.

I like to play around w/ operating systems as if they were toys. Since OpenWrt doesn't work for me, eBox on ARM might. I'll constantly be looking for ways to lower my power usage whether that means going Atom or going ARM. ARM is going to be more restrictive and harder to configure, but it's surely going to be a lot more fun in the long run and something to brag about. The only way I can think Atom would come in handy is if all my servers became Atom servers (hopefully processors with VT), and I figure out a way to cluster them together, run them in an OS-level VM, and be happy everything is super portable. I mean, eBox in a VM means, if it goes down, just start up another one from an earlier snapshot. Lots of things to try, but OpenWrt is definitely out of the picture now.