proftpd start at boot wont work

[jjjustjjjay]

I was a freebsd user but I recently switched to OpenBSD just for the sake of exploring. startuing things at boot with freebsd was eaiser that it apears in OpenBSD. i install proftpd and i added proftpd=YES and proftpd_flags="" in rc.conf.local but it wont start. i can manualy start it just by typing proftpd. i thought that format was right from other things i ve read and the way rc.conf is setup.

please help.

-Thanks

(didnt know if this shoud go here or ports but i put it here because this could apply for a drifferent program thats not a port)

[ocicat]

Originally Posted by jjjustjjjay

i install proftpd...

At one time, ProFTP was officially ported to OpenBSD's ports tree, but it is no longer active or present in the tree. I don't see any evidence since 2007. In searching both the official misc@ & ports@ mailing lists, no mention is made as to why it was removed, but some anecdotal comments can be found questioning how well the code base had been audited. I also found configuration questions similar to yours. If you check the ports tree directly or through third party tools such as http://openports.se, an abundance of FTP server alternatives are still present in the ports tree, & OpenBSD has its own (audited) ftp(1) & sftp(1) servers part of the base installation.

sftp(1) has the advantage over classic FTP servers in that passwords are not sent as cleartext over the wire.

The general convention on the official mailing lists is that users wanting to port third-party applications to OpenBSD in which an officially sanctioned port is not already present are pretty much on their own. We here at this site tend to follow the same rule-of-thumb, however if someone wants to speak up from experience, they are certainly welcomed to do so.

Likewise, in looking at ProFTP's Website, I do see where they claim to support OpenBSD, however, I find no further information. It is not uncommon for third-party sites to announce support for OpenBSD & then let verification languish over several versions. Given that I find no mention of what version number ProFTP claims compatibility, I would be skeptical.

If I do have a recommendation, I would steer you towards looking at OpenBSD's ftp(1) & sftp(1) servers. You may also want to peruse the ports tree for other alternatives. Otherwise, if you want to use ProFTP, you may want to contact ProFTP's developers or community to determine what is needed for running on OpenBSD.

[jjjustjjjay]

Ok but if i can start it have it run fine from a command line why would i unable to put it in the rc to start at boot?


-Thanks

[jggimi]

/etc/rc.conf and /etc.rc.conf.local are for environment variables used by /etc/rc -only-. These two files have no other value. Adding new environment variables you make up on your own will have no impact whatsoever.

If you want 3rd party applications started by /etc/rc, you do that in the shell script /etc/rc.local.

[J65nko]

There are packages for pure-ftpd and vsftpd. IIRC ftp.openbsd.org runs vsftpd

[BSDfan666]

As stated by jggimi, just adding a new variable to rc.conf/rc.conf.local won't automagically make things work.

The preferred method of starting 3rd party services at boot time is in rc.local(5), you probably should only start daemons/servers that properly support privilege separation using this method.

The alternative is to create a lesser privileged account and start it manually, if the software listens on a port <= 1024 by default, you can bind it to a higher port and use pf to redirect traffic.

Hope that helps.

[jjjustjjjay]

ok well thats what i did the rc.conf.local file looks like this

proftpd=YES
proftpd_flags=""

thats right is it not. proftpd is installed fine and i have run it from a command line and i can connect and i have set what groups can login and stuff like that.

[BSDfan666]

You're not reading what we're writing, rc.conf/rc.conf.local is not the correct file.. it's for system services.

The rc script has no knowledge of proftpd, nor does it act upon the inclusion of the "proftpd_*" variables, If you read the script and you'll understand why.

You need to modify rc.local (NOT rc.conf.local) to start proftpd, this includes a path to the executable name and any arguments required.

[J65nko]

Originally Posted by jjjustjjjay

ok well thats what i did the rc.conf.local file looks like this

proftpd=YES
proftpd_flags=""

thats right is it not.

No, that is not right
rc.conf and rc.conf.local are different from rc and rc.local. From rc(8):

     rc is the command script that is invoked by init(8) during an automatic
     reboot and after single user mode is exited; it performs system house-
     keeping chores and starts up system daemons.  Additionally, rc is intri-
     cately tied to the netstart(8) script, which runs commands and daemons
     pertaining to the network.  The rc.securelevel and rc.local scripts hold
     commands which are pertinent only to a specific site.

