cleaner builds and using RPMs instead of custom builds

jlasman said:
We've never seen DirectAdmin modify the the exclude line in yum. Can you document any particular update that has?

Jeff
Click to expand...

in /etc/yum.conf

exclude=apache* httpd* mod_* mysql* MySQL* da_* *ftp* exim* sendmail* php* bind* bind-chroot*
 
jlasman said:
I'd love to switch to updating on only one system, and then using a method to duplicate that across all servers, but that would take a lot of work, and would also be very OS dependent.
Click to expand...

Things like Puppet can reduce this quite a bit and make it easier than previous shell scripts. We have pretty much all of our customizations into puppet, right now currently only all CentOS (different versions though), but will be able to add other distros to our managed setup very easily. To keep this thread on track my beef is with the upgrading/updating DA not installing.
 
in /etc/yum.conf

exclude=apache* httpd* mod_* mysql* MySQL* da_* *ftp* exim* sendmail* php* bind* bind-chroot*
Click to expand...

These were added during the original install of DirectAdmin NOT during any update. Do you have a problem with excluding any of the above?
 
In this case you're right, Floyd :).

A standard DirectAdmin install probsbly doesn't want to update any of these from RPMs.

However you or anyone can change this line at any time; DirectAdmin never looks at it again after installation.

Jeff
 
jlasman said:
In this case you're right, Floyd :).

A standard DirectAdmin install probsbly doesn't want to update any of these from RPMs.

However you or anyone can change this line at any time; DirectAdmin never looks at it again after installation.

Jeff
Click to expand...

Sorry I was confused on the term update. It's only during the initial install.
 
empowering said:
Which is a valid reason to create a custom rpm.



Yes if it's in conflict with another required RPM that's the best way of handling it. If using your methodology, then the alias should be installed via your script, not in the RPM.



If they were using package management, no in most cases it's just changing the version # and rebuilding the package. No different than you describe. I donno how automated/manual your development process is so I can't speak for how you do it, but it's all definitely possible with not much extra work.

Out of the the OSes I'm aware you support, FreeBSD is the only one that doesn't support a package manager. CentOS, Fedora, RHEL, Debian all have package managers. Hell with most using RPMs you could even take a SRPM created and compile it on the destination machine and then install.



In mosts cases the distro already has all of the applications you need. If not there are already reliable packages out there available to do the job. If I'm mistaken there isn't many custom patches that DA makes to each of the complied source code?

The difference is if someone wants something newer than their distro, leave that to the sysadmin to decide how they want to do it, not DA. IMHO DA should be working closer with the distro they offer, not against them. By custom compiling code that's exactly what DA's doing and in the end makes server harder to maintain. Would you agree with this statement?

I'm not saying using everything already built into the distro BUT PLEASE use their package manager as much as possible.

Ok let me ask you this, how does DA recommend keeping all servers updated with the custom complied code? Manually SSHing into each machine?

You have the installing/creating a new DA instance down pat. How does DA keep them updated? This is where DA's software falls short, and most of the discussions in the forum is about this.
Click to expand...

I do not want directadmin to go the precompiled route its inferior to compiling. The only problems I have had with directadmin is from mysql and exim both precompiled, yet no problems with customapache httpd php etc. all compiled. I even use mysqld from ports since it means I am using a compiled version on the box. Also would like to use compiled exim. Customapache and custombuild are both fairly easy to use.
 
Chrysalis said:
I do not want directadmin to go the precompiled route its inferior to compiling.
Click to expand...

How is it inferior? Please detail this other than making a vast generalizations. My points:
- compiling code per server gives little to no performance edge
- packages can be setup to include or require other specific packages
- you can create your own rpms and customize them per your liking
- compile as I'm sure you are well are of doesn't always work the first time and can be time consuming (both in terms of sysadmin time and server time) and have to be much more technical.

Your point IMHO is somewhat valid for PHP and apache only. All of the supporting modules? No. Most of the support libraries either:
a. come already with the distro and is either current or close to current
b. can get a current package from somewhere to install
c. can create a custom package

All of the package systems that exist out there are just a waste? Sorry but custom compiling is old school. You can also custom compile SRC rpms to your liking and if you wanted to custom compile everything if you wanted. You could choose not even use the packages, then why even use a specific distro? You might as well roll your own and/or use FreeBSD.

The only problems I have had with directadmin is from mysql and exim both precompiled,
Click to expand...

Can you be specific? The mysql rpms from DA are directly from Mysql. I'm not aware of any issue, never had an issue, with any the rpms themselves.

