Bug 753365 - multiple issues with vsftpd's systemd unit
Summary: multiple issues with vsftpd's systemd unit
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: vsftpd
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jiri Skala
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 753665 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-12 01:03 UTC by Michal Schmidt
Modified: 2014-11-09 22:35 UTC (History)
15 users (show)

Fixed In Version: vsftpd-2.3.4-6.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-02 21:28:08 UTC
Type: ---


Attachments (Terms of Use)
New and improved unit =) (171 bytes, text/plain)
2011-11-13 00:12 UTC, Jóhann B. Guðmundsson
no flags Details

Description Michal Schmidt 2011-11-12 01:03:26 UTC
Description of problem:
The systemd unit file for vsftpd in F16 is odd in many ways and somewhat buggy:

Issue #1: Badly chosen service type
"Type=oneshot" is useful for services that perform one-time initialization and do not fork off daemons, such as iptables. This is clearly not the case of vsftpd.
The process started by the ExecStart command is not the main process of the service, because vsftpd forks. The type should be "forking" then. I suspect "RemainAfterExit=yes" is currently used as a workaround for the problems caused by the badly chosen type. It too is inappropriate for a daemon.

Issue #2: A comment suggests admins to add symlinks under /lib
I refer to this comment in the unit file:
# ln -s /lib/systemd/system/vsftpd@.service /lib/systemd/system/vsftpd@vsftpd2.service
Administrators should not customize anything under /lib. They should use /etc.

Issue #3: The [Install] section does not work as people expect
"WantedBy=multi-user.target" was the right idea, but unfortunately it does not behave well in the template unit. The command:
 systemctl enable vsftpd@.service
will not do the right thing. This is in part systemd's fault (bug 752774).
You may want to use this instead:
 Alias=multi-user.target.wants/vsftpd@vsftpd.service
to make systemctl enable the typical instance of your template, not the template itself.

Meta-Issue: Should a template have been used at all?
I admit that the SysV initscript for vsftpd in Fedora has for many years supported the starting of more instances of the daemon. However, what makes vsftpd so special that this needs to be supported out of the box for this daemon? Multiple instances can be useful for many other daemons too, yet we do not write the initscripts/units generally like that. The vast majority of users do not run more than one instance. For them it is a needless complication. Those who do need multiple instances can easily do so by copying the unit file. The template does not really help them that much.
Furthermore, it seems all other Linux distributions simply run one instance of vsftpd (using /etc/vsftpd.conf) in their scripts - I checked Debian, OpenSUSE, Ubuntu, Arch.
With systemd units the goal should be to get them upstream and share them among all distributions. I believe a single-instanced vsftpd.service would be more palatable to upstream than a vsftpd@.service template.

Version-Release number of selected component (if applicable):
vsftpd-2.3.4-5.fc16

Comment 1 Jóhann B. Guðmundsson 2011-11-12 23:59:38 UTC
(In reply to comment #0)
> Description of problem:
> The systemd unit file for vsftpd in F16 is odd in many ways and somewhat buggy:
> 
> Issue #1: Badly chosen service type
> "Type=oneshot" is useful for services that perform one-time initialization and
> do not fork off daemons, such as iptables. This is clearly not the case of
> vsftpd.
> The process started by the ExecStart command is not the main process of the
> service, because vsftpd forks. The type should be "forking" then. I suspect
> "RemainAfterExit=yes" is currently used as a workaround for the problems caused
> by the badly chosen type. It too is inappropriate for a daemon.

I taken that one on me the answer to the rest of your comments can be found in bug 719434...

Comment 2 Jóhann B. Guðmundsson 2011-11-13 00:12:18 UTC
Created attachment 533307 [details]
New and improved unit =)

Just drop in that one and fix the other unit's accordingly and as I had mentioned on the previous bug report ( comment 5 )the shipped templates can just act as addons for those that want to run more then one instance while having the vsftpd.service will keep upgrade paths along with service foo start backwards compatability...

Comment 3 Jiri Skala 2011-11-14 08:00:18 UTC
*** Bug 753665 has been marked as a duplicate of this bug. ***

Comment 4 Jim Haynes 2011-11-15 02:57:05 UTC
I couldn't get vsftpd to start at boot time either.  I just followed the
instructions under bug 753665 and that seems to have fixed it.  Then earlier
I couldn't get vsftpd to read home directories, and someone gave me an
incantation to fix that.

I'm dismayed that system administration is getting more arcane and difficult
as time goes on and new releases come out.  I've been with Linux for a long
time, and it just keeps getting more complicated without much improving
my ability to get my work done.  Sometimes we get new tools that make
system administration easier, and then things happen like the switch to
systemd that set me way back.  It shouldn't be this hard to set up an
ftpd server on my workstation.

Comment 5 Fedora Update System 2011-11-15 14:26:33 UTC
vsftpd-2.3.4-6.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/vsftpd-2.3.4-6.fc16