[snip]
     rc.local is executed towards the end of rc (it is not the very last as
     there are a few services that must be started at the very end).  Normal-
     ly, rc.local contains commands and daemons that are not part of the stock
     installation.

[J65nko]

Actually you can set variables like you did in /etc/rc.conf.local, but then you have to use them in the /etc/rc.local.

The /etc/rc script uses the following to decide whether to start sshd and with which options:

echo -n starting network daemons:

if [ X"${sshd_flags}" != X"NO" ]; then
        echo -n ' sshd';                /usr/sbin/sshd ${sshd_flags};
fi

If you use something similar in /etc/rc.local you can use your proftpd and proftpd_flags variables in /etc/rc.conf.local to start or not to start proftpd in the /etc/rc.local script.

For a test I created a stripped down version of the rc script, which does not start up any daemons, but does only the following:

1. Reads or includes the variable assignments from /etc/rc.conf.
   Note that this file will include the variable assignments from /etc/rc.conf.local
   
   

   $ tail -3 /etc/rc.conf 
   
   local_rcconf="/etc/rc.conf.local"
   
   [ -f ${local_rcconf} ] && . ${local_rcconf} # Do not edit this line

2. Includes the /etc/rc.local script
   

The stripped down version

# example rc file 

echo
echo "$0: Source/include the variable assignments from \"/etc/rc.conf\"" 
echo "     and \"/etc/rc.conf.local\" with the shell \".\" dot operator"

#  grep -n rc.conf /etc/rc  
#  248:. /etc/rc.conf

. /etc/rc.conf


echo
echo $0: Source/include  the \"/etc/rc.local\" script with the shell \".\" dot operator
echo

#  grep -n rc.local /etc/rc 
#  789:[ -f /etc/rc.local ] && . /etc/rc.local

[ -f /etc/rc.local ] && . /etc/rc.local

For simplicity sake I did not "include" the /etc/rc.securelevel which allows you to start things before the securelevel changes.

I placed this simplified rc file in a subdirectory temp in my home directory together with a simple test script called myprogram

$ pwd ; ls -l

/home/j65nko/temp

-rwxr-xr-x  1 j65nko  j65nko   61 Feb 27 23:07 myprogram
-rwxr-xr-x  1 j65nko  j65nko  459 Feb 28 00:09 rc

$ cat myprogram                                                    

#!/bin/sh

cat <<END

This is my program
My options: $@
END

As you can see this myprogram script just prints a message and the displays the options passed to it. An example

$ myprogram clinton obama

This is my program
My options: clinton obama

To control myprogram I added the following to the real /etc/rc.conf.local:

myprogram="YES"
myprogram_flags="-s -p -x"

The real /etc/rc.local script uses these variables as follows

#       $OpenBSD: rc.local,v 1.39 2006/07/28 20:19:46 sturm Exp $

# Site-specific startup actions, daemons, and other things which
# can be done AFTER your system goes into securemode.  For actions
# which should be done BEFORE your system has gone into securemode
# please see /etc/rc.securelevel.

echo -n 'starting local daemons:'

# Add your local startup actions here.

cat <<END

Displaying 'myprogram' variables :
===================================
$(set | grep myprogram)
==================================
END

if [ X"${myprogram}" != X"NO" ] ; then
   echo -n " myprogram" ;  /home/j65nko/temp/myprogram ${myprogram_flags} 
fi

echo '.'

First task is just for diagnostics.The shell set command prints all variables. Because this list is quite long, I used grep to filter out the ones having myprogram in it.

The actual work is done in a similar way like the real "rc" starts up sshd.

• if myprogram is not set to "NO", then display the name of the program
  
• Invoke /home/j65nko/temp/myprogram and pass it the flags or options as set by the myprogram_flags variable.

Running the stripped version of rc in this temp directory:

$  ./rc

./rc: Source/include the variable assignments from "/etc/rc.conf"
     and "/etc/rc.conf.local" with the shell "." dot operator

./rc: Source/include the "/etc/rc.local" script with the shell "." dot operator

starting local daemons:
Displaying 'myprogram' variables :
===================================
myprogram=
myprogram_flags='-s -p -x'
==================================
 myprogram
This is my program
My options: -s -p -x
.

Conclusion:

You can use your own daemon controlling variables in /etc/rc.conf.local which are not supported in the standard /etc/rc script.

To use these custom variables you have to write some some simple code in /etc/rc.local which uses them. Read the real /etc/rc script. to find inspiration.