Custombuild install problems with Debian Etch

I'm attempting to install DA in Debian Etch and believe I have found a number of bugs. Note that I am installing clean with the custombuild option, not installing with customapache and then updating. Not that that works either.

The first error is from the line "chown -f root:ftp /etc/proftpd.passwd" in scripts/proftpd.sh. Debian base install does not have an ftp group. The script also attempts to install proftpd-1.3.1.deb without first downloading it. These errors also occur when trying to install with customapache. Where in the scripts should proftpd-1.3.1.deb be downloaded?

When running the "make install" from custombuild/build::doProftpd() it attempts the following line, that fails because debian also has no ftp user in the base install.
/usr/bin/install -c -s -o ftp -g ftp -m 0755 proftpd /usr/sbin/proftpd

Both of these errors can be fixed by adding the ftp user and group before running the scripts.

After install DA complains that proftpd is not running and it fails to start it. This turned out to be because there is no /etc/init.d/proftpd script installed. Where does this come from on other platforms?

Another issue is the wget problem that everyone seems to have. This of properly solved by installing ca-certificates beforehand, as debians wget does support https but it needs these certificates to perform verification.

Yet another is the scripts trying to install gd. In debian gd is known as libgd1-xpm or libgd2-xpm. Solve by install libgd2-xpm before running the scripts:

I'll leave it at this for now. Any help is appreciated, and I'm happy to submit patches for problems I can fix if they will be accepted.

Cheers

Hello,

I've added the "groupadd ftp" command to the proftpd.sh for debian, available for the next release (does a check for /etc/group first).

Regarding ca-certificates, I did some tested of adding the packages and I can't see to get it to not give the full screen menu to chose the options. We'd need it to be a totally silent and non-interactive install if we're to use it as many datacenteres call the setup.sh via an automated script.
Failing that, this is our guide to install a working verison of wget that doesn't have the checks:
http://help.directadmin.com/item.php?id=119

We could easily just add the guide into the setup.sh to compile a new wget on the fly.. may be another option which is OS independant.

For gd, you can probably ignore the errors there. Custombuild install php/gd as needed... check a <? phpinfo(); ?> to see if you have gd compiled in (I believe it comes with php5 now...). In any case, it's more for other OS's and it's a generic function call to install the package, but isn't always needed for certain OS's.

John

Hi John

Thanks for the reply and sorry for the delay. I've been trying to get the spare time to try and reproduce your problem installing ca-certificates. There should not be any user interaction from "apt-get install ca-certificates" apart from a possible confirmation if prerequisites are needed, and that can be avoided by passing --yes. Can you please explain in more details what you get.

I'd prefer not having the official debian wget overwritten. That's just asking for trouble down the line and should be easily avoided by installing ca-certificates to gain https support.

Do you know why I had problems with proftpd-1.3.1.deb not being downloaded or why /etc/init.d/proftpd was missing. This is really a matter of how it *should* happen, and why it's not happening that way for me.

Shane

I've finally got around to retrying the install again. This time the critical failures seem to be fixed. The ftp user and group both exist as well as the proftpd init.d script. Thanks for whatever you did. Below is my current DA install "recipe" for those interested. My only major remaining issues are with my lack of trust in the install scripts and the fudging being done with the DA provided .deb packages.

If the machine dies an ugly death I need to know I can reinstall everything promptly, as well as trusting that a ./build all won't hose a working system. Is it possible to run the install scripts from an IP not matching my DA licence to confirm that they continue to work?

Non-debian provided packages should not have names conflicting with the official packages. Although the DA exim is in a file named da_exim-4.67.deb the package is still named "exim" internally. So apt-get update will happily replace the installed exim with a newer version from the debian repository! I would suggest naming them da-exim, da-proftpd, etc or similar. This would also allow them to have conflicts lines against the official exim, proftpd, etc; to forcibly prevent the official packages from accidentally being installed. Both of these changes can be made in the debian/control file in the package source.

My DA install recipe (from a new Xen instance):

PS. The message above from shaned is from me. I lost that registration, but my work computer remembered it for me!