yum remove proftpd removes virtualmin-base

Hi,

Just installed the virtualmin vsftpd module (and vsftpd of course) and now I want to get rid of proftpd (only security nightmares because of this one), but yum remove proftpd wants to also wipe out virtualmin-base... Is this intentional?

Status: 
Closed (works as designed)

Comments

Joe's picture
Submitted by Joe on Mon, 02/14/2011 - 00:27 Pro Licensee

It won't hurt anything to leave proftpd installed. Just shut it down, and there can be no security issues from it. ;-)

Yes, it's intentional, though it should probably be made more generic and require an FTP server rather than specifically proftpd. But, only proftpd and vsftpd are supported, so it'd be possible to end up with a system that didn't have a workable FTP server if we just required any FTP server.

I've been considering moving to a non-dependency based installation process, which would never have this issue, but it would also be much easier for people to break their systems. I haven't yet decided which path will generate the fewest confused users (and, more importantly, the fewest broken systems; I tend to think package manager enforced dependencies are more robust than having them installed via a script).

I agree here that the package manager would be the better way to go. Trying to "manually" manage the required packages with scripts will probably turn out to be more of a nightmare than trying to get the package managers to play nice.

If you can configure the PM to accept both/either proftpd and vsftpd you should be fine I think. Like, apt or more specifically aptitude usually suggests alternatives when they are available - like when one package depends on either "this" or "that" but not "both", and I try to uninstall "this", it will suggest to install "that" instead.

Though you always need to carefully examine the actions the package manager is going to do when making changes. That's why I never auto-install updates on my production servers, but only have them inform me about new stuff, which I then first try on a test system. I don't trust the conflict resolution functions of the manager without verification. :)

Joe's picture
Submitted by Joe on Mon, 02/14/2011 - 12:02 Pro Licensee

yum/RPM doesn't have the option to require "this or that"; there is not logical or in dependency checking in RPM, nor is there a recommendation option, as in dpkg. The way dependencies on a type of service (rather than a specific package name) is handled is to have a "Provides: webserver" or something along those lines in the packages that would be depended on. So, Apache and lighttpd and nginx might all have a Provides: like that (I don't know that they do, they just might). I'm pretty sure both proftpd and vsftpd have such a provides line (and if proftpd doesn't, we can add it, as we provide that package in our repos). But, as I mentioned, if any other ftp server has that line, then it would be entirely possible to install or have installed an ftp server that won't work with Virtualmin. (or, at least, one that Virtualmin doesn't know how to configure; any FTP server will "work", as long as it uses normal users and permissions, but it would need to be manually configured by the user if it's not vsftpd or proftpd)

Another option in RPM is to depend on the same command that is provided by two similar packages; so, there are many Java packages out there, and all provide a "/usr/bin/java" binary. So, you could depend on that. But, that's not true of FTP servers, or web servers, or anything we have to work with.

tpnsolutions's picture
Submitted by tpnsolutions on Mon, 02/14/2011 - 12:31

To remove proftpd without issue on CentOS, simply issue:

rpm -e --nodeps proftpd

This should remove just the proftpd package without error or such. I do this on all my servers as we only allow SFTP.

*** the syntax above may be slightly incorrect as I'm not in front of my computer at this time. Consult "man rpm" to confirm. ***

-Peter

Hmm, seems then that apt is making the packaging job for the Virtualmin team way easier than RPM. ;)

Joe's picture
Submitted by Joe on Mon, 02/14/2011 - 12:50 Pro Licensee

Uh oh, you've set Joe off on a rant about package managers...Eric and Jamie have to take a drink now.

apt/dpkg is much harder to work with, actually. apt/dpkg has some really nasty behaviors (like removing all dependencies of virtualmin-base when any dependency is removed, leading to everything Virtualmin-related being uninstalled). This is a failing on my part, at least as much as apt/dpkg, but I still consider it very dangerous and surprising behavior. I find RPM much less surprising to work with, and thus it makes me happier. Now that I know about this behavior, I'll figure out ways to deal with it...but it caught me completely by surprise, and I hate surprising behavior from vital software like package managers. ;-)

This feature of apt/dpkg is the reason we'll be moving the Debian/Ubuntu part of install.sh to doing all the installs separately rather than letting dependency management handle it. There's no other way to do it safely.

The worst case when removing proftpd with RPM is you get a dependency warning, as discussed in this issue. The worst case with apt/dpkg is that it removes every Virtualmin-related package on the system. apt explains what's going to happen...but a number of users have managed to ignore the messages apt prints out about what will be uninstalled and they proceed. I'll choose the former worst-case over the latter any day, because we have to help folks clean up when horrible things like that happen.