yet no problems with customapache httpd php etc. all compiled. I even use mysqld from ports since it means I am using a compiled version on the box. Also would like to use compiled exim. Customapache and custombuild are both fairly easy to use.
Click to expand...

Easy to use is NOT my point. It has to do with:
- harder to keep updated
- harder to automate updates
- harder to know the state of a server and tje software installed
- harder to keep secure
- harder to make servers consistent

These are all part of what a sysadmin should be doing to keep their system updated and/or secure. While I'm sure most of DAs customers install and forget, I'm also sure they have been hacked, or will be hacked at one point or another. DA's decision to make everything custom compiled makes these items much harder than they need to with today's distros.

If you honestly want to custom compile all your software, fine so be it. My argument of the existing DA setup is while easy to install and hard to maintain is a very valid one. The setup should be:
- use packages first
- if you want custom anything custom compile whatever you want.

While package management is not perfect, it sure the hell beats custom compiling code for everything. If I wanted to do that I might as well turn the clock back 10 years on Unix administration.
 
I can't seem to get this one to install on CentOS 4.6. It fails with:

rfc2047.o(.text+0x384): In function `rfc2047_decode2':
: undefined reference to `libiconv_open'
rfc2047.o(.text+0x44f): In function `rfc2047_decode2':
: undefined reference to `libiconv'
rfc2047.o(.text+0x535): In function `rfc2047_decode2':
: undefined reference to `libiconv_close'
collect2: ld returned 1 exit status
make[1]: *** [exim] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/da_exim-4.69/build-Linux-i386'
make: *** [go] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.49235 (%build)
 
zaphod said:
I can't seem to get this one to install on CentOS 4.6. It fails with:

rfc2047.o(.text+0x384): In function `rfc2047_decode2':
: undefined reference to `libiconv_open'
rfc2047.o(.text+0x44f): In function `rfc2047_decode2':
: undefined reference to `libiconv'
rfc2047.o(.text+0x535): In function `rfc2047_decode2':
: undefined reference to `libiconv_close'
collect2: ld returned 1 exit status
make[1]: *** [exim] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/da_exim-4.69/build-Linux-i386'
make: *** [go] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.49235 (%build)
Click to expand...


that's because the rpm was built on 3 not 4, DA needs to compile this for 4.
 
zaphod said:
That error was from rebuilding the source RPM on CentOS 4.6.
Click to expand...

Yea that happened on 3.9 i386 for me, it's not on 4.6 x86_64 I haven't had the time to investigate closer but I suspect it's a missing rpm. I created a 4.6 x86_64 build without issue I haven't done the rest yet.
 
Thanks for the posts guys. I duplciated the problem as well as it was because of:

EXTRALIBS=-static

which I changed to:

#EXTRALIBS=-static

I've reuploaded the da_exim-4.69-2.src.rpm with the directadmin.com/Makefile, minus the -static compile.

Don't ask my why compiling static breaks that, but it does apparently ;)

John
 
How is it inferior? Please detail this other than making a vast generalizations.
Click to expand...

Keep in mind this was years ago and things may have changed now. But this was my experience. I was using a version of Mandrake when php5 was starting to become popular. Many of my customers were starting to want php5 but this version of Mandrake only had an rpm for php4. I was stuck with php4 because I did not know how to compile it myself at the time. Now because of DA I can always upgrade to the latest php without waiting for RHEL to come out with an rpm for it.

The rpm system at least at that time was inferior to custom compiling.
 
DirectAdmin uses custom compiles rather than RPMs for several reasons. One is that there are distributions supported by DirectAdmin that don't use RPMs and it starts getting to be a lot of work to support multiple package systems.

Another is that if DirectAdmin relied on RPMs and other packages it would be a quite a bit harder to support multiple versions of the same packages.

Jeff
 
I consider it inferior to use precompiled because.

1 - It's possible the precompiled stuff will depend on something that doesnt exist on the server. In other words more dependency problems.
2 - It is not possible to customise the binary, whatever options and compile optimisations were used to make the binary you have to stick with.
3 - Multiple versions would be required eg. php can be compiled against mysql5 or mysql5.1 client libraries but not both at the same time.
4 - The user is reliant on whoever makes the rpms to keep up to date and keep to not making mistakes whilst with the customapache script they just edit the version number and download the tarballs.

The only advantage for pre compiled rpms and packages I can think off is time, there is no wait for compiling but because its quicker it doesnt mean it is easier and you lose so much flexibility.
 
You must log in or register to reply here.
Back
Top