Mailing List Archive: Packaging drbd, heartbeat, FHS

Packaging drbd, heartbeat, FHS

Nov 8, 2000, 7:35 PM

Post #1 of 6 (1820 views)

Hi all,

We are making SuSE packages for drbd. But there are some changes needed
to integrate with other parts of our setup. One issue is that we are
trying very hard to be fully FHS compliant. Also the current drbd
installation makes some assumptions about what else is on the system.
Finally, it is not quite distribution neutral.

I have thought about this a bit and come up with a couple comments and
a proposal.

Tieing drbd to "/etc/ha.d/resource.d/" is too much a dependancy on heartbeat,
so I would prefer to not do that. And "/etc/sysconfig/" is a Redhat path.

The "drbd[0-9]" config files could go happily into /etc/drbd.d/ as far as I
care. My long term intent is to merge them all into one file anyway, maybe
"/etc/drbdtab", but that is not for today.

That leaves "datadisk", which is sortof like a sysVinit script, but is
really a HA resource script. But, it seems generally useful too. So I
propose we put it with the other drbd binary "/usr/sbin/drbdsetup".
I always end up making a symlink to it in /usr/sbin anyway. If we do
that, then the name "datadisk" is slightly confusing, so maybe it wants
a rename, maybe to "drbddisk" or even better, "drbd-control".

However, since drbd is used to support block devices, the drbd tools
(drbdsetup, datadisk/drbd-control) really should be in /sbin to allow
for /usr to be unavailable and to be FHS compliant.

Finally, there is the init script in "/sbin/init.d/drbd" used at boot time
to load and configure the module. On SuSE it is also symlinked
to "/sbin/rcdrbd".

To summarize, after some thought and debate I think we want to install
drbd like this:

/etc/drbd.d/drbd[0-9]+ # drbd device configuration
/sbin/init.d/drbd # sysV init script to configure drbd devices
/sbin/rcdrbd -> /sbin/init.d/drbd # symlink

/sbin/drbdsetup # binary that does the actual ioctls() to
# configure drbd
/sbin/drbd-control # script to control drbd state, eg primary vs
# secondary, master vs slave etc (was datadisk)

Comments?

-dg

--
David Gould dg@example.com
SuSE, Inc., 580 2cd St. #210, Oakland, CA 94607 510.628.3380
"I personally think Unix is "superior" because on LSD it tastes
like Blue." -- jbarnett

Re: Packaging drbd, heartbeat, FHS [ In reply to ]

lmb at example

Nov 9, 2000, 1:13 AM

Post #2 of 6 (1805 views)

Permalink

On 2000-11-08T18:35:16,
David Gould <dg@example.com> said:

> /etc/drbd.d/drbd[0-9]+ # drbd device configuration
> /sbin/init.d/drbd # sysV init script to configure drbd devices
> /sbin/rcdrbd -> /sbin/init.d/drbd # symlink

This last one is SuSE-specific, those symlinks don't exist on other
distributions. We can keep that one private to the SuSE RPM.

> /sbin/drbdsetup # binary that does the actual ioctls() to
> # configure drbd
> /sbin/drbd-control # script to control drbd state, eg primary vs
> # secondary, master vs slave etc (was datadisk)
>
> Comments?

Sounds good to me.

Sincerely,
Lars Marowsky-Brée <lmb@example.com>
Development HA

--
Perfection is our goal, excellence will be tolerated. -- J. Yahl

Re: Packaging drbd, heartbeat, FHS [ In reply to ]

thomas.mangin at example

Nov 9, 2000, 2:37 AM

Post #3 of 6 (1803 views)

Permalink

> We are making SuSE packages for drbd. But there are some changes needed
> to integrate with other parts of our setup. One issue is that we are
> trying very hard to be fully FHS compliant. Also the current drbd
> installation makes some assumptions about what else is on the system.
> Finally, it is not quite distribution neutral.
>
> I have thought about this a bit and come up with a couple comments and
> a proposal.
>
> Tieing drbd to "/etc/ha.d/resource.d/" is too much a dependancy on
heartbeat,
> so I would prefer to not do that. And "/etc/sysconfig/" is a Redhat path.

if you look the cvs script I encoded /etc/ha.d/resource.d/ in a variable.
Just change it and all the script must work fine.

For "/etc/sysconfig/" I only used Debian, Mandrake and RH - I have no clue
how SUSE init works ..

> The "drbd[0-9]" config files could go happily into /etc/drbd.d/ as far as
I
> care. My long term intent is to merge them all into one file anyway, maybe
> "/etc/drbdtab", but that is not for today.