Comment 6 E. Lewis 2011-11-15 18:13:05 UTC
I confirm the existence of this bug.

There is also a documentation error:

Section 15.2.4 of the Fedora 16 System Administrators Guide states that to start the vsfpd server, issue the command (as root) 'systemctl start vsftpd.service'. There are companion restart and stop commands.

The start command results in the following error: 'Failed to issue method call: Unit vsftpd.service failed to load: No such file or directory. See system logs and 'systemctl status vsftpd.service' for details.'

This appears to be a regression from fc-15 where vsftpd seemed to work fine.

There appear to be similar errors attempting to use the nfs server as well.

Comment 7 Jóhann B. Guðmundsson 2011-11-15 18:35:41 UTC
Try the update ( which was mentioned in comment 5 ) 

http://koji.fedoraproject.org/koji/buildinfo?buildID=274170

Works just fine there 

# for i in start status restart status stop status; do systemctl $i vsftpd.service; done 
vsftpd.service - Vsftpd ftp daemon
	  Loaded: loaded (/lib/systemd/system/vsftpd.service; disabled)
	  Active: active (running) since Tue, 15 Nov 2011 18:33:48 +0000; 38ms ago
	 Process: 17985 ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf (code=exited, status=0/SUCCESS)
	Main PID: 17986 (vsftpd)
	  CGroup: name=systemd:/system/vsftpd.service
		  └ 17986 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
vsftpd.service - Vsftpd ftp daemon
	  Loaded: loaded (/lib/systemd/system/vsftpd.service; disabled)
	  Active: active (running) since Tue, 15 Nov 2011 18:33:48 +0000; 20ms ago
	 Process: 17991 ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf (code=exited, status=0/SUCCESS)
	Main PID: 17992 (vsftpd)
	  CGroup: name=systemd:/system/vsftpd.service
		  └ 17992 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
vsftpd.service - Vsftpd ftp daemon
	  Loaded: loaded (/lib/systemd/system/vsftpd.service; disabled)
	  Active: inactive (dead) since Tue, 15 Nov 2011 18:33:48 +0000; 54ms ago
	 Process: 17991 ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf (code=exited, status=0/SUCCESS)
	Main PID: 17992 (code=killed, signal=TERM)
	  CGroup: name=systemd:/system/vsftpd.service

Comment 8 Fedora Update System 2011-11-16 00:32:33 UTC
Package vsftpd-2.3.4-6.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing vsftpd-2.3.4-6.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-15986
then log in and leave karma (feedback).

Comment 9 E. Lewis 2011-11-16 13:38:39 UTC
Response to comment 7:

Your recommendation works as follows. Thanks.

download the updates you recommended.

change to the directory of the download
command: su -c 'yum install vsftpd-2.3.4-6.fc16.x86_64.rpm'
su -c 'yum install vsftpd-sysvinit-2.3.4-6.fc16.x86_64.rpm'
su -c 'yum install vsftpd-debuginfo-2.3.4-6.fc16.x86_64.rpm'

Start the vsftpd service:
su -c systemctl start vsftpd.service

This works fine. It is possible to use the companion commands -- stop and restart as well.

There is still a problem, likely involving interaction with 'pluggable authentication modules'.

Anonymous ftp works.

It is not possible, however to log in with a user account, any adjustments in the files /etc/vsftpd/ directory notwithstanding. (Refer to Fedora 16 System Administrators Guide, Chapter 15.2.3.).

Any attempt to log in from either localhost (127.0.0.1) or from a remote client results in an error: 530 Login incorrect.
Login failed.

Response to Comment 8

Doesn't work yet. I haven't given the file to make its way to the repository yet. The instruction in Comment 7 seems to work relative to installing and running vsftpd as noted above.

Logging in under a user account still does not work. It worked in fc-15 server.

Thanks for all of your help.

Comment 10 Michal Schmidt 2011-11-16 13:57:11 UTC
Jiří,
thanks for putting the vsftpd.service unit into the package. May I suggest though that you also add a RPM scriptlet that would enable the new unit if the user previously had the vsftpd@vsftpd.service instance enabled? Some users may have already figured it out how to enable vsftpd in F16 GA and this update will make it disabled again. It probably does not make sense to try to migrate other instances of the template, but migrating at least the typical one should cover the most users.
Or at the very least, please add a warning note in the Bodhi description that manual enablement of the service is necessary after the update (systemctl enable vsftpd.service).

Comment 11 Michal Schmidt 2011-11-16 14:11:28 UTC
Another option would be to keep shipping the template vsftpd@.service (with the fixed Type=..., etc.) in the package in addition to the plain vsftpd.service. That way the users who already used the template in F16 GA can keep using it if they like. And don't touch vsftpd@.service in the scriptlets at all, it would be for manual handling only.

Comment 12 Andy Blanchard 2011-11-18 15:58:03 UTC
Re. FTP not working with user accounts in comment #9, this is another known bug - see https://bugzilla.redhat.com/show_bug.cgi?id=752827 for more info.

