7:54 a.m.
Hi,
Why sysrq is limited to only "sync" command on official fedora kernel?
Regards,
Ali
8:04 a.m.
On Wed, Feb 25, 2015 at 8:54 AM, Ali AlipourR <alipoor90(a)gmail.com> wrote:
Hi,
Why sysrq is limited to only "sync" command on official fedora kernel?
The kernel itself isn't limited. It's just set that way in
/usr/lib/sysctl.d/50-default.conf which is provided by systemd. You
can edit that file, create your own in /etc/sysctrl.d/, or (as root)
set it to whatever you would like via /proc/sys/kernel/sysrq.
josh
8:35 a.m.
> Why sysrq is limited to only "sync" command on official
fedora kernel?
The kernel itself isn't limited. It's just set that way in
/usr/lib/sysctl.d/50-default.conf which is provided by systemd. You
can edit that file, create your own in /etc/sysctrl.d/, or (as root)
set it to whatever you would like via /proc/sys/kernel/sysrq.
Of course it can be changed at runtime, but I mean why official fedora
kernel shouldn't be configured to allow all (or at least a wider
subset) of sysrq commands by default?
This way official fedora live CDs are unsuitable for system recovery
tasks; you have to change sysrq value every time you use live CDs or
build your own live CD.
Regards,
Ali
8:39 a.m.
Am 25.02.2015 um 15:35 schrieb Ali AlipourR:
>> Why sysrq is limited to only "sync" command on
official fedora kernel?
>
> The kernel itself isn't limited. It's just set that way in
> /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You
> can edit that file, create your own in /etc/sysctrl.d/, or (as root)
> set it to whatever you would like via /proc/sys/kernel/sysrq.
Of course it can be changed at runtime, but I mean why official fedora
kernel shouldn't be configured to allow all (or at least a wider
subset) of sysrq commands by default?
This way official fedora live CDs are unsuitable for system recovery
tasks; you have to change sysrq value every time you use live CDs or
build your own live CD
it is nothing someone is using regulary and that settings are security
settings recommended by most auditing tools
8:52 a.m.
it is nothing someone is using regulary and that settings are security
settings recommended by most auditing tools
security part is admit able, but still I think it is too much strict,
e.g. what is security problem of having 'r' request enabled?
(specially considering that fedora uses relatively unstable
gnome-shell)
Regards,
Ali
8:43 a.m.
On Wed, Feb 25, 2015 at 9:35 AM, Ali AlipourR <alipoor90(a)gmail.com> wrote:
>> Why sysrq is limited to only "sync" command on
official fedora kernel?
>
> The kernel itself isn't limited. It's just set that way in
> /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You
> can edit that file, create your own in /etc/sysctrl.d/, or (as root)
> set it to whatever you would like via /proc/sys/kernel/sysrq.
Of course it can be changed at runtime, but I mean why official fedora
kernel shouldn't be configured to allow all (or at least a wider
subset) of sysrq commands by default?
Maybe we're getting hung up on a terminology issue, but this isn't a
kernel configuration issue. It's something userspace is doing.
This way official fedora live CDs are unsuitable for system recovery
tasks; you have to change sysrq value every time you use live CDs or
build your own live CD.
That's a good point. Since the live images have a "rescue" mode,
maybe there is a way to use a different value when booted into that.
How that would look, I'm not sure. Maybe dracut would need to include
an override file in the initramfs.
josh
8:53 a.m.
On 02/25/2015 03:43 PM, Josh Boyer wrote:
On Wed, Feb 25, 2015 at 9:35 AM, Ali AlipourR
<alipoor90(a)gmail.com> wrote:
>>> Why sysrq is limited to only "sync" command on official fedora
kernel?
>>
>> The kernel itself isn't limited. It's just set that way in
>> /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You
>> can edit that file, create your own in /etc/sysctrl.d/, or (as root)
>> set it to whatever you would like via /proc/sys/kernel/sysrq.
>
> Of course it can be changed at runtime, but I mean why official fedora
> kernel shouldn't be configured to allow all (or at least a wider
> subset) of sysrq commands by default?
Maybe we're getting hung up on a terminology issue, but this isn't a
kernel configuration issue. It's something userspace is doing.
> This way official fedora live CDs are unsuitable for system recovery
> tasks; you have to change sysrq value every time you use live CDs or
> build your own live CD.
That's a good point. Since the live images have a "rescue" mode,
maybe there is a way to use a different value when booted into that.
How that would look, I'm not sure. Maybe dracut would need to include
an override file in the initramfs.
I don't follow the reasoning. Why am I more likely to need SysRq in
rescue mode than in normal boot?
Michal
9:12 a.m.
On Wed, Feb 25, 2015 at 9:53 AM, Michal Schmidt <mschmidt(a)redhat.com> wrote:
On 02/25/2015 03:43 PM, Josh Boyer wrote:
> On Wed, Feb 25, 2015 at 9:35 AM, Ali AlipourR <alipoor90(a)gmail.com> wrote:
>>>> Why sysrq is limited to only "sync" command on official fedora
kernel?
>>>
>>> The kernel itself isn't limited. It's just set that way in
>>> /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You
>>> can edit that file, create your own in /etc/sysctrl.d/, or (as root)
>>> set it to whatever you would like via /proc/sys/kernel/sysrq.
>>
>> Of course it can be changed at runtime, but I mean why official fedora
>> kernel shouldn't be configured to allow all (or at least a wider
>> subset) of sysrq commands by default?
>
> Maybe we're getting hung up on a terminology issue, but this isn't a
> kernel configuration issue. It's something userspace is doing.
>
>> This way official fedora live CDs are unsuitable for system recovery
>> tasks; you have to change sysrq value every time you use live CDs or
>> build your own live CD.
>
> That's a good point. Since the live images have a "rescue" mode,
> maybe there is a way to use a different value when booted into that.
> How that would look, I'm not sure. Maybe dracut would need to include
> an override file in the initramfs.
I don't follow the reasoning. Why am I more likely to need SysRq in
rescue mode than in normal boot?
Rescue mode quite often translates to "debug mode" as well. Things
hang, you need to know why, etc. SysRq isn't always required, but it
is another tool in the box.
josh
12:02 a.m.
On 25 February 2015 at 16:43, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Wed, Feb 25, 2015 at 9:35 AM, Ali AlipourR
<alipoor90(a)gmail.com> wrote:
>>> Why sysrq is limited to only "sync" command on official fedora
kernel?
>>
>> The kernel itself isn't limited. It's just set that way in
>> /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You
>> can edit that file, create your own in /etc/sysctrl.d/, or (as root)
>> set it to whatever you would like via /proc/sys/kernel/sysrq.
>
> Of course it can be changed at runtime, but I mean why official fedora
> kernel shouldn't be configured to allow all (or at least a wider
> subset) of sysrq commands by default?
Maybe we're getting hung up on a terminology issue, but this isn't a
kernel configuration issue. It's something userspace is doing.
> This way official fedora live CDs are unsuitable for system recovery
> tasks; you have to change sysrq value every time you use live CDs or
> build your own live CD.
That's a good point. Since the live images have a "rescue" mode,
maybe there is a way to use a different value when booted into that.
How that would look, I'm not sure. Maybe dracut would need to include
an override file in the initramfs.
josh
AFAIK the live images don't have a rescue mode/boot option; that mode
is only available on the non-live installation DVD and the
network-install images.
--
Ahmad Samir
11:12 a.m.
On Wed, 25.02.15 18:05, Ali AlipourR (alipoor90(a)gmail.com) wrote:
>> Why sysrq is limited to only "sync" command on
official fedora kernel?
>
> The kernel itself isn't limited. It's just set that way in
> /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You
> can edit that file, create your own in /etc/sysctrl.d/, or (as root)
> set it to whatever you would like via /proc/sys/kernel/sysrq.
Of course it can be changed at runtime, but I mean why official fedora
kernel shouldn't be configured to allow all (or at least a wider
subset) of sysrq commands by default?
We generally default "secure". The thing is that with sysrq you can
kill arbitrary processes if you have acecss to the console, and other
things, and that's just too security sensitive.
This way official fedora live CDs are unsuitable for system recovery
tasks; you have to change sysrq value every time you use live CDs or
build your own live CD.
I figure for livecds it would be fine to override this.
Lennart
--
Lennart Poettering, Red Hat
11:16 a.m.
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
We generally default "secure". The thing is that with sysrq
you can
kill arbitrary processes if you have acecss to the console, and other
things, and that's just too security sensitive.
There are other useful things, like sync, remount read-only, reboot,
poweroff, that we already allow console users to do other ways by
default. Allowing them to do them through SysRq seems like a good idea
IMHO.
--
Chris Adams <linux(a)cmadams.net>
11:29 a.m.
On Wed, 25.02.15 11:16, Chris Adams (linux(a)cmadams.net) wrote:
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de>
said:
> We generally default "secure". The thing is that with sysrq you can
> kill arbitrary processes if you have acecss to the console, and other
> things, and that's just too security sensitive.
There are other useful things, like sync, remount read-only, reboot,
poweroff, that we already allow console users to do other ways by
default. Allowing them to do them through SysRq seems like a good idea
IMHO.
Hmm? Syncing is allowed to my knowledge. C-a-d and gdm allow a clean
reboot/poweroff. But sysrq does an abnormal reboot/poweroff, which we
cannot allow. Similar, remounting read-only is also security senstive,
which we cannot allow.
Without being logged in there's very little you can do on a host right
now, and sysrq should not open up more there by default.
Lennart
--
Lennart Poettering, Red Hat
11:37 a.m.
On Wed, 25 Feb 2015, Lennart Poettering wrote:
Hmm? Syncing is allowed to my knowledge. C-a-d and gdm allow a clean
reboot/poweroff. But sysrq does an abnormal reboot/poweroff, which we
cannot allow. Similar, remounting read-only is also security senstive,
which we cannot allow.
Without being logged in there's very little you can do on a host right
now, and sysrq should not open up more there by default.
You must have forgotten your university days....
The alternative to not being able to sync-umount-boot using sysrq is to
flip the switch. I'd rather have them use sysrq.
I said it when they closed X ctrl-alt-backspace and I'll say it now.
When you are on console with the power plug, preventing these actions
is stupid.
Paul
11:44 a.m.
Am 25.02.2015 um 18:37 schrieb Paul Wouters:
On Wed, 25 Feb 2015, Lennart Poettering wrote:
> Hmm? Syncing is allowed to my knowledge. C-a-d and gdm allow a clean
> reboot/poweroff. But sysrq does an abnormal reboot/poweroff, which we
> cannot allow. Similar, remounting read-only is also security senstive,
> which we cannot allow.
>
> Without being logged in there's very little you can do on a host right
> now, and sysrq should not open up more there by default.
You must have forgotten your university days....
The alternative to not being able to sync-umount-boot using sysrq is to
flip the switch. I'd rather have them use sysrq.
I said it when they closed X ctrl-alt-backspace and I'll say it now.
When you are on console with the power plug, preventing these actions
is stupid
when you are on a machine where you have pysical only keyboard and mouse
it is not - not every PC stands in front of your face - think about
kiosk mode and so on...
11:47 a.m.
Once upon a time, Reindl Harald <h.reindl(a)thelounge.net> said:
when you are on a machine where you have pysical only keyboard and
mouse it is not - not every PC stands in front of your face - think
about kiosk mode and so on...
But Fedora out-of-the-box is not secured for that already. An admin
needs to do additional configuration to secure for a "console does NOT
have physical access" and "console user is NOT admin" setup.
--
Chris Adams <linux(a)cmadams.net>
11:50 a.m.
Am 25.02.2015 um 18:47 schrieb Chris Adams:
Once upon a time, Reindl Harald <h.reindl(a)thelounge.net> said:
> when you are on a machine where you have pysical only keyboard and
> mouse it is not - not every PC stands in front of your face - think
> about kiosk mode and so on...
But Fedora out-of-the-box is not secured for that already. An admin
needs to do additional configuration to secure for a "console does NOT
have physical access" and "console user is NOT admin" setup
no - but it makes a difference if you need to care abot 20 or 200 things
to secure - many even don't know about sysrq and so would never come to
the idea secure sysrq too and so have an unknown door wide open
the users which know about it can enable it
that's the whole purpose of secure defaults
2:38 p.m.
Dne 25.2.2015 v 18:44 Reindl Harald napsal(a):
Am 25.02.2015 um 18:37 schrieb Paul Wouters:
> On Wed, 25 Feb 2015, Lennart Poettering wrote:
>
>> Hmm? Syncing is allowed to my knowledge. C-a-d and gdm allow a clean
>> reboot/poweroff. But sysrq does an abnormal reboot/poweroff, which we
>> cannot allow. Similar, remounting read-only is also security senstive,
>> which we cannot allow.
>>
>> Without being logged in there's very little you can do on a host right
>> now, and sysrq should not open up more there by default.
>
> You must have forgotten your university days....
>
> The alternative to not being able to sync-umount-boot using sysrq is to
> flip the switch. I'd rather have them use sysrq.
>
> I said it when they closed X ctrl-alt-backspace and I'll say it now.
> When you are on console with the power plug, preventing these actions
> is stupid
when you are on a machine where you have pysical only keyboard and mouse it is
not - not every PC stands in front of your face - think about kiosk mode and
so on...
When I read such answers - I always wonder myself - how many kiosk ever run
Fedora...
It's such a bad idea to optimize Fedora for one-in-milion users and those
999.999 has to suffer instead of require 1 guy to configure more secure version.
On the other hand - Fedora might easily provide a 'script' to disable all
obscure 'security' settings - if that's the only thing to pass the security
audit with 'defaults'...
And my recent personal experience - I tried to configure NFS to use it between
my qemu and host machine - and guess what - first thing which has been
instantly removed from host was firewalld as this piece is simply
unconfigurable nonsense and the second one is absurdly broken nfs4 - replaced
with usable nfs3...
People need to do their works and don't have time to spend ours figuring out
where the settings has been shifted after some security-person decisions and
systemd upgrades....
Regards
Zdenek
2:49 p.m.
Am 25.02.2015 um 21:38 schrieb Zdenek Kabelac:
Dne 25.2.2015 v 18:44 Reindl Harald napsal(a):
>
> Am 25.02.2015 um 18:37 schrieb Paul Wouters:
>> On Wed, 25 Feb 2015, Lennart Poettering wrote:
>>
>>> Hmm? Syncing is allowed to my knowledge. C-a-d and gdm allow a clean
>>> reboot/poweroff. But sysrq does an abnormal reboot/poweroff, which we
>>> cannot allow. Similar, remounting read-only is also security senstive,
>>> which we cannot allow.
>>>
>>> Without being logged in there's very little you can do on a host right
>>> now, and sysrq should not open up more there by default.
>>
>> You must have forgotten your university days....
>>
>> The alternative to not being able to sync-umount-boot using sysrq is to
>> flip the switch. I'd rather have them use sysrq.
>>
>> I said it when they closed X ctrl-alt-backspace and I'll say it now.
>> When you are on console with the power plug, preventing these actions
>> is stupid
>
> when you are on a machine where you have pysical only keyboard and
> mouse it is
> not - not every PC stands in front of your face - think about kiosk
> mode and
> so on...
When I read such answers - I always wonder myself - how many kiosk ever
run Fedora...
It's such a bad idea to optimize Fedora for one-in-milion users and
those 999.999 has to suffer instead of require 1 guy to configure more
secure version
you can be sure that the need for sysrq is the one-in-milion users just
because i am a *heavy user* with a lot of setups and used it 4 times in
the past 12 years while restricted it to "kernel.sysrq = 20" long before
the systemd change
it's such a bad idea to *not* optimize out-of-the box for security
the ones which don't care can disable it, most won't care, nor have a
need nor do they even know about a lot of things - this users are also
not in the position to fix bad security defaults because they have no
idea about it
9:51 a.m.
On Feb 25, 2015 1:50 PM, "Reindl Harald" <h.reindl(a)thelounge.net> wrote:
Am 25.02.2015 um 21:38 schrieb Zdenek Kabelac:
> Dne 25.2.2015 v 18:44 Reindl Harald napsal(a):
>>
>>
>> Am 25.02.2015 um 18:37 schrieb Paul Wouters:
>>>
>>> On Wed, 25 Feb 2015, Lennart Poettering wrote:
>>>
>>>> Hmm? Syncing is allowed to my knowledge. C-a-d and gdm allow a clean
>>>> reboot/poweroff. But sysrq does an abnormal reboot/poweroff, which we
>>>> cannot allow. Similar, remounting read-only is also security senstive,
>>>> which we cannot allow.
>>>>
>>>> Without being logged in there's very little you can do on a host
right
>>>> now, and sysrq should not open up more there by default.
>>>
>>>
>>> You must have forgotten your university days....
>>>
>>> The alternative to not being able to sync-umount-boot using sysrq is to
>>> flip the switch. I'd rather have them use sysrq.
>>>
>>> I said it when they closed X ctrl-alt-backspace and I'll say it now.
>>> When you are on console with the power plug, preventing these actions
>>> is stupid
>>
>>
>> when you are on a machine where you have pysical only keyboard and
>> mouse it is
>> not - not every PC stands in front of your face - think about kiosk
>> mode and
>> so on...
>
>
> When I read such answers - I always wonder myself - how many kiosk ever
> run Fedora...
>
> It's such a bad idea to optimize Fedora for one-in-milion users and
> those 999.999 has to suffer instead of require 1 guy to configure more
> secure version
you can be sure that the need for sysrq is the one-in-milion users just
because i
am a *heavy user* with a lot of setups and used it 4 times in the
past 12 years while restricted it to "kernel.sysrq = 20" long before the
systemd change
it's such a bad idea to *not* optimize out-of-the box for security
the ones which don't care can disable it, most won't care, nor have a
need
nor do they even know about a lot of things - this users are also not
in the position to fix bad security defaults because they have no idea
about it
--
The only time I've needed sysrq reboots in recent memory was while running
rawhide and knowingly venturing into uncharted territory. If I'm not the
only one, would it make sense to include appropriate sysctl snippets in
fedora-release-rawhide ?
--Pete
10:01 a.m.
On Thu, Feb 26, 2015 at 08:51:46AM -0700, Pete Travis wrote:
The only time I've needed sysrq reboots in recent memory was
while running
rawhide and knowingly venturing into uncharted territory. If I'm not the
only one, would it make sense to include appropriate sysctl snippets in
fedora-release-rawhide ?
We could ship /etc/sysctl.d/sysrq-enable.conf.disabled
(name up for discussion),
and interested users could enable it by renaming the file. Maybe even better
to provide it the same in all versions.
Zbyszek
3:33 p.m.
On Feb 26, 2015 9:01 AM, "Zbigniew Jędrzejewski-Szmek"
<zbyszek(a)in.waw.pl>
wrote:
On Thu, Feb 26, 2015 at 08:51:46AM -0700, Pete Travis wrote:
> The only time I've needed sysrq reboots in recent memory was while
running
> rawhide and knowingly venturing into uncharted territory. If
I'm not
the
> only one, would it make sense to include appropriate sysctl
snippets in
> fedora-release-rawhide ?
We could ship /etc/sysctl.d/sysrq-enable.conf.disabled (name up for
discussion),
and interested users could enable it by renaming the file. Maybe even
better
to provide it the same in all versions.
Zbyszek
--
All versions might be overkill, but I don't see the harm in the added
convenience, either. What's the next step?
--Pete
5:32 p.m.
On Thu, Feb 26, 2015 at 02:33:17PM -0700, Pete Travis wrote:
On Feb 26, 2015 9:01 AM, "Zbigniew Jędrzejewski-Szmek"
<zbyszek(a)in.waw.pl>
wrote:
>
> On Thu, Feb 26, 2015 at 08:51:46AM -0700, Pete Travis wrote:
> > The only time I've needed sysrq reboots in recent memory was while
running
> > rawhide and knowingly venturing into uncharted territory. If I'm not
the
> > only one, would it make sense to include appropriate sysctl snippets in
> > fedora-release-rawhide ?
> We could ship /etc/sysctl.d/sysrq-enable.conf.disabled (name up for
discussion),
> and interested users could enable it by renaming the file. Maybe even
better
> to provide it the same in all versions.
>
> Zbyszek
> --
>
All versions might be overkill, but I don't see the harm in the added
convenience, either. What's the next step?
Somebody should do the change :)
But there's a snag: systemd-sysctl warns
about overrides:
Overwriting earlier assignment of kernel/sysrq in file
'/etc/sysctl.d/60-local.conf'.
I think we should change this upstream (downgrade to debug). And thinking
about this more, creating a separate file seems overkill. Just adding
a comment in 50-default.conf should be enough.
Zbyszek
5:39 p.m.
Am 27.02.2015 um 00:32 schrieb Zbigniew Jędrzejewski-Szmek:
> All versions might be overkill, but I don't see the harm in
the added
> convenience, either. What's the next step?
Somebody should do the change :) But there's a snag: systemd-sysctl warns
about overrides:
Overwriting earlier assignment of kernel/sysrq in file
'/etc/sysctl.d/60-local.conf'.
I think we should change this upstream (downgrade to debug). And thinking
about this more, creating a separate file seems overkill. Just adding
a comment in 50-default.conf should be enough
and i hate all this systemd log flooding so much.....
6:10 p.m.
On Fri, Feb 27, 2015 at 12:39:23AM +0100, Reindl Harald wrote:
Am 27.02.2015 um 00:32 schrieb Zbigniew Jędrzejewski-Szmek:
>>All versions might be overkill, but I don't see the harm in the added
>>convenience, either. What's the next step?
>Somebody should do the change :) But there's a snag: systemd-sysctl warns
>about overrides:
>Overwriting earlier assignment of kernel/sysrq in file
'/etc/sysctl.d/60-local.conf'.
>I think we should change this upstream (downgrade to debug). And thinking
>about this more, creating a separate file seems overkill. Just adding
>a comment in 50-default.conf should be enough
OK, done upstream. Should land in
F22+ soon enough.
http://cgit.freedesktop.org/systemd/systemd/commit/?id=16b65d7f46
http://cgit.freedesktop.org/systemd/systemd/commit/?id=16b65d7f46^
and i hate all this systemd log flooding so much.....
One down
:)
Zbyszek
8:39 a.m.
On 02/25/2015 03:04 PM, Josh Boyer wrote:
On Wed, Feb 25, 2015 at 8:54 AM, Ali AlipourR
<alipoor90(a)gmail.com> wrote:
> Hi,
>
> Why sysrq is limited to only "sync" command on official fedora kernel?
The kernel itself isn't limited. It's just set that way in
/usr/lib/sysctl.d/50-default.conf which is provided by systemd. You
can edit that file,
The file in /usr will be overwritten by the next package update.
create your own in /etc/sysctl.d/,
Yes, local configuration belongs to /etc.
See also "man sysctl.d".
or (as root) set it to whatever you would like via
/proc/sys/kernel/sysrq.
Or pass "sysrq_always_enabled" on the kernel command line.
sysrq_always_enabled
[KNL]
Ignore sysrq setting - this boot parameter will
neutralize any effect of /proc/sys/kernel/sysrq.
Useful for debugging.
Michal
8:14 p.m.
On Wed, Feb 25, 2015 at 9:39 AM, Michal Schmidt
<mschmidt(a)redhat.com> wrote:
> On 02/25/2015 03:04 PM, Josh Boyer wrote:
>> On Wed, Feb 25, 2015 at 8:54 AM, Ali AlipourR <alipoor90(a)gmail.com> wrote:
>> Hi,
>>
>> Why sysrq is limited to only "sync" command on official fedora kernel?
>
> The kernel itself isn't limited. It's just set that way in
> /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You
> can edit that file,
The file in /usr will be overwritten by the next package update.
> create your own in /etc/sysctl.d/,
Yes, local configuration belongs to /etc.
See also "man sysctl.d".
Except, of course, that it is apparently Leonard Pottering's announced desire to stop
people from using /etc/
8:22 p.m.
On 02/27/2015 06:14 PM, Nico Kadel-Garcia wrote:
Except, of course, that it is apparently Leonard Pottering's
announced desire to stop people from using /etc/
No, it's not. Why do people insist on misinterpreting him?
He wants it to be possible to have a read-only / (including /etc), so
*dynamic* information needs to be stored elsewhere.
8:28 p.m.
Am 28.02.2015 um 03:14 schrieb Nico Kadel-Garcia:
> On Wed, Feb 25, 2015 at 9:39 AM, Michal Schmidt
<mschmidt(a)redhat.com> wrote:
>> On 02/25/2015 03:04 PM, Josh Boyer wrote:
>>> On Wed, Feb 25, 2015 at 8:54 AM, Ali AlipourR <alipoor90(a)gmail.com>
wrote:
>>> Hi,
>>>
>>> Why sysrq is limited to only "sync" command on official fedora
kernel?
>>
>> The kernel itself isn't limited. It's just set that way in
>> /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You
>> can edit that file,
>
> The file in /usr will be overwritten by the next package update.
>
>> create your own in /etc/sysctl.d/,
>
> Yes, local configuration belongs to /etc.
> See also "man sysctl.d".
Except, of course, that it is apparently Leonard Pottering's announced desire to stop
people from using /etc/
stop that trolling
*local* CONFIGURATIONS belong to /etc and nothing else
Lennarts point is that any defaults and package data don't belong there
and he is not completly wrong in that context - in the best case you
would have a operating system with *nothing* in /etc and any package
shipped stuff can have a *override* file with the same name in /etc
at the end this would also obsolete all that rpmnew / rpmsave stuff just
because files from packages would no longer be touched by a user but
*completly* ignored from the moment there is a replacement in /etc
4:37 a.m.
On Fri, 27.02.15 21:14, Nico Kadel-Garcia (nkadel(a)gmail.com) wrote:
> On Wed, Feb 25, 2015 at 9:39 AM, Michal Schmidt
<mschmidt(a)redhat.com> wrote:
>> On 02/25/2015 03:04 PM, Josh Boyer wrote:
>>> On Wed, Feb 25, 2015 at 8:54 AM, Ali AlipourR <alipoor90(a)gmail.com>
wrote:
>>> Hi,
>>>
>>> Why sysrq is limited to only "sync" command on official fedora
kernel?
>>
>> The kernel itself isn't limited. It's just set that way in
>> /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You
>> can edit that file,
>
> The file in /usr will be overwritten by the next package update.
>
>> create your own in /etc/sysctl.d/,
>
> Yes, local configuration belongs to /etc.
> See also "man sysctl.d".
Except, of course, that it is apparently Leonard Pottering's
announced desire to stop people from using /etc/
Hmm? What? I figure "Leonard Pottering" cannot be a misspelling of my
name, given that what you claim his desire to be is certainly not even
remotely mine.
Plese stop FUDding around!
Thank you,
Lennart
--
Lennart Poettering, Red Hat
3343
days inactive
3346
days old
28 comments
13 participants
participants (13)
-
Ahmad Samir -
Ali AlipourR -
Chris Adams -
Josh Boyer -
Lennart Poettering -
Michal Schmidt -
Nico Kadel-Garcia -
Paul Wouters -
Pete Travis -
Reindl Harald -
Samuel Sieb -
Zbigniew Jędrzejewski-Szmek -
Zdenek Kabelac