devil-linux-develop Mailing List for Devil-Linux (Page 38)

Quoting Bruce Smith <bw...@ar...>:

>> >> >> If my memory serves me right, I think we're doing a couple chmods,
>> >> >> maybe some chowns during the boot process, maybe that's what's
>> >> >> screwing with it.
>> >> >
>> >> > You mean:  /etc/init.d/setfileperm  ???
>> >> >
>> >> > Yeah, those look like the files that are being created in etc-mods.
>> >> >
>> >> > Do we still need to run that script at boot time?
>> >>
>> >> Well we need to make sure the perms are right on the default config
>> >> which comes out of our build. Then we can get rid of the script.
>> >> There was a reason why I added the script in the first place, but of
>> >> course I can't remember why...
>> >
>> > How about I rewrite the script so it only changes permissions on files
>> > that need them changed?
>>
>> even better
>
> OK, I have that done, which causes another problem.
>
> There are a bunch of files in "permissions.base" that are on the CD,
> like /usr files.  Is "permissions.base" used anywhere else, like during
> the build?  Is it going to cause problems if I comment out the RO files?

I'm really not sure about that, did you grep for it?

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

> > >> >> If my memory serves me right, I think we're doing a couple chmods,
> > >> >> maybe some chowns during the boot process, maybe that's what's
> > >> >> screwing with it.
> > >> >
> > >> > You mean:  /etc/init.d/setfileperm  ???
> > >> >
> > >> > Yeah, those look like the files that are being created in etc-mods.
> > >> >
> > >> > Do we still need to run that script at boot time?
> > >>
> > >> Well we need to make sure the perms are right on the default config
> > >> which comes out of our build. Then we can get rid of the script.
> > >> There was a reason why I added the script in the first place, but of
> > >> course I can't remember why...
> > >
> > > How about I rewrite the script so it only changes permissions on files
> > > that need them changed?
> > 
> > even better
> 
> OK, I have that done, which causes another problem.
> 
> There are a bunch of files in "permissions.base" that are on the CD,
> like /usr files.  Is "permissions.base" used anywhere else, like during
> the build?  Is it going to cause problems if I comment out the RO files?

I've done a lot of find's and grep's and I can't see where 
/etc/sysconfig/permissions.base is used anywhere in the build process,
so I'm going to modify it and comment out the stuff on the CD.  

My guess is it's a file copied from some other distro a long time ago.

 - BS

> >> >> If my memory serves me right, I think we're doing a couple chmods,
> >> >> maybe some chowns during the boot process, maybe that's what's
> >> >> screwing with it.
> >> >
> >> > You mean:  /etc/init.d/setfileperm  ???
> >> >
> >> > Yeah, those look like the files that are being created in etc-mods.
> >> >
> >> > Do we still need to run that script at boot time?
> >>
> >> Well we need to make sure the perms are right on the default config
> >> which comes out of our build. Then we can get rid of the script.
> >> There was a reason why I added the script in the first place, but of
> >> course I can't remember why...
> >
> > How about I rewrite the script so it only changes permissions on files
> > that need them changed?
> 
> even better

OK, I have that done, which causes another problem.

There are a bunch of files in "permissions.base" that are on the CD,
like /usr files.  Is "permissions.base" used anywhere else, like during
the build?  Is it going to cause problems if I comment out the RO files?

 - BS

Quoting Bruce Smith <bw...@ar...>:

>> >> If my memory serves me right, I think we're doing a couple chmods,
>> >> maybe some chowns during the boot process, maybe that's what's
>> >> screwing with it.
>> >
>> > You mean:  /etc/init.d/setfileperm  ???
>> >
>> > Yeah, those look like the files that are being created in etc-mods.
>> >
>> > Do we still need to run that script at boot time?
>>
>> Well we need to make sure the perms are right on the default config
>> which comes out of our build. Then we can get rid of the script.
>> There was a reason why I added the script in the first place, but of
>> course I can't remember why...
>
> How about I rewrite the script so it only changes permissions on files
> that need them changed?

even better

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

> >> If my memory serves me right, I think we're doing a couple chmods,
> >> maybe some chowns during the boot process, maybe that's what's
> >> screwing with it.
> >
> > You mean:  /etc/init.d/setfileperm  ???
> >
> > Yeah, those look like the files that are being created in etc-mods.
> >
> > Do we still need to run that script at boot time?
> 
> Well we need to make sure the perms are right on the default config  
> which comes out of our build. Then we can get rid of the script.
> There was a reason why I added the script in the first place, but of  
> course I can't remember why...