I see not reason why it can not be done. I can add that to my todo list
for today (which tend to become next week ;*)...

> That leaves "datadisk", which is sortof like a sysVinit script, but is
> really a HA resource script. But, it seems generally useful too. So I
> propose we put it with the other drbd binary "/usr/sbin/drbdsetup".
> I always end up making a symlink to it in /usr/sbin anyway. If we do
> that, then the name "datadisk" is slightly confusing, so maybe it wants
> a rename, maybe to "drbddisk" or even better, "drbd-control".

Gotcha ! The CVS changed a lot of thing. It seems you are speaking of the
current stable code I don't know when philipp plan to release the next
version but using the CVS may make a lot of sense, mainly for heartbeat.

The only point is that the script now rely on a "drbd-commun" file.
Putting this file in a sbin directory isn't really clean ..

> However, since drbd is used to support block devices, the drbd tools
> (drbdsetup, datadisk/drbd-control) really should be in /sbin to allow
> for /usr to be unavailable and to be FHS compliant.

I agree with that. But /etc is part of the / partition too so leaving it
here and siply symbolicly linking them must do ?

> Finally, there is the init script in "/sbin/init.d/drbd" used at boot time
> to load and configure the module. On SuSE it is also symlinked
> to "/sbin/rcdrbd".

The drbd script is used to load/initialise the module.
datadisk to setup the node function (slave/master)

> To summarize, after some thought and debate I think we want to install
> drbd like this:
>
> /etc/drbd.d/drbd[0-9]+ # drbd device configuration
> /sbin/init.d/drbd # sysV init script to configure drbd devices
> /sbin/rcdrbd -> /sbin/init.d/drbd # symlink
>
> /sbin/drbdsetup # binary that does the actual ioctls() to
> # configure drbd
> /sbin/drbd-control # script to control drbd state, eg primary
vs
> # secondary, master vs slave etc (was
datadisk)
>
> Comments?

See before ;*)

Re: Packaging drbd, heartbeat, FHS [ In reply to ]

dg at example

Nov 9, 2000, 3:14 AM

Post #4 of 6 (1811 views)

Permalink

On Thu, Nov 09, 2000 at 09:37:44AM -0000, Thomas Mangin wrote:
>
> if you look the cvs script I encoded /etc/ha.d/resource.d/ in a variable.
> Just change it and all the script must work fine.

I will look. For package purposes, we tend to use the stable versions though.

> For "/etc/sysconfig/" I only used Debian, Mandrake and RH - I have no clue
> how SUSE init works ..

Right, we get to worry about that. But there is no /etc/sysconfig in SuSE
at the moment, so a /etc/drbd.d would be neutral.

> The only point is that the script now rely on a "drbd-commun" file.
> Putting this file in a sbin directory isn't really clean ..

I saw this, and am not sure how I think about it without a closer look.
It really seems to be there to support the "old" scripts vs the "new"
scripts. But it is one more thing that needs a hardcoded path, and
I am not sure I see the necessity.

> I agree with that. But /etc is part of the / partition too so leaving it
> here and siply symbolicly linking them must do ?

Because according to FHS /etc is not for binaries and scripts, that
is /sbin or /usr/bin. In drbd's case, /sbin is preferred. Which leaves no

> > Finally, there is the init script in "/sbin/init.d/drbd" used at boot time
> > to load and configure the module. On SuSE it is also symlinked
> > to "/sbin/rcdrbd".
>
> The drbd script is used to load/initialise the module.
> datadisk to setup the node function (slave/master)

Yes, we agree about what they do. That is fine. But for us to make rpms,
need to decide about paths and names. And we (SuSE) need to worry about
FHS and about not changing it too often, and about not being too different
from the package from the drbd team.

> > To summarize, after some thought and debate I think we want to install
> > drbd like this:
> >
> > /etc/drbd.d/drbd[0-9]+ # drbd device configuration
> > /sbin/init.d/drbd # sysV init script to configure drbd devices
> > /sbin/rcdrbd -> /sbin/init.d/drbd # symlink
> >
> > /sbin/drbdsetup # binary that does the actual ioctls() to
> > # configure drbd
> > /sbin/drbd-control # script to control drbd state, eg primary
> vs
> > # secondary, master vs slave etc (was
> datadisk)
> >
> > Comments?
>
> See before ;*)

