can we stop packaging sysvinit scripts?

can we stop packaging sysvinit scripts?

[Sage Weil]

We've had systemd unit files for several releases now and all major 
distros are using systemd by default.  Can we stop packaging the sysvinit 
scripts?

I realize that Debian allows you to switch init systems... do any users 
actually do this?  Is it required that debs include the sysvinit scripts 
or is there some glue that lets packages avoid maintaining sysvinit 
scripts?

I ask because the init scripts are one of the few remainining bits that 
use the ceph-conf utility, which I would like to deprecate (and eventually 
remove).  It parses local config files but we are migrating this to the 
mon.  We could make ceph-conf pull configs from the mon but I would 
like to simplify if possible!

Thanks-
sage

Re: [Ceph-maintainers] can we stop packaging sysvinit scripts?

[Ken Dreyer]

I'm good with dropping them.

On Wed, Jan 10, 2018 at 7:44 AM, Sage Weil <sweil@redhat.com> wrote:
> We've had systemd unit files for several releases now and all major
> distros are using systemd by default.  Can we stop packaging the sysvinit
> scripts?
>
> I realize that Debian allows you to switch init systems... do any users
> actually do this?  Is it required that debs include the sysvinit scripts
> or is there some glue that lets packages avoid maintaining sysvinit
> scripts?
>
> I ask because the init scripts are one of the few remainining bits that
> use the ceph-conf utility, which I would like to deprecate (and eventually
> remove).  It parses local config files but we are migrating this to the
> mon.  We could make ceph-conf pull configs from the mon but I would
> like to simplify if possible!
>
> Thanks-
> sage
>
> _______________________________________________
> Ceph-maintainers mailing list
> Ceph-maintainers@lists.ceph.com
> http://lists.ceph.com/listinfo.cgi/ceph-maintainers-ceph.com

Re: can we stop packaging sysvinit scripts?

[Amon Ott]

Am 10.01.2018 um 15:44 schrieb Sage Weil:
> We've had systemd unit files for several releases now and all major 
> distros are using systemd by default.  Can we stop packaging the sysvinit 
> scripts?
> 
> I realize that Debian allows you to switch init systems... do any users 
> actually do this?  Is it required that debs include the sysvinit scripts 
> or is there some glue that lets packages avoid maintaining sysvinit 
> scripts?
> 
> I ask because the init scripts are one of the few remainining bits that 
> use the ceph-conf utility, which I would like to deprecate (and eventually 
> remove).  It parses local config files but we are migrating this to the 
> mon.  We could make ceph-conf pull configs from the mon but I would 
> like to simplify if possible!

We would really appreciate having the init scripts around for a long
while, as we are not willing to use systemd on our servers for security
reasons. Please do not drop them.

Amon Ott
-- 
Dr. Amon Ott
m-privacy GmbH           Tel: +49 30 24342334
Werner-Voß-Damm 62       Fax: +49 30 99296856
12101 Berlin             http://www.m-privacy.de

Amtsgericht Charlottenburg, HRB 84946

Geschäftsführer:
 Dipl.-Kfm. Holger Maczkowsky,
 Roman Maczkowsky

GnuPG-Key-ID: 0x2DD3A649

Re: can we stop packaging sysvinit scripts?

[Alfredo Deza]

On Wed, Jan 10, 2018 at 11:18 AM, Amon Ott <a.ott@m-privacy.de> wrote:
> Am 10.01.2018 um 15:44 schrieb Sage Weil:
>> We've had systemd unit files for several releases now and all major
>> distros are using systemd by default.  Can we stop packaging the sysvinit
>> scripts?
>>
>> I realize that Debian allows you to switch init systems... do any users
>> actually do this?  Is it required that debs include the sysvinit scripts
>> or is there some glue that lets packages avoid maintaining sysvinit
>> scripts?
>>
>> I ask because the init scripts are one of the few remainining bits that
>> use the ceph-conf utility, which I would like to deprecate (and eventually
>> remove).  It parses local config files but we are migrating this to the
>> mon.  We could make ceph-conf pull configs from the mon but I would
>> like to simplify if possible!
>
> We would really appreciate having the init scripts around for a long
> while, as we are not willing to use systemd on our servers for security
> reasons. Please do not drop them.