How about I rewrite the script so it only changes permissions on files
that need them changed? 
 - BS

Quoting Bruce Smith <bw...@ar...>:

>> If my memory serves me right, I think we're doing a couple chmods,
>> maybe some chowns during the boot process, maybe that's what's
>> screwing with it.
>
> You mean:  /etc/init.d/setfileperm  ???
>
> Yeah, those look like the files that are being created in etc-mods.
>
> Do we still need to run that script at boot time?

Well we need to make sure the perms are right on the default config  
which comes out of our build. Then we can get rid of the script.
There was a reason why I added the script in the first place, but of  
course I can't remember why...

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

> If my memory serves me right, I think we're doing a couple chmods,  
> maybe some chowns during the boot process, maybe that's what's  
> screwing with it.

You mean:  /etc/init.d/setfileperm  ???

Yeah, those look like the files that are being created in etc-mods.

Do we still need to run that script at boot time?

 - BS

Quoting Bruce Smith <br...@ar...>:

>> >>> CD, but the files are in the mods directory.  Any clue why?
>> >> Are you sure they weren't put there when you loaded the mods dir?
>> >
>> > I'm sure I didn't load those files.
>>
>> I knew that would be the case, but one has to ask ;-)
>
> The exact same problem exists in both UnionFS and aufs.
>
> The problem occurs after the linuxrc and pre_init scripts, (I stuck a
> "ls /shm/etc-mods" at the very end of pre_init, and the files weren't
> there at that time), so something past /sbin/init causes those files to
> appear in the mods.
>
> I grep'ed all the init scripts, and I can't find where most of those
> files are referenced at all.  One guess is some binary program is
> opening those files RW, but not modifying them.  Any other ideas?
>
> One other idea I ruled out is I thought maybe the date on the files
> (1/1/1980) was too close to the epoch or too far in the past, confusing
> the union/aufs.  So I temporally modified the build script that does the
> touch and changed the date from 1/1/1980 to 1/1/1990, but that didn't
> help either.   :-(
>
> BTW, there is only a few files with this problem, and it doesn't hurt
> anything, so I didn't hold up the release of 1.3.5 for this.  Even if it
> never gets fixed, it's no big deal.  It just bugs me ...

If my memory serves me right, I think we're doing a couple chmods,  
maybe some chowns during the boot process, maybe that's what's  
screwing with it.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

> > The mount goes like this (as I recall from memory):
> > mount -t aufs -o dirs=/shm/etc-mods:/etc-cd=ro none /shm/etc
> > 
> > Make sense?
> 
> I thought yesterday you'd done something differently.  Basically I 
> didn't understand - still don't actually.
> 
> If you look in mtab  the mount looks quite different. In particualer 
> /etc-cd is mounted rr (really readonly).  Is this significant?  Probably 
> not.  

I typed the mount yesterday from memory.  A copy/paste of the actual
mount being used is:

  mount -n -t aufs -o br:/shm/etc-mods:/etc-cd=rr none /shm/etc

I tried "rr" and "ro" for /etc-cd without any difference.  The docs say
that "rr" is faster for volumes that cannot physically be written to,
like a CD or ISO9660, so I settled on "rr".

Keep in mind, that "mount.aufs" is a shell script, that tweaks the
command line options, which is why /proc/mounts & mtab is different.

FYI, when running UnionFS, the equivalent mount statement used was:

  mount -n -t unionfs -o dirs=/shm/etc-mods:/etc-cd=ro none /shm/etc

> But it is like the whole of /etc-cd is being written into 
> etc-mods.  It's baffling.

It's not the whole thing.  On a DL Apache / PHP / MySQL / firewall I'm
running, the size difference between the saved configs is significant:

-rwxr-xr-x 1 root root  230221 Apr 16 16:12 etc-mods.tar.bz2
-rwxr-xr-x 1 root root 1114236 Apr 16 19:21 etc.tar.bz2

After sleeping on it, I have another theory.  Which may or may not go
anywhere.  I'll let you know if I find anything!  :-)

 - BS

Quoting Bruce Smith <bw...@ar...>:

> What's the deal with "scripts/build-etc" ?
>
> I was grep'ing for "etc.tar.bz2" in the scripts directory, and build-etc
> appears.  Then I grep for build-etc, and nothing seems to run or
> reference it.  Is it an obsolete file?

No idea, must be some leftover from the good old days...

Whack it.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Bruce Smith wrote:

> Something else is going on.  Something that we haven't thought of yet ...

:-)