You didn't hit a couple of points:
- rename datadisk to drbd-control
- and move it to /sbin
- move drbd? to /etc/drbd.d from /etc/ha.d/resource.d. I am trying to
make drbd independant of heartbeat so it can be used with kimberlite
and failsafe and standalone. It is nice that you created a variable, but
if we can avoid extra patching and make our package agree with the
drbd website (or the other way round ;-) that would be easier for
everyone.

Regards

-dg

--
David Gould dg@example.com
SuSE, Inc., 580 2cd St. #210, Oakland, CA 94607 510.628.3380
"I personally think Unix is "superior" because on LSD it tastes
like Blue." -- jbarnett

Re: Packaging drbd, heartbeat, FHS [ In reply to ]

philipp at example

Nov 13, 2000, 8:53 AM

Post #5 of 6 (1803 views)

Permalink

* David Gould <dg@example.com> [001109 03:35]:
>
> Hi all,
>
> We are making SuSE packages for drbd. But there are some changes needed
> to integrate with other parts of our setup. One issue is that we are
> trying very hard to be fully FHS compliant. Also the current drbd
> installation makes some assumptions about what else is on the system.
> Finally, it is not quite distribution neutral.
>
> I have thought about this a bit and come up with a couple comments and
> a proposal.
>
> Tieing drbd to "/etc/ha.d/resource.d/" is too much a dependancy on heartbeat,

Hmmm, I like it that way. -- maybe we will end up with these packets:

drbd
heartbeat
failsave
drbd-heartbeat-glue
dbbd-failsave-glue

> so I would prefer to not do that. And "/etc/sysconfig/" is a Redhat path.

That's true.

>
> The "drbd[0-9]" config files could go happily into /etc/drbd.d/ as far as I

I prefer /etc/ha.d/drbd.d.
Is "ha.d" for heartbeat or is it for high-availability ?

> care. My long term intent is to merge them all into one file anyway, maybe
> "/etc/drbdtab", but that is not for today.
>

If you do the patch ...

> That leaves "datadisk", which is sortof like a sysVinit script, but is
> really a HA resource script. But, it seems generally useful too. So I
> propose we put it with the other drbd binary "/usr/sbin/drbdsetup".
> I always end up making a symlink to it in /usr/sbin anyway. If we do
> that, then the name "datadisk" is slightly confusing, so maybe it wants
> a rename, maybe to "drbddisk" or even better, "drbd-control".
>

drbd-disk ?

> However, since drbd is used to support block devices, the drbd tools
> (drbdsetup, datadisk/drbd-control) really should be in /sbin to allow
> for /usr to be unavailable and to be FHS compliant.
>
> Finally, there is the init script in "/sbin/init.d/drbd" used at boot time
> to load and configure the module. On SuSE it is also symlinked
> to "/sbin/rcdrbd".
>
> To summarize, after some thought and debate I think we want to install
> drbd like this:
>
> /etc/drbd.d/drbd[0-9]+ # drbd device configuration
> /sbin/init.d/drbd # sysV init script to configure drbd devices
> /sbin/rcdrbd -> /sbin/init.d/drbd # symlink
>
> /sbin/drbdsetup # binary that does the actual ioctls() to
> # configure drbd
> /sbin/drbd-control # script to control drbd state, eg primary vs
> # secondary, master vs slave etc (was datadisk)
>
> Comments?

I do not know what do you think about open source, but what's
about having all your spec files etc... in the drbd repository?

I will do the stuff for a .deb packet sooner or later :)

-Philipp

Re: Packaging drbd, heartbeat, FHS [ In reply to ]

lmb at example

Nov 13, 2000, 9:09 AM

Post #6 of 6 (1797 views)

Permalink

On 2000-11-13T16:53:54,
Philipp Reisner <philipp@example.com> said:

> > The "drbd[0-9]" config files could go happily into /etc/drbd.d/ as far as
> I prefer /etc/ha.d/drbd.d. Is "ha.d" for heartbeat or is it for
> high-availability ?

/etc/ha.d/ is currently "owned" by the heartbeat RPM, so it is indeed a
dependency on heartbeat.

/etc/drbd(.d)/ would probably be a better choice indeed, as drbd itself
doesn't rely on heartbeat, FailSafe, Kimberlite, piranha or whatever.

> I do not know what do you think about open source, but what's
> about having all your spec files etc... in the drbd repository?

Sure, no problem - but we don't want to have these paths differ between the
different distributions, so we should try to agree on something here.

We can easily check in the suse.spec file as soon as we finished it ;-)

Sincerely,
Lars Marowsky-Brée <lmb@example.com>
Development HA

--
Perfection is our goal, excellence will be tolerated. -- J. Yahl