cleaner builds and using RPMs instead of custom builds

I have been running yum -y update for 3 years on DA servers with Fedora and CentOS and have not had a problem yet.

With CentOS you probably shouldn't, with Fedora yes. Fedora IMHO isn't meant to run on production machines, unless you want bleeding edge software, with yum updates RPMs that can break, and a short support lifecycle.
 
I didn't want to start a Fedora debate. I already know all of that and it has been discussed in other threads and I have been switching to CentOS ever since I learned about it as the Fedora life cycle ends.

So are you saying I should not use yum with CentOS? But I can use yum with Fedora even though I should not use Fedora at all?
 
I guess I have just been extremely lucky that I have not had any problems at all with automatic updates in 3 years running DA on Fedora and CentOS.
 
So are you saying I should not use yum with CentOS? But I can use yum with Fedora even though I should not use Fedora at all?

No yum should be used. To have it completely automated, well that's up to how you wish to admin your box. For things we do not manage via puppet we get notified of updates and currently manually install.
 
2) I can look into removing /etc/aliases from the config list of the rpm for the setup rpm conflict. Exim does use it, but it's easy enough to not include in the list and the rpm system wouldn't know.

John,

is this a definite? If so when? as I would like to have all servers on the same version of exim and right now can't unless I manually force install on all servers.
 
Ok what I found is that after fully removing all /etc/aliases lines from the exim.spec file, the exim installer *still* installs it, which the rpm system does notice. This breaks the rpm build because any files installed by the program must be reflected in the exim.spec file.

So we do have the option of simply renaming the /etc/aliases to /etc/aliases2 in the Makefile .. but then that would complie a wrong default into the exim binaries which would make it worse.

Unless there are other options I'm not seeing, or even just other "angles" that support the other options, the --force option seems best to me at this time, as the rpm does install and use the /etc/aliases file.

John
 
Ok what I found is that after fully removing all /etc/aliases lines from the exim.spec file, the exim installer *still* installs it, which the rpm system does notice. This breaks the rpm build because any files installed by the program must be reflected in the exim.spec file.
John

Something isn't right then.
Can you send the spec updated file?
 
Just download the src.rpm from our server, type:

rpm -ivh da_exim-4.69-1.src.rpm

and the spec lives in the:
/usr/src/redhat/SPECS/exim.spec

The source of the "installer" that is doing the install anyway is in the tar.gz file:
scripts/exim_install

and uses:
SYSTEM_ALIASES_FILE

from the Local/Makefile (copied from da_exim-Makefile)

Manually changing the exim_install script is an option *however* we do need to make sure the aliases file is installed.. as if we hack it all out, we'd have a missing file for any system without the "setup" rpm.

John
 
Just download the src.rpm from our server, type:

rpm -ivh da_exim-4.69-1.src.rpm

and the spec lives in the:
/usr/src/redhat/SPECS/exim.spec

I'm asking if you didn't modify the .spec file? That's what needs to be done to prevent aliases from getting installed.

In fact this .spec file didn't even compile for me. On one of the rpms I see.

Build Date: Thu Aug 30 22:29:39 2007
Build Host: es4-64.jbmc-software.com

you were able to get this rpm to build properly as is?
 
I have not uploaded anything.

In order to edit the spec, you download the src.rpm, type "rpm -ivh file.src.rpm" and the start editing the spec file. Then once ready type "rpmbuild -ba exim.spec" on that spec file.

I did edit the spec file to not install the /etc/aliases file *however* the exim installer script that is run with the actual exim binary copy also includes the aliases file. It's not done at all by the spec file which is the problem. We could start hacking the exim installer scripts, but I'd rather not.

Was testing on fedora 4.

John
 
I have not uploaded anything.

In order to edit the spec, you download the src.rpm, type "rpm -ivh file.src.rpm" and the start editing the spec file. Then once ready type "rpmbuild -ba exim.spec" on that spec file.

I did edit the spec file to not install the /etc/aliases file *however* the exim installer script that is run with the actual exim binary copy also includes the aliases file. It's not done at all by the spec file which is the problem. We could start hacking the exim installer scripts, but I'd rather not.
John

Yes I fully understand how to build rpms and created many for ous. I don't need that info. Thanks..

