From: Phil S. <al...@ba...> - 2002-04-21 18:20:59
|
On Sun, Apr 21, 2002 at 07:03:54PM +0200, Kern Sibbald wrote: > Hello Phil, > > I didn't make any change, so I'm not sure what is > going on. The "developer" configuration files are > not processed by configure.in, so they will not > have the passwords changed, but > > console.conf > gnome-console.conf > bacula-dir.conf > bacula-sd.conf > bacula-fd.conf > > all should have a randomly hashed password > crammed into them. That's what I thought. For some reason, in the 1.17 I just rebuilt, only gnome-console's password is being hashed. > By the way, I'll apply your configure.in fix > tomorrow or Tuesday, but can you explain to me > how it is different from what I had done and why > you need the eval. In my tests here that was not > necessary. It's not so much that it's doing much *differently*, although it does do some things differently, as that it's doing things in a different order. I'll go through it in detail so that you can see why it needs to be done this way. First of all, your test for whether --prefix has been set by the user is correct. However, by default, sysconfdir is ${prefix}/etc. So, we need to test sysconfdir *before* we set prefix from NONE to '', because if we clear prefix before we set sysconfdir, then we no longer have the ability to distinguish between an unset sysconfdir (${prefix}/etc) and a sysconfdir set by the user to /etc, because if we've already cleared ${prefix}, they both evaluate to /etc. Assuming that --prefix has not been set, then ${prefix} evaluates to NONE. This means that at this moment, if --sysconfdir has not been set, then ${sysconfdir} is ${prefix}/etc, which evaluates to NONE/etc, which we can readily distinguish from a user-set value of /etc. If ${sysconfdir} at this point evaluates to /etc, it's user-set, and we leave it alone. If it evaluates to NONE/etc, it's unset, and we can reset it to /etc/bacula. On the other hand, if we clear ${prefix} first, and *then* test ${sysconfdir}, then the unset value of ${sysconfdir}, ${prefix}/etc, evaluates to /etc, which we cannot distinguish from the user manually setting --sysconfdir=/etc. In this case, if we attempt to reset the default sysconfdir to /etc/bacula if --sysconfdir is unused, we will make it impossible for the user to set --sysconfdir=/etc, because every time he does, we will reset it to /etc/bacula. By testing ${sysconfdir} *before* we clear ${prefix}, we retain the ability to tell whether the user has set --sysconfdir or left it defaulted. Now we come to the case in which the user has set --prefix, but left --sysconfdir to default to ${prefix}/etc. If used in a makefile, ${prefix}/etc will be parsed and expanded by make. However, ${sysconfdir} is also substituted into the bacula and fd scripts, which will *not* evaluate ${prefix}. @sysconfdir@ is replaced with the literal value of ${sysconfdir} without further parsing, which will be ${prefix}/etc. So, if you set a prefix but don't set --sysconfdir, then you end up with ${prefix}/etc in your bacula and fd scripts. To prevent this, we need to eval ${sysconfdir} after we get done testing it, so that the final value gets properly substituted into the bacula and fd scripts. ${sbindir} needs to be eval'd for the same reason, as it also gets substituted into the bacula and fd scripts. (I note, however, that your test-and-reset for ${sbindir} is a NOP, as the code sets it to ${exec_prefix}/sbin only if it is already set to ${exec_prefix}/sbin, and leaves it alone otherwise. This test might as well be deleted, since it does nothing, but the eval needs to stay in.) While we're on the subject of configure, I noticed this morning that --with-pid-dir and --with-subsys-dir appeared to be being ignored. I've just looked at the code for them in configure.in, and they *are* ignored unless the specified directory already exists. So if I set --prefix=/opt/bacula --with-pid-dir=/opt/bacula/run --with-subsys-dir=/opt/bacula/var, expecting /opt/bacula/run and /opt/bacula/var to be created, they both get silently changed to ${sysconfdir}. Since there's no code anywhere in the makefiles to create ${piddir} and ${subsysdir} at installation time, I don't know that these options are useful. -- ********* Fight Back! It may not be just YOUR life at risk. ********* phil stracchino :: al...@ba... :: hal...@so... unix ronin :::: renaissance man :::: mystic zen biker geek 2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold) Linux Now! ...because friends don't let friends use Microsoft. |