Assuming your default shell is bash, then the quickest fix is to add the line "/bin/bash" to the end of "/etc/shells" if it's not already present, or if you don't feel happy editing config files by hand run the following command:

sudo echo /bin/bash >> /etc/shells

A pending update to the bash package should fix this for good.

Comment 13 E. Lewis 2011-11-18 18:23:54 UTC
Response to Comment 12
Works! 
Thanks so much for your help.

Comment 14 Fedora Update System 2011-12-02 21:28:08 UTC
vsftpd-2.3.4-6.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 15 sdcarter1 2011-12-12 18:19:14 UTC
I have been experiencing the same problem. when i opened /etc/shells to add /bin/bash at the end of the file i noticed that the last line read /bin/dash made the change. still get the 530 error

Comment 16 P H 2011-12-16 03:18:09 UTC
Is adding /bin/bash to the /etc/shells just a quick fix for error: 530 Login incorrect.

Is there a permanent fix for this.

Comment 17 Ralf Baechle 2011-12-21 11:01:02 UTC
The fix is imho a bit too simplistic.  Older System V init scripts did support running multiple instances of vsftpd, one for each /etc/vsftpd/vsftpd*.conf config file and so did the unit file of the original F16 vsftp rpm - albeit totally broken.  But the new vsftpd-2.3.4-6.fc16 unit files assumes there only is a single instance which is a step backward.  Otoh multiple copies of the unit files is not a good solution because it makes upgrades harder should the unit file change and I think all instances of vsftpd should rather be considered a single service than multiple.

A /lib/systemd/system/vsftpd@.service unit file like the following:

[Unit]
Description=Vsftpd ftp daemon
After=syslog.target network.target

[Service]
# Follow the steps below to set up an additional configuration file:
#
# cp /etc/vsftpd/vsftpd.conf /etc/vsftpd/vsftpd2.conf
# ln -s /lib/systemd/system/vsftpd@.service /etc/systemd/system/multi-user.target.wants/vsftpd@vsftpd2.service
#
Type=oneshot
ExecStart=/usr/sbin/vsftpd /etc/vsftpd/%i.conf
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
Alias=multi-user.target.wants/vsftpd@vsftpd.service

works fine for me.  This file really is just a minor modification from the original F16 rpm's unit file.

Comment 18 Ron Flory 2012-01-10 15:11:00 UTC
(In reply to comment #12)
> Re. FTP not working with user accounts in comment #9, this is another known bug
> - see https://bugzilla.redhat.com/show_bug.cgi?id=752827 for more info.
> 
> Assuming your default shell is bash, then the quickest fix is to add the line
> "/bin/bash" to the end of "/etc/shells" if it's not already present, or if you
> don't feel happy editing config files by hand run the following command:
> 
> sudo echo /bin/bash >> /etc/shells
> 
> A pending update to the bash package should fix this for good.

As of 2012/01/10 09:08, this is still missing.  

 I added /bin/bash, which seems to now allow anonymous login, but normal user login is still denied:
 
 500 OOPS: cannot change directory: /home/rjflory
 Login Failed.

 This even happens with user dir perms set to 0777.

Comment 19 Ron Flory 2012-01-10 15:47:20 UTC
(In reply to comment #18)
> (In reply to comment #12)
> > Re. FTP not working with user accounts in comment #9, this is another known bug
> > - see https://bugzilla.redhat.com/show_bug.cgi?id=752827 for more info.
> > 
> > Assuming your default shell is bash, then the quickest fix is to add the line
> > "/bin/bash" to the end of "/etc/shells" if it's not already present, or if you
> > don't feel happy editing config files by hand run the following command:
> > 
> > sudo echo /bin/bash >> /etc/shells
> > 
> > A pending update to the bash package should fix this for good.
> 
> As of 2012/01/10 09:08, this is still missing.  
> 
>  I added /bin/bash, which seems to now allow anonymous login, but normal user
> login is still denied:
> 
>  500 OOPS: cannot change directory: /home/rjflory
>  Login Failed.
> 
>  This even happens with user dir perms set to 0777.

As with so many other things, disabling SELinux 'fixed' this...

Comment 20 Jiri Skala 2012-01-11 07:57:44 UTC
> > 
> >  I added /bin/bash, which seems to now allow anonymous login, but normal user
> > login is still denied:
> > 
> >  500 OOPS: cannot change directory: /home/rjflory
> >  Login Failed.
> > 
> >  This even happens with user dir perms set to 0777.
> 
> As with so many other things, disabling SELinux 'fixed' this...

You have to set following selinux boolean:

# setsebool ftp_home_dir on

Comment 21 Jose 2012-03-20 16:13:22 UTC
hi all, i have the same problem, i can't login with anything user please help me!
i set selinux ftp_home_dir on. I can login with anonymous user but i can't login with other user, i did all things that you say here!


Note You need to log in before you can comment on or make changes to this bug.