I get this in the build process
Code:
+ mv doc/exim.8 /var/tmp/buildexim.fG5iR2/da_exim-4.69-root//usr/share/man/man8/exim.8
+ for i in blacklist_domains whitelist_from use_rbl_domains bad_sender_hosts blacklist_senders whitelist_domains whitelist_hosts whitelist_senders
+ touch /etc/virtual/blacklist_domains
touch: cannot touch `/etc/virtual/blacklist_domains': No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.46639 (%install)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.46639 (%install)

This is on a machine that does not have DA already installed. I assume DA created this part of the script? this part of it is the issue:
Code:
        touch /etc/virtual/$i;
        chown mail:mail /etc/virtual/$i;
        chmod 644 /etc/virtual/$i;

there are all sorts of references to the root file system which is a RPM spec no no.

You are referring to files that haven't been built yet. In fact when creating RPMs they should be created as a non-root user in a non root setup (it catches things like this)
 
DA creates the /etc/virtual directory ahead of time.

John

:confused: ? Either rpms by default should either depend upon another rpm or should have the dependencies built into the rpm itself. This can be part of the build process, or install.

ie this rpm specifically should create /etc/virtual folder if it doesn't already exist. I can add it to this spec file.

this is then explains why I'm not getting clean build and you are. the rpm spec file would never build properly in a normal situation. rpms shouldn't assume anything.
 
this is how the tail end of the spec file should look

Code:
mkdir -p ${RPM_BUILD_ROOT}/etc/virtual
for i in blacklist_domains whitelist_from use_rbl_domains bad_sender_hosts blacklist_senders whitelist_domains whitelist_hosts whitelist_senders; do
        touch ${RPM_BUILD_ROOT}/etc/virtual/$i;
        chown mail:mail ${RPM_BUILD_ROOT}/etc/virtual/$i;
        chmod 644 ${RPM_BUILD_ROOT}/etc/virtual/$i;
done
mkdir -p ${RPM_BUILD_ROOT}/etc/virtual/usage
chown mail:mail ${RPM_BUILD_ROOT}/etc/virtual/usage
chmod 600 ${RPM_BUILD_ROOT}/etc/virtual/usage
if [ ! -e ${RPM_BUILD_ROOT}/etc/virtual/limit ]; then
        echo "0" > ${RPM_BUILD_ROOT}/etc/virtual/limit
        chmod 644 ${RPM_BUILD_ROOT}/etc/virtual/limit
        chown mail:mail ${RPM_BUILD_ROOT}/etc/virtual/limit
fi

note all of the ${RPM_BUILD_ROOT} added. These were never in the rpm and in fact then need to be add to the list of config files this rpm knows about.
 
Here are the diffs to the orginal spec file. I have not tested this out completely but basics are there and the aliases file is no longer there.

Code:
[root@devcentos46 SPECS]# rpm -q -f /etc/aliases 
setup-2.5.37-1.3
[root@devcentos46 SPECS]# rpm -ivh /usr/src/redhat/RPMS/x86_64/da_exim-4.69-1.x86_64.rpm
Preparing...                ########################################### [100%]
   1:da_exim                ########################################### [100%]


Code:
[root@devcentos46 SPECS]# diff exim.spec da_exim.spec 
19c19
< BuildRoot: /var/tmp/buildexim.fG5iR2/%{name}-%{version}-root
---
> BuildRoot: /var/tmp/%{name}-%{version}-root
37a38
> %{__rm} -rf ${RPM_BUILD_ROOT}
47c48
< cp src/aliases.default ${RPM_BUILD_ROOT}/etc/aliases
---
> #cp src/aliases.default ${RPM_BUILD_ROOT}/etc/aliases
63a65
> mkdir -p ${RPM_BUILD_ROOT}/etc/virtual
65,67c67,69
<       touch /etc/virtual/$i;
<       chown mail:mail /etc/virtual/$i;
<       chmod 644 /etc/virtual/$i;
---
>       touch ${RPM_BUILD_ROOT}/etc/virtual/$i;
>       chown mail:mail ${RPM_BUILD_ROOT}/etc/virtual/$i;
>       chmod 644 ${RPM_BUILD_ROOT}/etc/virtual/$i;
69,75c71,77
< mkdir -p /etc/virtual/usage
< chown mail:mail /etc/virtual/usage
< chmod 600 /etc/virtual/usage
< if [ ! -e /etc/virtual/limit ]; then 
<       echo "0" > /etc/virtual/limit
<       chmod 644 /etc/virtual/limit
<       chown mail:mail /etc/virtual/limit
---
> mkdir -p ${RPM_BUILD_ROOT}/etc/virtual/usage
> chown mail:mail ${RPM_BUILD_ROOT}/etc/virtual/usage
> chmod 600 ${RPM_BUILD_ROOT}/etc/virtual/usage
> if [ ! -e ${RPM_BUILD_ROOT}/etc/virtual/limit ]; then 
>       echo "0" > ${RPM_BUILD_ROOT}/etc/virtual/limit
>       chmod 644 ${RPM_BUILD_ROOT}/etc/virtual/limit
>       chown mail:mail ${RPM_BUILD_ROOT}/etc/virtual/limit
84c86
< %config(noreplace) /etc/aliases
---
> #%config(noreplace) /etc/aliases
88a91
> %config(noreplace) /etc/virtual/*
 
How did you get da_exim 4.69-1 to compile on centos/RHEL 3.9?

I get a missing lib
Code:
....
gcc dkim-exim.c
 
awk '{ print ($1+1) }' cnumber.h > cnumber.temp
rm -f cnumber.h; mv cnumber.temp cnumber.h
gcc version.c
rm -f exim
gcc -o exim
rfc2047.o(.text+0x38f): In function `rfc2047_decode2':
: undefined reference to `libiconv_open'
rfc2047.o(.text+0x45c): In function `rfc2047_decode2':
: undefined reference to `libiconv'
rfc2047.o(.text+0x548): 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.74639 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.74639 (%build)
 
Blindly running yum -y update is bad practice, IMHO - especially given RHEL OS and DA's propensity to change the exclude line in most updates. If one package installs that shouldn't - you won't know it till after the update completes - and by then, it'll take you hours to recover from the mistake.
We've never seen DirectAdmin modify the the exclude line in yum. Can you document any particular update that has?

Jeff
 
And just for the record, I'd love it if DirectAdmin were restricted to only one OS distribution, but of course that's because they and I happen to like the same one.

We're currently switching to:

nightly yum updates
and
custombuild, manually, about once a month

and so far that's working for us on relatively simple CentOS installations.

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.

Jeff
 
Back
Top