Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Serveur with encrypted partition : 2 steps boot.
8 views
Skip to first unread message
Erwan David
Apr 11, 2013, 1:50:01 AM4/11/13
to
Hi,
I need to setup a distant server where some services store their data
on an encrypted disk. I'd like to be able to reboot server, which
should then start a minimal set of services (including ssh), which
would allow me to then mount the encrypted disk through an ssh
connection, and start the services which need the encrypted disk to be
mounted.
I'd like to do it in a way which would not disturb standard debian
tools nor packages upgrade.
My solutions so far are :
1) use a centos/fedora, where I can have services not automatically
started at boot which I can start manually through
service myserv start (it generally do not work in debian since
/etc/init.d.myserv will check in /etc/default wether to start service
or not)
2) add at the beginning of each /etc/init.d/myserv a test to stop if
the encrypted partition is not mounted
Neither of those solutions seems acceptable for me.
So if someone has an idea, I'm listening.
Thanks everybody.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2013041105...@rail.eu.org
I need to setup a distant server where some services store their data
on an encrypted disk. I'd like to be able to reboot server, which
should then start a minimal set of services (including ssh), which
would allow me to then mount the encrypted disk through an ssh
connection, and start the services which need the encrypted disk to be
mounted.
I'd like to do it in a way which would not disturb standard debian
tools nor packages upgrade.
My solutions so far are :
1) use a centos/fedora, where I can have services not automatically
started at boot which I can start manually through
service myserv start (it generally do not work in debian since
/etc/init.d.myserv will check in /etc/default wether to start service
or not)
2) add at the beginning of each /etc/init.d/myserv a test to stop if
the encrypted partition is not mounted
Neither of those solutions seems acceptable for me.
So if someone has an idea, I'm listening.
Thanks everybody.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2013041105...@rail.eu.org
Bob Proulx
Apr 11, 2013, 2:30:01 AM4/11/13
to
Erwan David wrote:
> 2) add at the beginning of each /etc/init.d/myserv a test to stop if
> the encrypted partition is not mounted
>
> Neither of those solutions seems acceptable for me.
>
> So if someone has an idea, I'm listening.
I would do one of two things. Either I would remove the /etc/rc?.d/S*
> 2) add at the beginning of each /etc/init.d/myserv a test to stop if
> the encrypted partition is not mounted
>
> Neither of those solutions seems acceptable for me.
>
> So if someone has an idea, I'm listening.
links associated with the services you don't want to start, or make
the script not executable. Then start them manually later as you
wish. Or I would install a /usr/sbin/policy-rc.d script that did your
automated check and only allowed the services to start if the disk was
mounted as you wish.
See the man page for invoke-rc.d for the first pass documentation.
Then read the README.policy-rc.d.gz file.
man invoke-rc.d
less /usr/share/doc/sysv-rc/README.policy-rc.d.gz
There is a huge amount of flexibility built into policy-rc.d that most
people will never need nor use. This makes the documentation a little
bit overdone. I will include a simple one that I am using at the
bottom so that you can get the feel for it. In my case this is for a
chroot and I only want to allow cron and nullmailer to start there.
All other daemons are denied. For your case you would want the
reverse and generally allow everything but exclude only the ones you
want to exclude.
Bob
#!/bin/sh
# /usr/sbin/policy-rc.d [options] <initscript ID> <actions> [<runlevel>]
# /usr/sbin/policy-rc.d [options] --list <initscript ID> [<runlevel> ...]
# See /usr/share/doc/sysv-rc/README.policy-rc.d for documentation.
# Live example scraped from ps:
# /bin/sh /usr/sbin/policy-rc.d x11-common stop unknown
while [ $# -gt 0 ]; do
case $1 in
--list) exit 101 ;;
--quiet) shift ;;
-*) shift ;;
cron) exit 0 ;;
nullmailer) exit 0 ;;
*) exit 101 ;;
esac
done
exit 101
Erwan David
Apr 11, 2013, 3:30:02 AM4/11/13
to
On Thu, Apr 11, 2013 at 08:25:56AM CEST, Bob Proulx <b...@proulx.com> said:
> Erwan David wrote:
> > 2) add at the beginning of each /etc/init.d/myserv a test to stop if
> > the encrypted partition is not mounted
> >
> > Neither of those solutions seems acceptable for me.
> >
> > So if someone has an idea, I'm listening.
>
> I would do one of two things. Either I would remove the /etc/rc?.d/S*
> links associated with the services you don't want to start, or make
> the script not executable. Then start them manually later as you
> wish. Or I would install a /usr/sbin/policy-rc.d script that did your
> automated check and only allowed the services to start if the disk was
> mounted as you wish.
>
> See the man page for invoke-rc.d for the first pass documentation.
> Then read the README.policy-rc.d.gz file.
Thanks, I was not aware of policy-rc.d, which seems to be exactly what I need.
> Erwan David wrote:
> > 2) add at the beginning of each /etc/init.d/myserv a test to stop if
> > the encrypted partition is not mounted
> >
> > Neither of those solutions seems acceptable for me.
> >
> > So if someone has an idea, I'm listening.
>
> I would do one of two things. Either I would remove the /etc/rc?.d/S*
> links associated with the services you don't want to start, or make
> the script not executable. Then start them manually later as you
> wish. Or I would install a /usr/sbin/policy-rc.d script that did your
> automated check and only allowed the services to start if the disk was
> mounted as you wish.
>
> See the man page for invoke-rc.d for the first pass documentation.
> Then read the README.policy-rc.d.gz file.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Erwan David
Apr 11, 2013, 3:00:02 PM4/11/13
to
Le 11/04/2013 20:53, Rick Thomas a écrit :
> with its own set of services? I'll bet you can use this to do what
> you want...
>
> Rick
>
>
You mean booting in level 2, where dovecot, postgresql, etc. are not
started (but ssh is), then after giving the decryption key and mounting
the encrypted partition switching to runlevel 3 where they are started ?
Indeed it may also be a good solution.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/516707F2...@rail.eu.org
>
> On Apr 11, 2013, at 12:22 AM, Erwan David wrote:
>
>> On Thu, Apr 11, 2013 at 08:25:56AM CEST, Bob Proulx <b...@proulx.com>
>> said:
>>> Erwan David wrote:
>>>> 2) add at the beginning of each /etc/init.d/myserv a test to stop if
>>>> the encrypted partition is not mounted
>>>>
>>>> Neither of those solutions seems acceptable for me.
>>>>
>>>> So if someone has an idea, I'm listening.
>>>
>>> I would do one of two things. Either I would remove the /etc/rc?.d/S*
>>> links associated with the services you don't want to start, or make
>>> the script not executable. Then start them manually later as you
>>> wish. Or I would install a /usr/sbin/policy-rc.d script that did your
>>> automated check and only allowed the services to start if the disk was
>>> mounted as you wish.
>>>
>>> See the man page for invoke-rc.d for the first pass documentation.
>>> Then read the README.policy-rc.d.gz file.
>>
>> Thanks, I was not aware of policy-rc.d, which seems to be exactly
>> what I need.
>
> Are you aware that init supports multiple run-levels (man 8 init) each
> On Apr 11, 2013, at 12:22 AM, Erwan David wrote:
>
>> On Thu, Apr 11, 2013 at 08:25:56AM CEST, Bob Proulx <b...@proulx.com>
>> said:
>>> Erwan David wrote:
>>>> 2) add at the beginning of each /etc/init.d/myserv a test to stop if
>>>> the encrypted partition is not mounted
>>>>
>>>> Neither of those solutions seems acceptable for me.
>>>>
>>>> So if someone has an idea, I'm listening.
>>>
>>> I would do one of two things. Either I would remove the /etc/rc?.d/S*
>>> links associated with the services you don't want to start, or make
>>> the script not executable. Then start them manually later as you
>>> wish. Or I would install a /usr/sbin/policy-rc.d script that did your
>>> automated check and only allowed the services to start if the disk was
>>> mounted as you wish.
>>>
>>> See the man page for invoke-rc.d for the first pass documentation.
>>> Then read the README.policy-rc.d.gz file.
>>
>> Thanks, I was not aware of policy-rc.d, which seems to be exactly
>> what I need.
>
> with its own set of services? I'll bet you can use this to do what
> you want...
>
> Rick
>
>
You mean booting in level 2, where dovecot, postgresql, etc. are not
started (but ssh is), then after giving the decryption key and mounting
the encrypted partition switching to runlevel 3 where they are started ?
Indeed it may also be a good solution.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Rick Thomas
Apr 11, 2013, 3:00:02 PM4/11/13
to
On Apr 11, 2013, at 12:22 AM, Erwan David wrote:
> On Thu, Apr 11, 2013 at 08:25:56AM CEST, Bob Proulx <b...@proulx.com>
> said:
>> Erwan David wrote:
>>> 2) add at the beginning of each /etc/init.d/myserv a test to stop if
>>> the encrypted partition is not mounted
>>>
>>> Neither of those solutions seems acceptable for me.
>>>
>>> So if someone has an idea, I'm listening.
>>
>> I would do one of two things. Either I would remove the /etc/rc?.d/
>> S*
>> links associated with the services you don't want to start, or make
>> the script not executable. Then start them manually later as you
>> wish. Or I would install a /usr/sbin/policy-rc.d script that did
>> your
>> automated check and only allowed the services to start if the disk
>> was
>> mounted as you wish.
>>
>> See the man page for invoke-rc.d for the first pass documentation.
>> Then read the README.policy-rc.d.gz file.
>
> Thanks, I was not aware of policy-rc.d, which seems to be exactly
> what I need.
> said:
>> Erwan David wrote:
>>> 2) add at the beginning of each /etc/init.d/myserv a test to stop if
>>> the encrypted partition is not mounted
>>>
>>> Neither of those solutions seems acceptable for me.
>>>
>>> So if someone has an idea, I'm listening.
>>
>> I would do one of two things. Either I would remove the /etc/rc?.d/
>> S*
>> links associated with the services you don't want to start, or make
>> the script not executable. Then start them manually later as you
>> wish. Or I would install a /usr/sbin/policy-rc.d script that did
>> your
>> automated check and only allowed the services to start if the disk
>> was
>> mounted as you wish.
>>
>> See the man page for invoke-rc.d for the first pass documentation.
>> Then read the README.policy-rc.d.gz file.
>
> Thanks, I was not aware of policy-rc.d, which seems to be exactly
> what I need.
Are you aware that init supports multiple run-levels (man 8 init) each
with its own set of services? I'll bet you can use this to do what
you want...
Rick
with its own set of services? I'll bet you can use this to do what
you want...
Rick
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/701059D1-4FA8-4473...@pobox.com
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Rick Thomas
Apr 12, 2013, 12:20:02 AM4/12/13
to
Enjoy!
Rick
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Erwan David
Apr 12, 2013, 4:00:02 AM4/12/13
to
On Fri, Apr 12, 2013 at 06:12:55AM CEST, Rick Thomas <rbth...@pobox.com> said:
> >You mean booting in level 2, where dovecot, postgresql, etc. are
> >not started (but ssh is), then after giving the decryption key and
> >mounting the encrypted partition switching to runlevel 3 where they
> >are started ?
> >
> >Indeed it may also be a good solution.
>
> Yup. I thought so too.
>
> Enjoy!
>
And which method is more likely to resist a transition of debian to systemd ?
> >You mean booting in level 2, where dovecot, postgresql, etc. are
> >not started (but ssh is), then after giving the decryption key and
> >mounting the encrypted partition switching to runlevel 3 where they
> >are started ?
> >
> >Indeed it may also be a good solution.
>
> Yup. I thought so too.
>
> Enjoy!
>
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Chris Bannister
Apr 12, 2013, 11:10:02 AM4/12/13
to
On Fri, Apr 12, 2013 at 09:53:17AM +0200, Erwan David wrote:
> On Fri, Apr 12, 2013 at 06:12:55AM CEST, Rick Thomas <rbth...@pobox.com> said:
> > >You mean booting in level 2, where dovecot, postgresql, etc. are
> > >not started (but ssh is), then after giving the decryption key and
> > >mounting the encrypted partition switching to runlevel 3 where they
> > >are started ?
> > >
> > >Indeed it may also be a good solution.
> >
> > Yup. I thought so too.
> >
> > Enjoy!
> >
>
> And which method is more likely to resist a transition of debian to systemd ?
Humour?
> On Fri, Apr 12, 2013 at 06:12:55AM CEST, Rick Thomas <rbth...@pobox.com> said:
> > >You mean booting in level 2, where dovecot, postgresql, etc. are
> > >not started (but ssh is), then after giving the decryption key and
> > >mounting the encrypted partition switching to runlevel 3 where they
> > >are started ?
> > >
> > >Indeed it may also be a good solution.
> >
> > Yup. I thought so too.
> >
> > Enjoy!
> >
>
> And which method is more likely to resist a transition of debian to systemd ?
--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing." --- Malcolm X
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Erwan David
Apr 12, 2013, 4:00:03 PM4/12/13
to
Le 12/04/2013 17:00, Chris Bannister a écrit :
> On Fri, Apr 12, 2013 at 09:53:17AM +0200, Erwan David wrote:
>> On Fri, Apr 12, 2013 at 06:12:55AM CEST, Rick Thomas <rbth...@pobox.com> said:
>>>> You mean booting in level 2, where dovecot, postgresql, etc. are
>>>> not started (but ssh is), then after giving the decryption key and
>>>> mounting the encrypted partition switching to runlevel 3 where they
>>>> are started ?
>>>>
>>>> Indeed it may also be a good solution.
>>> Yup. I thought so too.
>>>
>>> Enjoy!
>>>
>> And which method is more likely to resist a transition of debian to systemd ?
> Humour?
>
No, a concern, because I'd like to do something which resists upgrade,
> On Fri, Apr 12, 2013 at 09:53:17AM +0200, Erwan David wrote:
>> On Fri, Apr 12, 2013 at 06:12:55AM CEST, Rick Thomas <rbth...@pobox.com> said:
>>>> You mean booting in level 2, where dovecot, postgresql, etc. are
>>>> not started (but ssh is), then after giving the decryption key and
>>>> mounting the encrypted partition switching to runlevel 3 where they
>>>> are started ?
>>>>
>>>> Indeed it may also be a good solution.
>>> Yup. I thought so too.
>>>
>>> Enjoy!
>>>
>> And which method is more likely to resist a transition of debian to systemd ?
> Humour?
>
and clearly there is a risk for non standard boot methods if sysv-rc is
replaced by anything else.
However, booting in level 2 then using telinit 3 do not start the
services that I setup not to start in level 2... Thus I'll switch to
policy-rd method.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Rick Thomas
Apr 12, 2013, 7:50:02 PM4/12/13
to
On Apr 12, 2013, at 12:56 PM, Erwan David wrote:
> However, booting in level 2 then using telinit 3 do not start the
> services that I setup not to start in level 2... Thus I'll switch to
> policy-rd method.
What did you do to test? If you can give us some details, maybe we
can figure out how to make it work for you.
Rick
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Erwan David
Apr 13, 2013, 6:30:01 AM4/13/13
to
Le 13/04/2013 01:44, Rick Thomas a écrit :
>
> On Apr 12, 2013, at 12:56 PM, Erwan David wrote:
>
>> However, booting in level 2 then using telinit 3 do not start the
>> services that I setup not to start in level 2... Thus I'll switch to
>> policy-rd method.
>
>
>
> I'm surprised to hear that...
>
> What did you do to test? If you can give us some details, maybe we
> can figure out how to make it work for you.
>
> Rick
>
>
update-rc.d dovecot disable 2
>
> On Apr 12, 2013, at 12:56 PM, Erwan David wrote:
>
>> However, booting in level 2 then using telinit 3 do not start the
>> services that I setup not to start in level 2... Thus I'll switch to
>> policy-rd method.
>
>
>
> I'm surprised to hear that...
>
> What did you do to test? If you can give us some details, maybe we
> can figure out how to make it work for you.
>
> Rick
>
>
reboot, indeed dovecot is not started
telinit 3
dovecot does not start (even if there is a Sxxdovecot in /etc/rc3.d)
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bob Proulx
Apr 16, 2013, 7:20:02 PM4/16/13
to
Erwan David wrote:
> update-rc.d dovecot disable 2
> reboot, indeed dovecot is not started
> telinit 3
> dovecot does not start (even if there is a Sxxdovecot in /etc/rc3.d)
Hmm... It should start. I just tested this on a service locally and
> update-rc.d dovecot disable 2
> reboot, indeed dovecot is not started
> telinit 3
> dovecot does not start (even if there is a Sxxdovecot in /etc/rc3.d)
it starts for me. are you sure it isn't starting due to the presence
of a new policy-rc.d script? :-)
In any case... I wanted to add an additional comment. I have been
thinking of doing something like this myself. I haven't done it yet
but if I were implementing this then I think I would have the server
contact a central machine elsewhere on the network to get the keys to
decrypt and mount the encrypted partitions. I am not sure what the
best mechanics would be to implement it. But I think as soon as
networking came online I would have the remote server with the
encrypted disks contact a different server that I controlled. Have it
pull the keys for the partition from there. Then automatically mount
the partitions. Then have it continue the boot process normally and
start the daemons normally.
That way the machine can be rebooted in an automated way without
trouble. I would have them go through automatically. Then on a
normal reboot the machine would mostly behave normally. But if the
machine were stolen it wouldn't be able to get the keys and wouldn't
be able to decrypt that disk.
Lock the key server to the remote server's IP address. The machine
could also block waiting for the external keys and allow you to
acknowledge them if you wanted the extra security. After
acknowledging them the machine would continue to boot normally.
If the machine were stolen then the encrypted partition would not be
unlocked automatically since it would then come from a different IP
address. However knowing that IP address would give you a trail to
the thief.
Bob
Erwan David
Apr 20, 2013, 5:40:01 PM4/20/13
to
Le 17/04/2013 01:15, Bob Proulx a écrit :
> Erwan David wrote:
>> update-rc.d dovecot disable 2
>> reboot, indeed dovecot is not started
>> telinit 3
>> dovecot does not start (even if there is a Sxxdovecot in /etc/rc3.d)
> Hmm... It should start. I just tested this on a service locally and
> it starts for me. are you sure it isn't starting due to the presence
> of a new policy-rc.d script? :-)
Coming back after some testing and interrupts...
> Erwan David wrote:
>> update-rc.d dovecot disable 2
>> reboot, indeed dovecot is not started
>> telinit 3
>> dovecot does not start (even if there is a Sxxdovecot in /etc/rc3.d)
> Hmm... It should start. I just tested this on a service locally and
> it starts for me. are you sure it isn't starting due to the presence
> of a new policy-rc.d script? :-)
No, there is no policy-rc.d script, so it's not the reason. I use a
wheezy, with sysv-init if it makes a difference
> In any case... I wanted to add an additional comment. I have been
> thinking of doing something like this myself. I haven't done it yet
> but if I were implementing this then I think I would have the server
> contact a central machine elsewhere on the network to get the keys to
> decrypt and mount the encrypted partitions. I am not sure what the
> best mechanics would be to implement it. But I think as soon as
> networking came online I would have the remote server with the
> encrypted disks contact a different server that I controlled. Have it
> pull the keys for the partition from there. Then automatically mount
> the partitions. Then have it continue the boot process normally and
> start the daemons normally.
the machine is hosted, thus I do not physically control it. And that
would leave some problem of booting the key_bearing machine.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Erwan David
Apr 20, 2013, 5:40:01 PM4/20/13
to
Le 11/04/2013 08:25, Bob Proulx a écrit :
> Erwan David wrote:
>> 2) add at the beginning of each /etc/init.d/myserv a test to stop if
>> the encrypted partition is not mounted
>>
>> Neither of those solutions seems acceptable for me.
>>
>> So if someone has an idea, I'm listening.
> I would do one of two things. Either I would remove the /etc/rc?.d/S*
> links associated with the services you don't want to start, or make
> the script not executable. Then start them manually later as you
> wish. Or I would install a /usr/sbin/policy-rc.d script that did your
> automated check and only allowed the services to start if the disk was
> mounted as you wish.
>
> See the man page for invoke-rc.d for the first pass documentation.
> Then read the README.policy-rc.d.gz file.
>
> man invoke-rc.d
>
> less /usr/share/doc/sysv-rc/README.policy-rc.d.gz
>
> There is a huge amount of flexibility built into policy-rc.d that most
> people will never need nor use. This makes the documentation a little
> bit overdone. I will include a simple one that I am using at the
> bottom so that you can get the feel for it. In my case this is for a
> chroot and I only want to allow cron and nullmailer to start there.
> All other daemons are denied. For your case you would want the
> reverse and generally allow everything but exclude only the ones you
> want to exclude.
>
>
I have problems withe the documentation of poilcy-rc.d, mainly te fact
> Erwan David wrote:
>> 2) add at the beginning of each /etc/init.d/myserv a test to stop if
>> the encrypted partition is not mounted
>>
>> Neither of those solutions seems acceptable for me.
>>
>> So if someone has an idea, I'm listening.
> I would do one of two things. Either I would remove the /etc/rc?.d/S*
> links associated with the services you don't want to start, or make
> the script not executable. Then start them manually later as you
> wish. Or I would install a /usr/sbin/policy-rc.d script that did your
> automated check and only allowed the services to start if the disk was
> mounted as you wish.
>
> See the man page for invoke-rc.d for the first pass documentation.
> Then read the README.policy-rc.d.gz file.
>
> man invoke-rc.d
>
> less /usr/share/doc/sysv-rc/README.policy-rc.d.gz
>
> There is a huge amount of flexibility built into policy-rc.d that most
> people will never need nor use. This makes the documentation a little
> bit overdone. I will include a simple one that I am using at the
> bottom so that you can get the feel for it. In my case this is for a
> chroot and I only want to allow cron and nullmailer to start there.
> All other daemons are denied. For your case you would want the
> reverse and generally allow everything but exclude only the ones you
> want to exclude.
>
>
it seems to be for the sole usage of package maintainers, not of
administrators of the machine, (see the fact taht alternatives MUST be
used), and that I do not understand at all what an out-of-runlevel
action is.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Erwan David
Apr 21, 2013, 11:50:02 AM4/21/13
to
Le 20/04/2013 23:37, Erwan David a écrit :
> I have problems withe the documentation of poilcy-rc.d, mainly te fact
> it seems to be for the sole usage of package maintainers, not of
> administrators of the machine, (see the fact taht alternatives MUST be
> used), and that I do not understand at all what an out-of-runlevel
> action is.
>
Ok, here is a policy-rc.d which does not work :
> I have problems withe the documentation of poilcy-rc.d, mainly te fact
> it seems to be for the sole usage of package maintainers, not of
> administrators of the machine, (see the fact taht alternatives MUST be
> used), and that I do not understand at all what an out-of-runlevel
> action is.
>
#!/bin/sh
# /usr/sbin/policy-rc.d [options] <initscript ID> <actions> [<runlevel>]
# /usr/sbin/policy-rc.d [options] --list <initscript ID> [<runlevel> ...]
# See /usr/share/doc/sysv-rc/README.policy-rc.d for documentation.
# Live example scraped from ps:
# /bin/sh /usr/sbin/policy-rc.d x11-common stop unknown
if [ ! -r /etc/secure_services ]; then
# No secure service -> Ok for everything
exit 0
fi
##
# Defines the secure mount point and the services which must be started
after
. /etc/secure_services
do_check(){
SERVICES="$SECURE_SERVICES"
for test in $SECURE_SERVICES;do
if [ $1 = $test ];then
case $2 in
*start*)
if mountpoint -q $SECURE_MOUNTPOINT; then
exit 0
else
exit 101
fi;;
*)
exit 0
esac
fi
done
exit 0
}
if [ "X$SECURE_MOUNTPOINT" = "X" -o "X$SECURE_SERVICES" = "X" ];then
# no secure mount point or no secure service defined -> Ok for
everything
exit 0
fi
while [ $# -gt 0 ]; do
case $1 in
--list) exit 101 ;;
--quiet) shift ;;
-*) shift ;;
actions=$2
do_check $service $actions
esac
done
###
# default
exit 101
And my /etc/secure_services is
#####
# Mount point of encrypted file system
SECURE_MOUNTPOINT=/secure
####
# Services which need the encrypted file system
# space separated, they will be started in the order of the variable
SECURE_SERVICES="postgresql dspam slapd dovecot postfix"
But services in SECURE_SERVICES are started, so there is something I do
not understand in what the script should do.
I checked : if /secure is not mounted, /usr/sbin/policy-rc.d postgresql
start terminates on exit 101, which should prevent the start.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bob Proulx
Apr 21, 2013, 3:20:02 PM4/21/13
to
Erwan David wrote:
> Bob Proulx a écrit :
> >Erwan David wrote:
> >>update-rc.d dovecot disable 2
> >>reboot, indeed dovecot is not started
> >>telinit 3
> >>dovecot does not start (even if there is a Sxxdovecot in /etc/rc3.d)
> >Hmm... It should start. I just tested this on a service locally and
> >it starts for me. are you sure it isn't starting due to the presence
> >of a new policy-rc.d script? :-)
>
> Coming back after some testing and interrupts...
>
> No, there is no policy-rc.d script, so it's not the reason. I use a
> wheezy, with sysv-init if it makes a difference
All I can say is that when I change runlevels it works for me. The
> Bob Proulx a écrit :
> >Erwan David wrote:
> >>update-rc.d dovecot disable 2
> >>reboot, indeed dovecot is not started
> >>telinit 3
> >>dovecot does not start (even if there is a Sxxdovecot in /etc/rc3.d)
> >Hmm... It should start. I just tested this on a service locally and
> >it starts for me. are you sure it isn't starting due to the presence
> >of a new policy-rc.d script? :-)
>
> Coming back after some testing and interrupts...
>
> No, there is no policy-rc.d script, so it's not the reason. I use a
> wheezy, with sysv-init if it makes a difference
start scripts (/etc/rc3.d/S* for runlevel 3 example) all are invoked
and daemons launched there are started. I tested this on a pristine
installation. If it doesn't work for you then there is something
about your system that is different from a pristine installation.
Something local. You will need to debug it. Check /etc/inittab and
verify that the runlevels are still defined there.
> >In any case... I wanted to add an additional comment. I have been
> >thinking of doing something like this myself. I haven't done it yet
> >but if I were implementing this then I think I would have the server
> >contact a central machine elsewhere on the network to get the keys to
> >decrypt and mount the encrypted partitions. I am not sure what the
> >best mechanics would be to implement it. But I think as soon as
> >networking came online I would have the remote server with the
> >encrypted disks contact a different server that I controlled. Have it
> >pull the keys for the partition from there. Then automatically mount
> >the partitions. Then have it continue the boot process normally and
> >start the daemons normally.
>
> I have no central machine on "the network". I want to encrypt
> because the machine is hosted, thus I do not physically control it.
> And that would leave some problem of booting the key_bearing
> machine.
This would mean that you would need two machines and those should be
at different geographical locations. The further apart the better.
That way if thieves stole one machine they would not get both of
them. Individually each would be useless.
The only information on the key_bearing machine would be the keys. As
such those would not need to be on an encrypted disk. I wouldn't have
that one need to be encrypted. Although you could and also have a way
to manually enter the keys so that you could manually bring them up.
Then if either machine were stolen you would be able to change the
keys on the other machine. They keys are for boot time and not
runtime and so compromise of the keys would not compromise the runtime
of the system. You would just need to change the keys before the
machine booted next.
Of course you would need two machines. But for some of us there is
always a spare machine somewhere on the net that could be used for
this task and so that isn't a hardship. :-)
Bob
Bob Proulx
Apr 21, 2013, 3:30:02 PM4/21/13
to
Erwan David wrote:
> I have problems withe the documentation of poilcy-rc.d, mainly te
> fact it seems to be for the sole usage of package maintainers, not
> of administrators of the machine, (see the fact taht alternatives
> MUST be used), and that I do not understand at all what an
> out-of-runlevel action is.
That is simply to provide arbitration direction immediately to any
> I have problems withe the documentation of poilcy-rc.d, mainly te
> fact it seems to be for the sole usage of package maintainers, not
> of administrators of the machine, (see the fact taht alternatives
> MUST be used), and that I do not understand at all what an
> out-of-runlevel action is.
package that wishes to provide a policy-rc.d. Otherwise how would
that work?
$ apt-file search policy-rc.d | grep sbin/policy-rc.d
fai-nfsroot: /usr/bin/policy-rc.d.fai
policyrcd-script-zg2: /usr/sbin/zg-policy-rc.d
I only see two packages that provide a policy-rc.d script. If you
don't install them then you won't conflict with them. Your machine,
your rules, and all of that.
Or you could select one of the alternative methods. You are blazing a
trail. There is no pre-compiled correct answer.
Bob
Bob Proulx
Apr 21, 2013, 7:20:01 PM4/21/13
to
Erwan David wrote:
> Ok, here is a policy-rc.d which does not work :
Since I led you down this road I set up a test system. I have been
> Ok, here is a policy-rc.d which does not work :
using policy-rc.d in chroots seemlingly forever and they definitely
work there. They definitely prevent package upgrades from starting
daemons.
invoke-rc.d: policy-rc.d denied execution of restart.
But that is through dpkg and postinst scripts. When I set up a test
VM system and booted it I was shocked to find that it didn't work.
Just like you found the daemons were still started at boot time.
Starting Postfix Mail Transport Agent: postfix.
Am I completely misunderstanding the documentation on this? Maybe.
If so then I am sorry for misleading you along with me. I am
researching the problem. I think this is completely against the
documented interface.
Bob
Erwan David
Apr 22, 2013, 3:20:02 AM4/22/13
to
following resullt :
boot does not use it (should be startpar), /sbin/service does not use
it, only invoke-rc.d, which seems to be only used in postinst for
restarting a service.
My solution for the moment is to disable those services (thus losing the
information about their starting order) through update-rc.d disable
(which also means each upgrade will now get polluted by messages saying
their start runlevel are different from default) and starting them from
my encrypted partition mounting script.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bob Proulx
Apr 22, 2013, 3:30:01 PM4/22/13
to
Erwan David wrote:
> Bob Proulx a écrit :
> Bob Proulx a écrit :
> >Am I completely misunderstanding the documentation on this? Maybe.
> >If so then I am sorry for misleading you along with me. I am
> >researching the problem. I think this is completely against the
> >documented interface.
>
> >If so then I am sorry for misleading you along with me. I am
> >researching the problem. I think this is completely against the
> >documented interface.
>
> I added some traces in my policy-rc.d (to a file in /root), and got
> the following resullt :
> boot does not use it (should be startpar), /sbin/service does not
> use it, only invoke-rc.d, which seems to be only used in postinst
> for restarting a service.
You are correct. I was completely wrong about this. Sorry.
> the following resullt :
> boot does not use it (should be startpar), /sbin/service does not
> use it, only invoke-rc.d, which seems to be only used in postinst
> for restarting a service.
I couldn't find a plausible connection when I dug through the scripts.
Confused I wrote to the pkg-sysvinit-devel team yesterday and got that
answer as a response this morning!
So apparently policy-rc.d controls the policy to init.d. I think it
is misnamed. It should have been policy-init.d instead. It doesn't
control policy of the rc?.d scripts.
Apparently the *only* purpose is for use in chroots. Chroots get all
of the package installations and upgrades. The policy-rc.d controls
access to the init.d scripts instead of having a package postinst
calling '/etc/init.d/foo restart' or 'service foo restart' directly.
Since a chroot doesn't normally get its own init nor have its own
runlevels they aren't ever changed there and so there wasn't a need to
include /etc/init.d/rc in the policy infrastructure. And so using it
for a real system has no effect at all.
I apologize for leading you astray on this topic and wasting a lot of
your time. I can only offer that I was also led astray. Sometimes
documentation can be terribly misleading.
> My solution for the moment is to disable those services (thus losing
> the information about their starting order) through update-rc.d
> disable (which also means each upgrade will now get polluted by
> messages saying their start runlevel are different from default) and
> starting them from my encrypted partition mounting script.
As far as losing the starting order that doesn't matter at all. The
'insserv' program dynamically sets that up based upon the LSB headers
of the enabled scripts. If you were to return those back to being
enabled then insserv would order them according to the current set of
enabled scripts. So no real information is lost. It isn't like the
prior release with static legacy hard numbered ordering.
Again let me apologize. Sorry for the diversion down the rabbit hole.
Bob
Erwan David
Apr 22, 2013, 4:30:01 PM4/22/13
to
Le 22/04/2013 21:24, Bob Proulx a écrit :
> Again let me apologize. Sorry for the diversion down the rabbit hole. Bob
No harm done : I was not in a hurry, and I learned very interesting things.
> Again let me apologize. Sorry for the diversion down the rabbit hole. Bob
Thnaks for the help.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Richard Hector
May 8, 2013, 1:00:03 AM5/8/13
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is, like many things you post, really interesting. Do you have a
blog, to make these things easier to find?
Richard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQEcBAEBAgAGBQJRido7AAoJELSi8I/scBaN3UsH/2R/rB29S+ismTXAZhw4gUqG
+pfIbHkEzkcrPGQbAalHQoVGpWHUIIOspSpmpXFg3mPumW09MzwlGQwNcJIqUtxa
NLbvZn64XT9a0pZjdkx8CvgjRt2t3UDxAJTzGCLmLhk8S7KLahREvyBE3BjO3711
zmaA0QnojVnO1L7tXRmKfadDjLRnCUifdMVI2ZdHhlrnL9yFYvV6yipKZ9lzuwAB
Zdiv89xX63SvvpN4Ld+E2A7D5swx78Gl+WYlo1NBTFppPfUH/C9Xoue3uxBcvnEv
gfJ7uOTGZkD3a0thkA8k1x6pOcLsj9AC6eh51zXjonA+l+oR5EqNbvLRnUAWN3Q=
=ovAq
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/5189DA4...@walnut.gen.nz
Hash: SHA1
blog, to make these things easier to find?
Richard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQEcBAEBAgAGBQJRido7AAoJELSi8I/scBaN3UsH/2R/rB29S+ismTXAZhw4gUqG
+pfIbHkEzkcrPGQbAalHQoVGpWHUIIOspSpmpXFg3mPumW09MzwlGQwNcJIqUtxa
NLbvZn64XT9a0pZjdkx8CvgjRt2t3UDxAJTzGCLmLhk8S7KLahREvyBE3BjO3711
zmaA0QnojVnO1L7tXRmKfadDjLRnCUifdMVI2ZdHhlrnL9yFYvV6yipKZ9lzuwAB
Zdiv89xX63SvvpN4Ld+E2A7D5swx78Gl+WYlo1NBTFppPfUH/C9Xoue3uxBcvnEv
gfJ7uOTGZkD3a0thkA8k1x6pOcLsj9AC6eh51zXjonA+l+oR5EqNbvLRnUAWN3Q=
=ovAq
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bob Proulx
May 8, 2013, 1:50:01 AM5/8/13
to
Richard Hector wrote:
> Bob Proulx wrote:
> > In any case... I wanted to add an additional comment. I have
> > been thinking of doing something like this myself. I haven't done
> > it yet but if I were implementing this then I think I would have
> > ...
> Bob Proulx wrote:
> > In any case... I wanted to add an additional comment. I have
> > been thinking of doing something like this myself. I haven't done
> > it yet but if I were implementing this then I think I would have
>
> This is, like many things you post, really interesting. Do you have a
> blog, to make these things easier to find?
Thank you for the kind words. I am deeply flattered that you find my
> This is, like many things you post, really interesting. Do you have a
> blog, to make these things easier to find?
postings useful.
I do not have a blog although I have been thinking of starting one. I
am getting so that I don't remember details as well as at one time and
so would like some place to organize my own thoughts and a blog would
be one way to do it. But at the moment I do not.
I have also been trying to spend more time on http://wiki.debian.org/
when I have something to say. That resource is extremely useful and
continues to be more useful to more people the more that it is used.
Therefore I will give an advertisement for it now and suggest that
more people should get over there and improve it and then reference it
in postings so that it becomes more well known.
Also I want to say that every time I look at the history of pages on
the wiki I see many familiar names from the helpful people here on
debian-user. If I mention one I would slight twenty. I feel that
they have been putting in good long lasting work by updating the wiki
pages while I have been slacking by not doing so. I should spend my
fair share of time there too. So lately I have been trying to catch
up on the work and improve various pages on the wiki.
Bob
0 new messages