PDA

View Full Version : NOT Force installed MySQL



empowering
07-09-2008, 07:17 AM
DA and smtalk... can you NOT _NOT_ *NOT* force install mysql rpms per your build script. With a new install I tell mysql in the options.conf to not install the mysql rpms.



mysql=5.0
mysql_inst=no
mysql_backup=no


before running setup.sh. I have the setup.sh run custombuild and perform the install automatically (which I'm not going to detail here).

yet mysql rpms not only get installed BUT you perform a force install with mysql rpms already there (not the RH/CentOS) RPMs that are also newer then your rpms. So I have two sets of rpms! My mysql rpms there were pre installed and then DA's:



[root]# rpm -q -a | grep -i mysql
MySQL-devel-community-5.0.51a-0.rhel4
MySQL-client-community-5.0.51a-0.rhel4
MySQL-client-community-5.0.41-0.rhel4
MySQL-shared-community-5.0.41-0.rhel4
MySQL-server-community-5.0.51a-0.rhel4
MySQL-shared-community-5.0.51a-0.rhel4
MySQL-server-community-5.0.41-0.rhel4
MySQL-devel-community-5.0.41-0.rhel4


Why is my options.conf not working? Can you also stop doing things like forcing rpms to get installed and do things the proper method if you are using rpms!!! As I've stated previously all of this makes it very hard to automate and the world does not revolve around DA's 'build' script.

smtalk
07-10-2008, 12:17 AM
Hello,

I was not able to find the bug. Did you run "./build all"? It has:


if [ "${MYSQLINST_OPT}" = "yes" ]; then
doMySQL;
fi


If not - please let me know.

empowering
07-10-2008, 06:15 AM
Hello,

I was not able to find the bug. Did you run "./build all"? It has:


if [ "${MYSQLINST_OPT}" = "yes" ]; then
doMySQL;
fi


If not - please let me know.

It was run via setup.sh. According to DA support this is the method to run custombuild instead of customapache automatically. I have not looked into the code to see what exactly is happening.



echo 1.1 > /root/.custombuild
mkdir -p /usr/local/directadmin/custombuild
wget -O /usr/local/directadmin/custombuild/options.conf http://path.com/toyourcustom/options.conf
./setup.sh 123 4567 host.name.com eth0 1.2.3.4


In the 'build' you have.



rpm -Uhv ${MYSQLCLIENT} ${MYSQLDEVEL} ${MYSQLSERVER} ${MYSQLSHARED} --force


why is mysql force installed??? Even if this section of code runs, it shouldn't be doing this. You should either remove rpms already installed OR if older RPMS are trying to be installed do nothing OR the install should error out and fail.

Also installing:

/etc/init.d/mysqld

when the any mysql rpm supplies this is unneeded. The mysql rpms typically supply /etc/init.d/mysql NOT mysqld, so now there are two init processes which causes all sorts of confusion.

If DA is going to use some RPM packages (or any other package manager for that matter) please follow the package manager's rules and properly install the packages. Force install anything is telling me either it's lazy coding or not fully understanding how package managers should work.

empowering
07-10-2008, 06:18 AM
[root@affiniti08 custombuild]# rpm -q -f /etc/rc.d/init.d/mysqld
file /etc/rc.d/init.d/mysqld is not owned by any package
[root@affiniti08 custombuild]# rpm -q -f /etc/rc.d/init.d/mysql
MySQL-server-community-5.0.51a-0.rhel4

smtalk
07-10-2008, 06:36 AM
Yes, you are right. I think we should use --oldpackage instead of it.

empowering
07-10-2008, 06:54 AM
Yes, you are right. I think we should use --oldpackage instead of it.

Why should the build process downgrade? If a newer package is installed isn't that a "good thing"?

Again, the world does not revolve around DA. Some providers (like us) want to either use specific versions OR want the latest versions to fix bugs/security. FYI the version you are installing has security risks as one perfect example. We'll keep our setup secure thank you.

http://dev.mysql.com/doc/refman/5.0/en/releasenotes-cs-5-0-51a.html

Like I've stated before, not using package management or not even using it correctly makes keeping systems updated and secure that much harder.

IMHO DA is a control panel, not a package manager. In an ideal world we should be allowed to keep a server's software current how we see fit and if we want DA should be kept out of the picture and not even have to use the build script.

empowering
07-10-2008, 06:58 AM
Yes, you are right. I think we should use --oldpackage instead of it.

At least if you do this, our Puppet recipe will clobber your downgrades and fix what you broke.

smtalk
07-10-2008, 07:32 AM
If user wants to downgrade e.g. from 5.1 to 5.0 there is no other way to do that (I think), only --force or --oldpackage.

empowering
07-10-2008, 07:42 AM
If user wants to downgrade e.g. from 5.1 to 5.0 there is no other way to do that (I think), only --force or --oldpackage.

or remove the other package first. a rpm -e, might be different than --oldpackage. Since different commands in the .spec file might be called. I donno as I haven't ever researched this. In each RPM .spec file you can have:


%pre
%post
%preun
%postun


Some details on the subject:

http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Syntax

meaning --oldpackage might be considered an 'upgrade' and a -e which is a remove of that package, which will run %postun. If it is doing this an uninstall is much cleaner since it removes everything as if the rpm was never installed and ensures a clean install for the new setup. The only thing usually left behind is *.rpmsave files for customized config files.

If you are doing that explicitly by your build process, (ie mysql is currently set to 5.1 and the user changes 5.0) that's fine by me. The real beef I have is within the 5.0.x branch forcing us to use a specific version.

In our case we just disable mysql in your options.conf.

Which goes back to my original issue, why is it still called if I have it setup in the options.conf before setup.sh is run?

smtalk
07-10-2008, 07:54 AM
I found the problem. It's not a CustomBuild problem, but mysql.sh problem (/usr/local/directadmin/scripts/mysql.sh):



rpm -e --nodeps MySQL-Max 2> /dev/null 1> /dev/null
rpm -e --nodeps mysql-devel 2> /dev/null 1> /dev/null
rpm -e --nodeps mysql-client 2> /dev/null 1> /dev/null
rpm -e --nodeps mysql-libs 2> /dev/null 1> /dev/null
rpm -e --nodeps mysqlclient9 2> /dev/null 1> /dev/null
rpm -e --nodeps mysql-server 2> /dev/null 1> /dev/null
rpm -e --nodeps mysql 2> /dev/null 1> /dev/null
rpm -e --nodeps MySQL-shared 2> /dev/null 1> /dev/null #added july 3 2006 for mysql 5 shared rpms
rpm -e --nodeps mysql-libs php-mysql 2> /dev/null 1> /dev/null #added Dec 5, 2007 for fedora 7.


It does not remove mysql*community RPMs. And it doesn't update MySQL packages (rpm -Uhv), but installs (rpm -ihv):


rpm -ivh --nodeps --force /usr/local/directadmin/scripts/packages/MySQL-server*.rpm
rpm -ivh --nodeps --force /usr/local/directadmin/scripts/packages/MySQL-client*.rpm
rpm -ivh --nodeps --force /usr/local/directadmin/scripts/packages/MySQL-devel*.rpm
rpm -ivh --nodeps --force /usr/local/directadmin/scripts/packages/MySQL-shared*.rpm >/dev/null 2>/dev/null


So, your problem was not caused by the CustomBuild script :)

