Now I'm convinced about Linux

Now I'm convinced about Linux

[Kevin Chadwick]

I have often heard in certain circles that Linux messes things up by
trying to wipe peoples arses.

Having a simple problem today that last_rule would solve just fine and
finding that I must edit extra files or manage a packages file is
quite convincing that they are right, especially the reason
"Inconsistent behaviour" when that is exactly what I expect to be able
to do on Unix and is so often made difficult just on Linux these days
and it seems especially in code mainly managed by RedHat, though I do
not a member of RedHat raising concerns about it.

I have tried creating /lib/udev/rules.d/zzz-arsewipingidiotfix.rules
with LABEL="very_end"

but adding GOTO="very_end" to earlier udev rules
(/etc/udev/rules.d/46-) is having no effect even after a udev restart?

Any ideas?

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

Now I'm convinced about Linux

[Peter Rajnoha]

On 07/26/2013 06:37 PM, Kevin Chadwick wrote:
> Having a simple problem today that last_rule would solve just fine and
> finding that I must edit extra files or manage a packages file is

You should not be pushed into editing udev rules unless you do something
(very) extra. If something does not work correctly as expected, you
should submit a bug report against the relevant distro/package.

What exactly is the nature of the problem that needs such a manual
intervention? Also, what udev rules are we talking about exactly?

> quite convincing that they are right, especially the reason
> "Inconsistent behaviour" when that is exactly what I expect to be able
> to do on Unix and is so often made difficult just on Linux these days
> and it seems especially in code mainly managed by RedHat, though I do
> not a member of RedHat raising concerns about it.
> 
> I have tried creating /lib/udev/rules.d/zzz-arsewipingidiotfix.rules
> with LABEL="very_end"
> 
> but adding GOTO="very_end" to earlier udev rules
> (/etc/udev/rules.d/46-) is having no effect even after a udev restart?
> 
> Any ideas?
> 

Please, provide more information about the problem and if the problem
is related to LVM, then provide the LVM version as well please
Also, is this Fedora or RHEL or are you trying to use upstream
version directly?

Peter

Now I'm convinced about Linux

[Kevin Chadwick]

On Mon, 29 Jul 2013 09:44:36 +0200
Peter Rajnoha wrote:

> On 07/26/2013 06:37 PM, Kevin Chadwick wrote:
> > Having a simple problem today that last_rule would solve just fine and
> > finding that I must edit extra files or manage a packages file is
> 
> You should not be pushed into editing udev rules unless you do something
> (very) extra. If something does not work correctly as expected, you
> should submit a bug report against the relevant distro/package.
> 
> What exactly is the nature of the problem that needs such a manual
> intervention? Also, what udev rules are we talking about exactly?
>

I have written a vendor and product specific rule which loads a key into
truecrypt and then immediately unmounts the usb. Unfortunately later
rules then remount the device. I want the rules to stop evaluation for
just this device. GOTO seems to only apply to the current rules file
(from the logs, the man page needs improving here) and would require
creating another rules file in any case which should not be necessary.

I could edit the rules file which is doing the re-mounting but that is
another packages rules file that I should not have to manage. Also if I
know that there is no need to continue rule evaluation for a device
then it is far cleaner to stop especially if it was an embedded system
(it's not but these things should be thought about (properness, power
to the user/dev)). The usual method is putting big fat warnings on and
not crippling users, and also not updating the man pages in light of
the online tutorials talking about last_rule. I hate to think of all the
wasted devs and users time for this simple lack of consideration.
OpenBSD man pages are brill and I'm sure this kind of problem wouldn't
happen under their watch. I have never had to power up a web browser on
OpenBSD atleast for anything simple.

Perhaps there is a way but I cannot see it from the man pages.
Google seems to say all rules files are processed as one but that
seems not to be the case?

> > quite convincing that they are right, especially the reason
> > "Inconsistent behaviour" when that is exactly what I expect to be able
> > to do on Unix and is so often made difficult just on Linux these days
> > and it seems especially in code mainly managed by RedHat, though I do
> > not a member of RedHat raising concerns about it.
> > 
> > I have tried creating /lib/udev/rules.d/zzz-arsewipingidiotfix.rules
> > with LABEL="very_end"
> > 
> > but adding GOTO="very_end" to earlier udev rules
> > (/etc/udev/rules.d/46-) is having no effect even after a udev restart?
> > 
> > Any ideas?
> > 
> 
> Please, provide more information about the problem and if the problem
> is related to LVM, then provide the LVM version as well please
> Also, is this Fedora or RHEL or are you trying to use upstream
> version directly?
> 

I'm not even sure this is the right list but you seemed to have
committed the last_rule removal with concerns about Kays decision.

Fedora was one of the first unix-like systems I ever used playing with
selinux when first introduced on Fedora (3 I think) but I can't see me
ever installing it again. (I installed it a year or two ago to try
out systemd and I'm about as far from a systemd or polkit and so udisks
fan as you can get, technically and practically)

> Peter

Thanks,
	Kc

Now I'm convinced about Linux

[Peter Rajnoha]

On 07/30/2013 11:56 AM, Kevin Chadwick wrote:
> I have written a vendor and product specific rule which loads a key into
> truecrypt and then immediately unmounts the usb. Unfortunately later
> rules then remount the device. I want the rules to stop evaluation for
> just this device. GOTO seems to only apply to the current rules file
> (from the logs, the man page needs improving here) and would require
> creating another rules file in any case which should not be necessary.

