Unable to start vsftpd with upstart if private key
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
upstart |
New
|
Undecided
|
Unassigned | ||
vsftpd (Ubuntu) |
Triaged
|
Medium
|
Unassigned | ||
Maverick |
Triaged
|
Medium
|
Unassigned |
Bug Description
Binary package hint: vsftpd
Example of configuration added in /etc/vsftpd.conf :
=======
ssl_enable=YES
validate_cert=YES
ca_certs_
rsa_cert_
rsa_private_
=======
$ sudo service vsftpd start
[sudo] password for eric:
vsftpd start/running, process 3166
$ ps -ef | grep -E "(vsftpd|3166)" | grep -v grep
On the contrary, it works when launching directly the vsftpd daemon :
$ sudo vsftpd
Enter PEM pass phrase:
$ ps -ef | grep -E "[v]sftpd"
root 3206 1298 0 08:00 pts/0 00:00:00 vsftpd
Could there be also a prompt for the passphrase with vsftpd launched with upstart ?
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: vsftpd 2.2.2-3ubuntu6
ProcVersionSign
Uname: Linux 2.6.32-22-generic i686
Architecture: i386
Date: Sun Jul 11 07:51:58 2010
ProcEnviron:
LANG=fr_FR.UTF-8
SHELL=/bin/bash
SourcePackage: vsftpd
Changed in vsftpd (Ubuntu): | |
importance: | Undecided → Medium |
status: | New → Confirmed |
tags: | added: server-mrs |
I believe the upstart jobs inherit the stdio settings the upstart (init) itself had at bootup, which likely point to whatever was considered the "console". Simply telling upstart to "start" a job (service vsftpb start) notifies the upstart daemon over d-bus to start the child process. Hence, it has no direct means of knowing the current console session of the user.
The sysv init script system, by contrast, would start the daemon directly from the issuing command (like sudo /etc/init. d/vfstartd start) which of course would inherit the stdio settings of the user executing the command.
This of course does not offer a solution, but rather offers better understanding of the actual core problem.
I believe this question and issue should be forwarded to upstart at least for discussion. I could do a separate summary and bug report for that.
Basically, some daemons (like vsftp) may prompt the user during startup. A common case might be to get the password for unlocking a password protected private key, and I am sure this can apply to many other daemons that may do this including for example apache. I do not believe upstart has any provision to handle this kind of scenario other than, at boot, if the process is started then, it's password prompt should appear on whatever was the "console".