empowering
07-10-2008, 08:14 AM
Also I didn't validate this, but I believe proftpd, exim, dovecot, the web apps, etc. all got installed yet our options.conf file was setup this method.



# SOME OPTIONS IF CHANGED WILL BE FORCED BACK TO ORGINAL VALUE. IF UNSURE ASK!
#PHP settings. default_php possible values - 4 or 5
default_php=5
php4_cli=no
php4_cgi=no
php5_cli=no
php5_cgi=yes
zend=no

#Possible values - 4.1, 5.0 or 5.1
mysql=5.0
mysql_inst=no
mysql_backup=no

#Possible values - 1.3, 2.0 or 2.2
apache_ver=2.0

#Web applications
phpmyadmin=no
atmail=no
squirrelmail=no
roundcube=no
uebimiau=no

#Mail options
exim=no
mail-header-patch=yes
dovecot=no

#FTP options
proftpd=no

#Jailed shell (beta)
jail=no

#CustomBuild options
autover=no
bold=no
clean=yes

#Cron settings
cron=yes
email=asdfadsfasdfafd@empoweringmedia.com
notifications=yes
updates=no

#CustomBuild 1.2 settings
php6_cli=no
php6_cgi=no
php_ini=no
#Possible values - recommended or dist
php_ini_type=recommended
cleanapache=no
fileserver=1
eximconf=no