Yes, GOTO applies only to current rule file...

> 
> I could edit the rules file which is doing the re-mounting but that is
> another packages rules file that I should not have to manage. Also if I
> know that there is no need to continue rule evaluation for a device
> then it is far cleaner to stop especially if it was an embedded system
> (it's not but these things should be thought about (properness, power
> to the user/dev)). The usual method is putting big fat warnings on and
> not crippling users, and also not updating the man pages in light of
> the online tutorials talking about last_rule. I hate to think of all the

...I fully understand your concerns. We (LVM) were exactly in the
same situation as we used the 'last_rule' option to skip all the udev
processing that was not suitable as LVM also has some devices which
should not be used for scanning etc. Unfortunately, it seems that at
that time, we were one of the small group of users of this 'last_rule',
so it was not a problem for udev to simply remove it...

> wasted devs and users time for this simple lack of consideration.
> OpenBSD man pages are brill and I'm sure this kind of problem wouldn't
> happen under their watch. I have never had to power up a web browser on
> OpenBSD atleast for anything simple.
> 
> Perhaps there is a way but I cannot see it from the man pages.
> Google seems to say all rules files are processed as one but that
> seems not to be the case?
> 

...well, GOTO applies only to current rule file (so yes, maybe the
documentation should be clearer about this - but that needs to be reported
for udev team).

> I'm not even sure this is the right list but you seemed to have
> committed the last_rule removal with concerns about Kays decision.
> 

(I suppose you mean this one: http://comments.gmane.org/gmane.linux.lvm.devel/2119)

Nope, it wasn't me who wanted removal of that 'last_rule' from udev :)
We used the 'last_rule' ourselves and I remember being angry about its
removal too. Now, we need to set variables within rules which other rules
check... and yes, I had to notify all the other maintainers that owned
those other udev rules to check for these variables to make a skip
(to be honest, I hate this solution, but there is nothing else I could
do with what udev provides to prevent the rules from being scanned or
processed by third-party rules - if I understand correctly, that's exactly
what you're hitting now as well).

> Fedora was one of the first unix-like systems I ever used playing with
> selinux when first introduced on Fedora (3 I think) but I can't see me
> ever installing it again. (I installed it a year or two ago to try
> out systemd and I'm about as far from a systemd or polkit and so udisks
> fan as you can get, technically and practically)
> 

Well, yes, some of these have their advantages and, surely, their disadvantages.
As for udisks and from our LVM point of view, that's exactly the one which
caused extra scans for devices which we didn't want to be scanned and so
I had to negotiate the solution with its maintainer (you can spot some
"DM_UDEV_DISABLE_..." flags being checked now in udisks rules - this is
exactly to prevent that scanning we don't want to).

And to be honest, we've spent quite some time to make all this udev integration
working, to solve all bugs that appeared as a consequence etc.

Thing with Fedora is that it tries to adopt the newest techniques available.
Other distros might be more conservative here... The best in Linux world is
that you can make a decision which distro fits your needs the best.

Anyway, now I can imagine the source of your problems and yes, it's OK
that you made your points. Though in this case, I need to redirect you
to udev/systemd team as I can't help much here...

Peter

Now I'm convinced about Linux

[Kevin Chadwick]

On Wed, 31 Jul 2013 10:14:16 +0200
Peter Rajnoha wrote:

> Unfortunately, it seems that at
> that time, we were one of the small group of users of this 'last_rule',
> so it was not a problem for udev to simply remove it...
> 

Numbers to object should not matter here, it is simply plain and obvious
to me that any developer should realise that this feature should
exist, and obviously they did originally. That is what gets me the
most, as I said warnings yes, power from the user, how terrible.


> ...well, GOTO applies only to current rule file (so yes, maybe the
> documentation should be clearer about this - but that needs to be reported
> for udev team).
> 

Well I edited the rule of the package doing the remounting and
backed it up (removed .rules) in case the package manager overwrites it
but that's a very wrong fix.

Also as long as RedHat now being a support company (primarily) doesn't
have a better internal manual explaining all the events? etc. then that
will keep the conspiracy theorists at bay ;-)

> > I'm not even sure this is the right list but you seemed to have
> > committed the last_rule removal with concerns about Kays decision.
> > 
> 
> (I suppose you mean this one: http://comments.gmane.org/gmane.linux.lvm.devel/2119)
> 

Yeah I should have thought about the context of the list really.


> 
> Anyway, now I can imagine the source of your problems and yes, it's OK
> that you made your points. Though in this case, I need to redirect you
> to udev/systemd team as I can't help much here...

I must say I was expecting some flame or remarks and I am sure I would
get much nonsense about OpenBSD being of no consequence and perhaps dbus
being the heart of any good OS ;-) and maybe even the removal of the
GOTO rule out of spite if I were to post a copy of my last message to
the udev/systemd lot (I won't call what happens there teamwork).

Probably best If I make my post short and to the point, I haven't got
enough minutes never mind hours to tell Lennart how wrong he is on so
many things and argue about why he doesn't allow commenting and
ignores so much on his myths about systemd page.

You seem a real credit to RedHat. Perhaps RedHat should consider
protecting it's brand by putting some of the smaller projects which get
so much coverage shall we say under a seperate brand, perhaps
Dpointyhat.

   |
  | |
 | D |
|_____|

Cheap shot maybe but I always say what I think, where it's not cruel
atleast.

Regards,
	Kc