Dick

Bruce Smith wrote:
> The mount goes like this (as I recall from memory):
> mount -t aufs -o dirs=/shm/etc-mods:/etc-cd=ro none /shm/etc
> 
> Make sense?

I thought yesterday you'd done something differently.  Basically I 
didn't understand - still don't actually.

If you look in mtab  the mount looks quite different. In particualer 
/etc-cd is mounted rr (really readonly).  Is this significant?  Probably 
not.  But it is like the whole of /etc-cd is being written into 
etc-mods.  It's baffling.

I'll try to look more tonight.

Dick

>> Bruce,
>>
>> I just loaded DL 1.3.5 on VirtualBox without a etc.tar.bz2.  It comes up just fine.
>>
>> It seems we have /etc-cd  /shm/etc-mods and /shm/etc
>>
>> My first question is what is etc-mods - is that a default etc.tar.bz2 ?  If so I 
>> would expect that to be empty.  It seems to contain a lot of stuff like for 
>> example services all the postfix defaults etc etc.  It looks like you are 
>> copying a default etc.tar.bz2 into it. I assume that's where your mystery files 
>> are coming from.
>>     
>
> Sorry - just catching up.
>
> I don't understand this either!   What is going on????  Something is copying the 
>   etc-cd into etc-mods.
>   

etc-mods is brand new, so nothing is copying anything directly into that 
directory.

Something may be copying files into /etc, which puts the aufs 
modifications into /shm/etc-mods.  But that doesn't make sense either.  
Why would something copy files over top of themselves?  And if they were 
copied, they would have a newer modification date than 1980.

Something else is going on.  Something that we haven't thought of yet ...
 
 - BS

The mount goes like this (as I recall from memory):
mount -t aufs -o dirs=/shm/etc-mods:/etc-cd=ro none /shm/etc

And /etc is a symlink to /shm/etc.  (left over from from previous 
releases)  I realize I could have eliminated the symlink and just mount 
it on /etc but I left the sym link there (seemed like a good idea at the 
time).  Maybe in a future release.

save-config now saves /shm/etc-mods since that's where the modified /etc 
files are stored.

Also read the CHANGES file; I explain a little more there.

Make sense?

 - BS

> Bruce,
>
> I just loaded DL 1.3.5 on VirtualBox without a etc.tar.bz2.  It comes up just fine.
>
> It seems we have /etc-cd  /shm/etc-mods and /shm/etc
>
> My first question is what is etc-mods - is that a default etc.tar.bz2 ?  If so I 
> would expect that to be empty.  It seems to contain a lot of stuff like for 
> example services all the postfix defaults etc etc.  It looks like you are 
> copying a default etc.tar.bz2 into it. I assume that's where your mystery files 
> are coming from.
>
> What are you intending there?
>
> I take it /shm/etc is just a mount point for the aufs - is that right?
>
> The way I envisaged it was that etc.tar.bz2 would be loaded into /shm/etc-mods 
> if it existed (otherwise /shm/etc-mods would be empty).
>
> /etc-cd and /shm/etc-mods would be mounted aufs on /shm/etc.
>
> Any config changes in /etc would appear in /shm/etc-mods and ultimately copied 
> to etc.tar.bz2.
>
> Dick
>   

Dick Middleton wrote:
> Bruce,
> 
> I just loaded DL 1.3.5 on VirtualBox without a etc.tar.bz2.  It comes up just fine.
> 
> It seems we have /etc-cd  /shm/etc-mods and /shm/etc
> 
> My first question is what is etc-mods - is that a default etc.tar.bz2 ?  If so I 
> would expect that to be empty.  It seems to contain a lot of stuff like for 
> example services all the postfix defaults etc etc.  It looks like you are 
> copying a default etc.tar.bz2 into it. I assume that's where your mystery files 
> are coming from.

Sorry - just catching up.

I don't understand this either!   What is going on????  Something is copying the 
  etc-cd into etc-mods.

Dick

Dick Middleton wrote:
> Since moving to 1.3.4 I've been getting messages like this every day:
> 
> Cron <root@Devil> /usr/sbin/cron.interval daily
> 
> zcat: /var/log/mail.log.4.gz already has .gz suffix -- unchanged
> zcat: /var/log/mail.log.3.gz already has .gz suffix -- unchanged
> zcat: /var/log/mail.log.2.gz already has .gz suffix -- unchanged
> zcat: /var/log/messages.2.gz already has .gz suffix -- unchanged
> zcat: /var/log/apache2/access.log.2.gz already has .gz suffix -- unchanged
> 
> It seems to be logwatch that is producing these.

