Florian Haas wrote:
On 11/19/2009 03:53 PM, Eelco Jepkema wrote:
With 8.3.5 source tarball I could just do 'make; make install' and
everything would be fine. I would get sane defaults, files in expected
locations (config in /etc, libs in /usr/lib/drbd, man pages in
/usr/share/man, local state in /var/lib/drbd etc.).
Except that few if any of these defaults were FHS compliant, not to
mention that they weren't configurable.
True, i don't want to go back :).
With 8.3.6 however you'll need to run the configure script. Doing this
it's really hard to get the defaults of before back and just running
'./configure' will forget or not create certain directories.
"Certain directories" isn't helping much here. Be specific. Which ones?
Those would be the ones noted below.
Attached is the output for just running ./configure without any options
and the config.log that belongs to that.
Both of which look fine.
You are right if you mean by fine, it did its work without an error
message. However, if you do this you end up with a drbdadm that gives
warnings about symlinks to /var/lib/drbd on every command. I haven't
tested the other userland tools for this but i don't count a binary that
gives a warning on every use to belong in the category 'fine'.
running 'make -C user install':
mkdir -p //usr/local/var/lib/drbd
#1, you're not supposed to do that. Using "make -C user install"
installs only the userland binaries which is perfectly fine if you build
an appliance and you know exactly how your home-rolled management
utilities will manage DRBD, but most users will also want the
integration scripts found in scripts/, so you should simply run "make
install" from the top of the extracted tarball. Or, actually "sudo make
install" as it's generally a good idea to not build as root.
I know this installs the userland tools, I didn't do this by hand.
running 'make install' on drbd source root as you describe did this, I
just explained here where the error was, not the actual command i used.
I thought I would highlight the problems i found from the make install
output I added to my original message.
#2, that mkdir is fine as it uses a correct default localstatedir path.
Well, yes and no. Yes, it creates the path as stated in the Makefiles as
localstatedirpath but, since I mentioned that some sourcecode is
hardwired to /var/lib/drbd, this localstatedirpath will, as far as I can
tell, not be used by anything.
running 'make -C scripts install':
mkdir -p //usr/local/lib/ocf/resource.d/linbit
While the correct directory seems to be /usr/lib/ocf/resource.d/ (at
least on my system).
I'll have to check the OCF standard on that. My hunch is that both
/usr/lib/ocf and /usr/local/lib/ocf are permissible in which case the
default would be correct (being in line with both OCF and FHS), but if
OCF does mandate /usr/lib/ocf specifically, we'll correct this.
Furthermore, the default for creating a kernel module, WITH_KM, is set
to no by configure. I'm not sure if having kernel module not compiled by
default is something users would expect from drbd source.
As you may have noticed, DRBD is headed for being merged into the
mainline kernel, at which point building the out of tree module becomes
obsolete. That's the reason why we created the separate configure
option, and also set its default to "no".
Ah, that is even better. That is a good reason for a default of no.
Ultimately, i'm not a fan of installing to /usr/local/etc et.al because
i don't believe many tools will be able to use them correctly?
Use --prefix=/usr.
Debian
init script fixer update-rc.d for instance won't find the drbd init
script in /usr/local/etc/init.d/drbd. I would think the defaults for
this would rather be just normal /etc and /etc/init.d.
Use --sysconfdir=/etc.
I know I can override the defaults, however, I was thinking that doing...
./configure; make all; make install
...would and should at least be likely (I know its not possible to
account for all situations) to leave functioning software that wouldn't
need tinkering one way or the other. With the /var/lib/drbd references
in source fixed that should be possible though so we'll leave it at that.
Best regards,
Eelco Jepkema
_______________________________________________
drbd-user mailing list
[email protected]
http://lists.linbit.com/mailman/listinfo/drbd-user