I assume this is because the setup.sh isn't using custombuild for everything?

empowering
07-10-2008, 08:19 AM
The only things we leave to DA is apache and PHP, everything else we use RPMs for.

smtalk
07-10-2008, 12:46 PM
Yes, DirectAdmin installs everything as it's needed for installation and only then runs CustomBuild.

empowering
07-10-2008, 01:27 PM
Yes, DirectAdmin installs everything as it's needed for installation and only then runs CustomBuild.

Isn't that kinda bassackwards? so then what is custombuild used for in the setup.sh process??

DirectAdmin Support
07-10-2008, 06:21 PM
Hello,

DA is a bit "forceful" with the mysql install because it needs mysql to have the new data setup withou any passwords so that DA can then setup the new mysql root password and da_admin password.

What I've done is changed the -ivh to -Uvh as requested which should sort that out. I've left the --force as it's saved us headaches often when things like the pgp check fails for whatever reason (or whatever it is) but the package is still perfectly valid. But the Uvh should prevent you getting the duplicates. This will be avaiable for the next release.

The mysql.sh script is for setting up new accounts, passwords etc.. while custombuild (with respect to mysql) is more for updating it to new versions, hence it's set to "no" by default for mysql.

If you thing there needs to be more changes, let me know and we'll look at them.

John

empowering
06-13-2011, 05:53 AM
If you thing there needs to be more changes, let me know and we'll look at them.

John

John,

This process is still broken. I've had some time to revisit automating a DA install as part of our build process using Puppet.

FYI you are still installing a MySQL 5.0.51 that has security issues.

your install.sh forces your mysql rpms to get installed.

Ideally I would rather have us install the MySQL rpms we want to use and then call DA's build process.

If not, then I am forced to create my own setup.sh and then replace within that script point to my own install.sh script.

SeLLeRoNe
06-13-2011, 06:19 AM
Well maybe (if i can put my 2cent) skip the directadmin stuff installation (phpmyadmin mysql and other for example) and let just start custombuild script so the user can choose what install and what not from options.conf file

Am i wrong?

Regards

empowering
06-13-2011, 06:26 AM
Well maybe (if i can put my 2cent) skip the directadmin stuff installation (phpmyadmin mysql and other for example) and let just start custombuild script so the user can choose what install and what not from options.conf file

Am i wrong?

Regards

I'm forced to create my own setup.sh, install.sh and mysql.sh because of the dependancies.

Why not at least allow for the install of a custom install.sh and mysql.sh in the custom folder? If someone puts them there they should be knowing they are doing it on purpose and if they break the install process it's because of their scripts.

DirectAdmin Support
06-15-2011, 02:05 AM
Hello,

Thanks for letting me know.

1) I've updated the mysql.sh script to do a better job of removing rpms:
if [ -e /usr/bin/mysql ]; then
for i in `rpm -qa | grep -i "^mysql"`; do { rpm -ev $i --nodeps; }; done;
fiavailable for the next release of DA.

2) I've removed --force from the rpm -Uhv calls in custombuild. Will continue to monitor closely to ensure we didn't break anything.

3) Thanks for pointing out the 5.0.51 version in the CentOS 5 64-bit package. I've updated it to 5.1.57.

4) To bump our scripts at install time, I think the easiest way would be to add a plecibo mysql.sh before running the install, and set it to chattr +i. When the update.tar.gz is extracted, your version will remain and will be called.

John