Q: executables in /lib/udev , is this correct?

Jeremy Henty onepoint at starurchin.org
Fri Aug 22 15:24:12 PDT 2008


On Fri, Aug 22, 2008 at 03:31:36PM -0300, Valter Douglas Lisbôa Jr. wrote:
> Em Thursday 21 August 2008 14:51:12 Jeremy Henty escreveu:
> > I  just noticed that  both my  LFS 6.1  and 6.3  systems installed
> > useful  executables  such as  vol_id  into  /lib/udev rather  than
> > anywhere in my $PATH .
> 
> This executables is  not need to be in the PATH,  they are called by
> udev tools in background.  They Follow the /usr/lib/<program>/* idea
> to  separate  libraries,  backstage  daemons, whatever  from  system
> aplications runned in terminals,

I understand  what you say,  but I expected something  different after
reading a good article "How To Manage Your Disk By UUID On Linux"

    http://linuxshellaccount.blogspot.com/2008/08/how-to-manage-your-disk-by-uuid-on.html

which says things like

    1. If  you don't know the  UUID of your  disk, you can find  it by
    using one of the several commands below:

    host # vol_id /dev/sda3
    ...
    ID_FS_UUID=a1331d73-d640-4bac-97b4-cf33a375ae5b

which fails on LFS because vol_id is not in $PATH .  So maybe there is
a  case  for putting  such  things  in /bin  rather  than  /lib ?   It
certainly suggests that other distros  do that, since the writer seems
to assume  that these commands will  be in $PATH .   (I understand the
reasons for not putting them in /usr .)

(BTW, I'm not  trying to lay down the law here,  just raising an issue
than confused me and wondering what it means.)

> ... personaly,  I put the iptables  modules there [not  in /usr] too
> (my Firewall starts very early :-) )

OK, I'm interested.  I consider myself fairly security-conscious but I
can't  see the  need  to  start iptables  before  mounting local  file
systems  like /usr  .   As long  as  your firewall  starts before  the
network, what  could possibly go wrong?  (Famous  last words!)  Unless
your /usr is networked?

Regards, 

Jeremy Henty 



More information about the lfs-support mailing list