I think this is because zcat is a sym link to gzip

On Debian zcat is a script which does exec gzip -cd "$@"

So here zcat is trying to compress file again rather than uncompress and send to 
stdout.

Dick

Bruce,

I just loaded DL 1.3.5 on VirtualBox without a etc.tar.bz2.  It comes up just fine.

It seems we have /etc-cd  /shm/etc-mods and /shm/etc

My first question is what is etc-mods - is that a default etc.tar.bz2 ?  If so I 
would expect that to be empty.  It seems to contain a lot of stuff like for 
example services all the postfix defaults etc etc.  It looks like you are 
copying a default etc.tar.bz2 into it. I assume that's where your mystery files 
are coming from.

What are you intending there?

I take it /shm/etc is just a mount point for the aufs - is that right?

The way I envisaged it was that etc.tar.bz2 would be loaded into /shm/etc-mods 
if it existed (otherwise /shm/etc-mods would be empty).

/etc-cd and /shm/etc-mods would be mounted aufs on /shm/etc.

Any config changes in /etc would appear in /shm/etc-mods and ultimately copied 
to etc.tar.bz2.

Dick

> >>>>> CD, but the files are in the mods directory.  Any clue why?
> >>>> Are you sure they weren't put there when you loaded the mods dir?
> >>> I'm sure I didn't load those files.
> 
> > The exact same problem exists in both UnionFS and aufs.
> 
> So, something to do with DL then.

Appears to be the case.

> > The problem occurs after the linuxrc and pre_init scripts, (I stuck a
> > "ls /shm/etc-mods" at the very end of pre_init, and the files weren't
> > there at that time), so something past /sbin/init causes those files to
> > appear in the mods.
> 
> Something's doing it.  To keep that old mtime it would have to be copying and 
> restoring them.  Sort of thing tar or cpio does.  They're not in initramfs and 
> being copied back before pivot root.

I can't find any commonalities between the files that are in etc-mods.

All the scripts/files in etc-mods/init.d/ are there.
So I'm thinking maybe they have to be there if there are symlinks to the
files for some reason internal to the workings of aufs.