We no longer test those scripts (someone correct me if I am wrong
here), maybe you could support them out of the ceph tree?

>
> Amon Ott
> --
> Dr. Amon Ott
> m-privacy GmbH           Tel: +49 30 24342334
> Werner-Voß-Damm 62       Fax: +49 30 99296856
> 12101 Berlin             http://www.m-privacy.de
>
> Amtsgericht Charlottenburg, HRB 84946
>
> Geschäftsführer:
>  Dipl.-Kfm. Holger Maczkowsky,
>  Roman Maczkowsky
>
> GnuPG-Key-ID: 0x2DD3A649
>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: can we stop packaging sysvinit scripts?

[Sage Weil]

On Wed, 10 Jan 2018, Amon Ott wrote:
> Am 10.01.2018 um 15:44 schrieb Sage Weil:
> > We've had systemd unit files for several releases now and all major 
> > distros are using systemd by default.  Can we stop packaging the sysvinit 
> > scripts?
> > 
> > I realize that Debian allows you to switch init systems... do any users 
> > actually do this?  Is it required that debs include the sysvinit scripts 
> > or is there some glue that lets packages avoid maintaining sysvinit 
> > scripts?
> > 
> > I ask because the init scripts are one of the few remainining bits that 
> > use the ceph-conf utility, which I would like to deprecate (and eventually 
> > remove).  It parses local config files but we are migrating this to the 
> > mon.  We could make ceph-conf pull configs from the mon but I would 
> > like to simplify if possible!
> 
> We would really appreciate having the init scripts around for a long
> while, as we are not willing to use systemd on our servers for security
> reasons. Please do not drop them.

Okay, I think in the end ceph-conf behavior won't change (it will continue 
to only do config files, not mon config) so all of the current users (like 
sysvinit scripts) can continue to do their old legacy thing.  

So... nevermind, I guess!

sage

Re: can we stop packaging sysvinit scripts?

[Ken Dreyer]

On Wed, Jan 10, 2018 at 9:18 AM, Amon Ott <a.ott@m-privacy.de> wrote:
> We would really appreciate having the init scripts around for a long
> while, as we are not willing to use systemd on our servers for security
> reasons. Please do not drop them.

I'm curious, what init system are you using?

- Ken

Re: can we stop packaging sysvinit scripts?

[Amon Ott]

Am 12.01.2018 um 00:40 schrieb Ken Dreyer:
> On Wed, Jan 10, 2018 at 9:18 AM, Amon Ott <a.ott@m-privacy.de> wrote:
>> We would really appreciate having the init scripts around for a long
>> while, as we are not willing to use systemd on our servers for security
>> reasons. Please do not drop them.
> 
> I'm curious, what init system are you using?

Still sysvinit. I just do not like the idea of one complex user space
daemon like systemd controlling most of the system, whose complexity
makes severe security problems likely. So we stick with separate small
programs and mandatorily assign individual and limited access control
rights to them with RSBAC.

Think of the regular nightmare with anti malware software deep in the
system, which repeatedly opened up the whole system remotely in the
past, and you get the idea. We do not trust malware scanners and
strictly limit their abilities to a simple "read a file and decide, we
do the rest as we please".

IMO, access control must be done in the kernel and security needs small
components in user space with limited functionality, following the good
old KISS principle. Then you have full control and can limit the
consequences of misbehaving programs.

Amon Ott
-- 
Dr. Amon Ott
m-privacy GmbH           Tel: +49 30 24342334
Werner-Voß-Damm 62       Fax: +49 30 99296856
12101 Berlin             http://www.m-privacy.de

Amtsgericht Charlottenburg, HRB 84946

Geschäftsführer:
 Dipl.-Kfm. Holger Maczkowsky,
 Roman Maczkowsky

GnuPG-Key-ID: 0x2DD3A649