While I'm ranting...the documentation for packaging, and especially maintaining apt repositories, for dpkg is horrible. Poorly organized, seriously incomplete, and out of date. It took me at least ten times as long to learn my way around apt repos as it did to setup a yum repo (and I'm still unhappy with the way our apt repos are maintained...). There's huge swaths of documentation out there, it's just an incomprehensible mess.

There's a lot to like about Debian/Ubuntu, but the packaging and repo management process is not one of those things I like. ;-) (But, it's so much better than FreeBSD, Solaris, Gentoo, Mac OS X, and SuSE that I really shouldn't complain. It's clearly the second best package management system available, and everything else is very distantly behind it. The differences between yum/RPM and apt/dpkg are tiny, really. They've just bitten me a lot lately, so I'm feeling very put upon.)

Uh-oh indeed. I had no idea what I started with that. ;)

Anyway, doesn't apt at least have appropriate options to prevent such a "remove all that crap because one dependency is being removed" disaster?

E.g. aptitude has config options to not auto-remove anything, and also apt has the --no-remove switch. Then again, users of course have to actually use those switches and not blindly say "yes" to anything that apt asks...

I personally like the dependencies system, as long as it is properly set up. And as I already pointed out, I never trust the auto-resolve mechanisms of apt but review changes and conflicts and resolutions manually before I apply them. Same goes for updates.

So maybe the installer-script-to-be-soon could get a "user" and an "expert" mode, setting stuff up script-controlled or using dependencies respectively, the former being the default and the latter selected with a switch?

Wow, what a flame I started.

Obviously I ended up doing rpm -e --nodeps proftpd, but since RHEL is providing vsftpd out of the box wouldn't this mean less work for webmin packager? :-) I'm sure vsftpd is also being provided by debian/ubuntu (and anyway I dare to assume centos/rhel install base is significantly larger - it would be interesting to see some 'oficial' stats about this). There's something to think about.

Cheerio

Joe's picture
Submitted by Joe on Mon, 02/14/2011 - 23:02 Pro Licensee

Actually, I would prefer to work with vsftpd. I've always liked it better. (Actually, I don't use FTP, at all, and tend to recommend not using it, but many folks still have non-technical users that learned how to use FTP 20 years ago, and refuse to take the ten minutes it would take to learn something else.) ;-)

But, when we started Virtualmin, ProFTPd was dramatically (like 10 to 1, probably more) preferred over vsftpd by the hosting providers we were working with. It wasn't even close.

Part of that was the additional features of ProFTPd over vsftpd, and it still has more capability. And part of it was familiarity; ProFTPd was the most popular FTP server at the time, by far, so everyone already knew it.

And, at this point I don't think it really matters. The security issues in ProFTPd are long past (seemingly), fewer people are using plain old FTP so hopefully it's dying as a protocol, and folks can install and use vsftpd if they want and shut down ProFTPd. (I still don't see why uninstalling it matters...it's only a a tenth of a penny worth of disk space, if it's not running.)

On this note, I've been tinkering with a Perl rewrite of the install.sh. It would be able to be quite a bit smarter...I'm not sure if I'd want to introduce the complexity of this kind of question, but it would handle things like installing PostgreSQL and other optional stuff.

I'm using an FTP server for the exact same reason you specified. I myself have been ssh only for years. Proftpd security issues aren't far long, you can get root privileges with version 1.3.3b (i think), this vulnerable version is still widely used in a LOT of data centres (since both virtualmin and plesk uses proftpd). We had major head aches at work because of pwned proftpd boxes.

Regarding the install.sh, doesn't it already install PostgreSQL? I think it does, but it doesn't configure it so it's actually usable (what I noticed is needed is md5 instead of ident in pg_hba.conf and postgres user needs setting a password). We can haz a different ticket/issue for this if you want, I could do some beta testing if needed.

What alternatives to FTP are there for the non-techie-user to get files into their webspace? Only thing I can really see is SCP/SFTP, which has the disadvantage that you cannot (easily) restrict a user's root path to their web home directory, but they'll see the host's root if they want to.

I know this doesn't constitute a real security issue, but explain your average web site caretaker that he has to go to /home/something/public_html and ignore all the other fancy stuff around it. ;)

Also, enabling SFTP also means enabling SSH, and maybe users don't want that.

Or is there anything I'm overlooking? :)

Locutus,

I think that's about it. Chrooting is still a big problem with SSH. Recent versions of openssh can do chroot automatically in a clean way but requires permissions that security on any web server. Too bad.