But then again, all the files in sysconfig/nic/* are there too,
including the _sample_ files!  There are no links to those files, and I
don't think anything would even look at those SAMPLE files during boot!

And there are files in mods for postfix/* and ppp/* too!  This is a
fresh/copy-your-config-to-blank-floppy-boot!  I'm not running postfix or
ppp (or any other services with the default config).  WEIRD!!!

Maybe I need to join the aufs mailing list and start asking questions...

 - BS

Bruce Smith wrote:
>>>>> CD, but the files are in the mods directory.  Any clue why?
>>>> Are you sure they weren't put there when you loaded the mods dir?
>>> I'm sure I didn't load those files.

> The exact same problem exists in both UnionFS and aufs.

So, something to do with DL then.

> The problem occurs after the linuxrc and pre_init scripts, (I stuck a
> "ls /shm/etc-mods" at the very end of pre_init, and the files weren't
> there at that time), so something past /sbin/init causes those files to
> appear in the mods.

Something's doing it.  To keep that old mtime it would have to be copying and 
restoring them.  Sort of thing tar or cpio does.  They're not in initramfs and 
being copied back before pivot root.

> I grep'ed all the init scripts, and I can't find where most of those
> files are referenced at all.  One guess is some binary program is
> opening those files RW, but not modifying them.  Any other ideas?

 > It just bugs me ...

It would me too.

Dick

> >>> CD, but the files are in the mods directory.  Any clue why?
> >> Are you sure they weren't put there when you loaded the mods dir?
> > 
> > I'm sure I didn't load those files.
> 
> I knew that would be the case, but one has to ask ;-)

The exact same problem exists in both UnionFS and aufs.

The problem occurs after the linuxrc and pre_init scripts, (I stuck a
"ls /shm/etc-mods" at the very end of pre_init, and the files weren't
there at that time), so something past /sbin/init causes those files to
appear in the mods.

I grep'ed all the init scripts, and I can't find where most of those
files are referenced at all.  One guess is some binary program is
opening those files RW, but not modifying them.  Any other ideas?

One other idea I ruled out is I thought maybe the date on the files
(1/1/1980) was too close to the epoch or too far in the past, confusing
the union/aufs.  So I temporally modified the build script that does the
touch and changed the date from 1/1/1980 to 1/1/1990, but that didn't
help either.   :-(

BTW, there is only a few files with this problem, and it doesn't hurt
anything, so I didn't hold up the release of 1.3.5 for this.  Even if it
never gets fixed, it's no big deal.  It just bugs me ...

 - BS

What's the deal with "scripts/build-etc" ?

I was grep'ing for "etc.tar.bz2" in the scripts directory, and build-etc
appears.  Then I grep for build-etc, and nothing seems to run or
reference it.  Is it an obsolete file?

 - BS

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

I played around within my network and found out that it could be useful to have a tool
for decoding the various traffic/protocols flooding around.

There is a nice configure option in wireshark to tell the script to build only the
console version (tshark).

As far as i tested, it works nice within DL-1.3.4 and if more people like that idea i
could provide the scripts for DL integration.

What do you think about tshark support in DL?


sample output:

> Linux Devil 2.6.24.4 #1 SMP Tue Apr 15 21:38:40 Local time zone must be set--see zic  i686 prescott i386 GNU/Linux
> root@Devil:~ # tshark -i br0
> Capturing on br0
>   0.000000 192.168.10.1 -> 192.168.10.255 CUPS ipp://192.168.10.1:631/printers/kyocera (idle)
>   0.000086  192.168.2.1 -> 192.168.2.255 CUPS ipp://192.168.2.1:631/printers/kyocera (idle)
>   0.782132 192.168.10.216 -> 192.168.10.242 TCP rockwell-csp3 > 33773 [PSH, ACK] Seq=1 Ack=1 Win=191 [TCP CHECKSUM INCORRECT] Len=144 TSV=837300 TSER=1612136


Regards,

Oliver



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org

iD8DBQFIBcnE724ZL5LNhNcRAjKHAJoDp6hoT2RKnIUyW5+CqK/ALadc9wCeNNEj
4rr82L0Y37rKmzyifoi779g=
=a3rZ
-----END PGP SIGNATURE-----

> >>> CD, but the files are in the mods directory.  Any clue why?
> >> Are you sure they weren't put there when you loaded the mods dir?
> > 
> > I'm sure I didn't load those files.
> 
> I knew that would be the case, but one has to ask ;-)

I'm getting closer to figuring out where they are coming from ...
(more later, hopefully)  :-)

> > I'm trying aufs now, but I haven't got it's mount to work in the boot
> > script yet (pre_init - and yes the module is loaded).  It works fine
> > after the system is booted.
> 
> You're doing well.

I have it running now with /etc mounted as aufs.  It needed more things
available at that point in the boot process (/proc , /dev and /var/tmp)
than UnionFS needed.

I think I'll go with aufs since UnionFS was giving me a bunch of weird
warnings.  (that appears to be a common complaint)

> What's your overall impression so far?  Does it actually make things easier?

Easier?  (the upgrade to a new version script was a real pain to fix! :)

I don't know about _easier_, but it sure makes the saved config tarfile
a WHOLE LOT _smaller_!!!!!!   :-)

I plan on running a fresh/mrproper compile tonight.  If all goes well, I
hope to check it in tomorrow.

 - BS

Bruce Smith wrote:

>>> CD, but the files are in the mods directory.  Any clue why?
>> Are you sure they weren't put there when you loaded the mods dir?
> 
> I'm sure I didn't load those files.

I knew that would be the case, but one has to ask ;-)

> I'm trying aufs now, but I haven't got it's mount to work in the boot
> script yet (pre_init - and yes the module is loaded).  It works fine
> after the system is booted.

You're doing well.

What's your overall impression so far?  Does it actually make things easier?

Dick

> > I have DL running with the mods for /etc/ in a UnionFS.
> > 
> > There is an expanded /etc on the CD, the mods in /shm, joined to the
> > real /etc directory.
> > 
> > One odd thing I've noticed.  The mods directory contains some files that
> > have not been changed (like /etc/services and a few others).  The dates
> > are 1980, and 'diff' shows they are exactly the same as the file on the
> > CD, but the files are in the mods directory.  Any clue why?
> 
> Are you sure they weren't put there when you loaded the mods dir?

I'm sure I didn't load those files.

I'm trying aufs now, but I haven't got it's mount to work in the boot
script yet (pre_init - and yes the module is loaded).  It works fine
after the system is booted.

 - BS