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

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

>> Sorry for my late and sparse answers, but I'm currently moving into my
>> new house and I'm sick...
>
> No problem, I hope you feel better soon!
>
>> You can turn it off globally via menuconfig (requires are mrproper) or
>> for specific programs by adding
>> CC="gcc -fPIC -fno-stack-protector -U_FORTIFY_SOURCE -nonow -nopie" to
>> the make statement.
>
> OK, I added that CC to the make in both httpd and php build scripts.
>
> 'make clean makefile', and now ... Apache/PHP file uploads work!  :-)
>
>> The CC statement I gave you here turns everything off, you may only
>> need a subset of it.
>
> Now comes the long process of trial & error to see which option causes
> the problem ...   :-(
>
> I'm guessing that only PHP needs the CC option(s), since I'm using PHP
> to do the file uploads, so I'll try removing the CC from httpd first.
>
> Assuming that works, any idea what option(s) are most likely to solve
> the problem on PHP, so I can try them first?

Try the fortify source first, then I'd play with the pie stuff (now  
I'm getting hungry).

-- 

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


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

> Sorry for my late and sparse answers, but I'm currently moving into my  
> new house and I'm sick...

No problem, I hope you feel better soon!

> You can turn it off globally via menuconfig (requires are mrproper) or  
> for specific programs by adding
> CC="gcc -fPIC -fno-stack-protector -U_FORTIFY_SOURCE -nonow -nopie" to  
> the make statement.

OK, I added that CC to the make in both httpd and php build scripts.

'make clean makefile', and now ... Apache/PHP file uploads work!  :-)

> The CC statement I gave you here turns everything off, you may only  
> need a subset of it.

Now comes the long process of trial & error to see which option causes
the problem ...   :-(

I'm guessing that only PHP needs the CC option(s), since I'm using PHP
to do the file uploads, so I'll try removing the CC from httpd first.

Assuming that works, any idea what option(s) are most likely to solve
the problem on PHP, so I can try them first?

 - BS

> > Well, I'm happy to know your system is OK. :-)
> > May I ask to share modified config lines?  We'll add it to default logrotate
> > config to avoid such problem in future...
> 
> In /etc/logrotate.conf
> 
> compresscmd /usr/bin/gzip

Since I'm mucking around in the source code now, I added it to CVS.

 - BS

Serge,

> Well, I'm happy to know your system is OK. :-)
> May I ask to share modified config lines?  We'll add it to default logrotate
> config to avoid such problem in future...

In /etc/logrotate.conf

compresscmd /usr/bin/gzip

Dick

Hi Dick,

Dick Middleton wrote:
> Serge,
> 
>> - modify logrotate section and add "compresscmd".
>> - I have no idea why but looks like the problem with environment, so please
>> don't use for 'compresscmd' a command which is a bash wrapper, use exactly the
>> binary (with necessary options).
>>
>> I think it helps.
> 
> I have to say I'm surprised :-)  but that worked OK last night. Have 
> some extra kudos from me.
Well, I'm happy to know your system is OK. :-)
May I ask to share modified config lines?  We'll add it to default logrotate
config to avoid such problem in future...

-- 
Serge

I moved this threat to the develop mailinglist.

Sorry for my late and sparse answers, but I'm currently moving into my  
new house and I'm sick...
You can turn it off globally via menuconfig (requires are mrproper) or  
for specific programs by adding
CC="gcc -fPIC -fno-stack-protector -U_FORTIFY_SOURCE -nonow -nopie" to  
the make statement.
Some programs require a little bit different approach.

The CC statement I gave you here turns everything off, you may only  
need a subset of it.


-- 

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



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

>> I think it's the hardened compile options for GCC.
>
> How can I turn them off to test this?
>
> Do I have to change the menuconfig options (which ones?) and start over
> with a mrproper?
>
> Or can I just turn off stack protection (or something?) in the build
> script?  PHP or Apache or both?
>
> Let me know and I can start a fresh compile (if needed) tonight.
>
>  - BS
>
>
>> I can't really look into right now, I'm moving and I'm happy that I
>> even can read my emails... ;-)
>>
>> --
>>
>> Regards
>>    Heiko Zuerker
>>    http://www.devil-linux.org
>>
>>
>>
>> Quoting Bruce Smith <bw...@ar...>:
>>
>> > Yes, I have whatever security features are in the 'server' options.
>> >
>> > What should I to turn off to test this?
>> >
>> > Can I turn it off for just apache and/or php? (how?)
>> >
>> >   - BS
>> >
>> >
>> >> I noticed a smiliar behaviour with php/squirrelmail and sending
>> >> emails.
>> >> Do you have any of the security features on? I think it worked when I
>> >> turned off the hardened compile. Unfortunately I didn't have time to
>> >> look further into it.
>> >>
>> >> --
>> >>
>> >> Regards
>> >>   Heiko Zuerker
>> >>   http://www.devil-linux.org
>> >>
>> >>
>> >>
>> >> Quoting Bruce Smith <bw...@ar...>:
>> >>
>> >>> Is there some trick to get file uploads to work in DL 1.3 Apache/PHP?
>> >>>
>> >>> I'm copying/pasting the small example code from the PHP manual and
>> >>> have
>> >>> spent all afternoon google'ing for a solution and trying different
>> >>> values in php.ini.  It doesn't even work with a very SMALL file.
>> >>>
>> >>> When I browse/enter a filename in the input form and press submit,
>> >>> I get
>> >>> nothing from the POST PHP script.  Apache logs this for each attempt:
>> >>>
>> >>> [Wed Apr 23 16:08:01 2008] [notice] child pid 4795 exit signal
>> >>> Segmentation fault (11)
>> >>> [Wed Apr 23 16:12:17 2008] [notice] child pid 4777 exit signal
>> >>> Segmentation fault (11)
>> >>> [Wed Apr 23 16:12:17 2008] [notice] child pid 4825 exit signal
>> >>> Segmentation fault (11)
>> >>> [Wed Apr 23 16:12:23 2008] [notice] child pid 4778 exit signal
>> >>> Segmentation fault (11)
>> >>> ...
>> >>>
>> >>> - BS
>> >>>
>> >>>
>> >>>
>> >>>  
>> -------------------------------------------------------------------------
>> >>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> >>> Don't miss this year's exciting event. There's still time to save
>> >>> $100.
>> >>> Use priority code J8TL2D2.
>> >>>  
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> >>> _______________________________________________
>> >>> Devil-linux-discuss mailing list
>> >>> Dev...@li...
>> >>> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
>> >>>
>> >>
>> >>
>> >>
>> >> ----------------------------------------------------------------
>> >> This message was sent using IMP, the Internet Messaging Program.
>> >>
>> >>
>> >> -------------------------------------------------------------------------
>> >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> >> Don't miss this year's exciting event. There's still time to save
>> >> $100.
>> >> Use priority code J8TL2D2.
>> >>  
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> >> _______________________________________________
>> >> Devil-linux-discuss mailing list
>> >> Dev...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
>> >
>> >
>> > -------------------------------------------------------------------------
>> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> > Don't miss this year's exciting event. There's still time to save $100.
>> > Use priority code J8TL2D2.
>> >  
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> > _______________________________________________
>> > Devil-linux-discuss mailing list
>> > Dev...@li...
>> > https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
>> >
>>
>>
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> Don't miss this year's exciting event. There's still time to save $100.
>> Use priority code J8TL2D2.
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> _______________________________________________
>> Devil-linux-discuss mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Devil-linux-discuss mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
>



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

Serge,

> - modify logrotate section and add "compresscmd".
> - I have no idea why but looks like the problem with environment, so please
> don't use for 'compresscmd' a command which is a bash wrapper, use exactly the
> binary (with necessary options).
> 
> I think it helps.

I have to say I'm surprised :-)  but that worked OK last night. Have 
some extra kudos from me.

Dick

Serge,

>>> I had logrotate fail last night on several files, for example:
>>>
>>> error: failed to compress log /var/log/apache2/access.log.1
>
> - modify logrotate section and add "compresscmd".
> - I have no idea why but looks like the problem with environment, so please
> don't use for 'compresscmd' a command which is a bash wrapper, use exactly the
> binary (with necessary options).

I'll try that, thanks for suggestion.  I'll let you know what happens.

Dick

Hi Dick,

Dick Middleton wrote:
> Dick Middleton wrote:
> 
>  > Version is 1.3.5-2008-04-23-i586
> 
>> I had logrotate fail last night on several files, for example:
>>
>> error: failed to compress log /var/log/apache2/access.log.1
>>
>> I've no idea why and I'm not sure how repeatable that is - it works OK manually. 
> 
> This has done it again.  There's something wrong.  It's even more curious 
> because I have  delaycompress set so it shouldn't be trying to compress these 
> files anyway.
I'm sorry in advance, I cannot allocate time to investigate the problem
properly. Instead I may only suggest you to do several actions to minimize/avoid
"the harm":
- modify logrotate section and add "compresscmd".
- I have no idea why but looks like the problem with environment, so please
don't use for 'compresscmd' a command which is a bash wrapper, use exactly the
binary (with necessary options).

I think it helps.

--
Serge

> 
> It's also true that I'm using copytruncate for all the files that failed.
> 
> I wonder what's changed to provoke this?
> 
> Dick

Dick Middleton wrote:

 > Version is 1.3.5-2008-04-23-i586

> I had logrotate fail last night on several files, for example:
> 
> error: failed to compress log /var/log/apache2/access.log.1
> 
> I've no idea why and I'm not sure how repeatable that is - it works OK manually. 

This has done it again.  There's something wrong.  It's even more curious 
because I have  delaycompress set so it shouldn't be trying to compress these 
files anyway.

It's also true that I'm using copytruncate for all the files that failed.

I wonder what's changed to provoke this?

Dick

> > Bruce moved gzip package to /usr/bin/. Not sure about logrotate, but "man"
> > doesn't work due to wrong path in /etc/man.conf.
> 
> Easy when you know how!  All these years and I never new that existed.

Thanks for reporting the error.  It's fixed in CVS.

 - BS

Serge,

> Bruce moved gzip package to /usr/bin/. Not sure about logrotate, but "man"
> doesn't work due to wrong path in /etc/man.conf.

Easy when you know how!  All these years and I never new that existed.

Thanks

Dick

Hi,

Bruce moved gzip package to /usr/bin/. Not sure about logrotate, but "man"
doesn't work due to wrong path in /etc/man.conf.

-- 
Serge

Dick Middleton wrote:
> I had logrotate fail last night on several files, for example:
> 
> error: failed to compress log /var/log/apache2/access.log.1
> 
> I've no idea why and I'm not sure how repeatable that is - it works OK manually. 
>   I was going to leave it another night then I noticed:
> 
> #man passwd
> sh: /bin/gunzip: No such file or directory
> fgets: No such file or directory
> Error reading man page /usr/share/man/man1/passwd.1.gz
> sh: /bin/gunzip: No such file or directory
> fgets: No such file or directory
> Error reading man page /usr/man/man1/passwd.1.gz
> No manual entry for passwd
> 
> I'm just wondering if these are related.
> 
> My path looks like: /bin:/usr/bin:/sbin:/usr/sbin
> 
> Version is 1.3.5-2008-04-23-i586
> 
> Any suggestions?
> 
> Dick

I had logrotate fail last night on several files, for example:

error: failed to compress log /var/log/apache2/access.log.1

I've no idea why and I'm not sure how repeatable that is - it works OK manually. 
  I was going to leave it another night then I noticed:

#man passwd
sh: /bin/gunzip: No such file or directory
fgets: No such file or directory
Error reading man page /usr/share/man/man1/passwd.1.gz
sh: /bin/gunzip: No such file or directory
fgets: No such file or directory
Error reading man page /usr/man/man1/passwd.1.gz
No manual entry for passwd

I'm just wondering if these are related.

My path looks like: /bin:/usr/bin:/sbin:/usr/sbin

Version is 1.3.5-2008-04-23-i586

Any suggestions?

Dick

> I'm now running my server on the 1.3.5-2008-04-23 release.  Seems to  
> work.

Cool.

> 	1)  There's no message when booting about copying cd to ramfs.  I  
> don't think
> this is working anymore.  How can I tell?

Do you mean "run from ram"?
I haven't tried that option since I added aufs.  :-)

I didn't [knowingly]  modify anything to do with run-from-ram, but  
I'll check it out next week.

>         2)  Why does the loading hotplug modules take so long?  I'm  
> talking a
> minute or so.

I haven't seen that.  Anyone else?

>         3)  aufs usage: if I 'delete' i.e. whiteout a file in the ro  
> filesystem
> how can I restore it i.e. without copying it up?

Deleting it from /shm/etc-mods/  will restore it to original in /etc.

If you delete a file from /etc/ it appears to create a hidden (dot)  
file that marks it as not showing up in /etc.

  - BS

I'm now running my server on the 1.3.5-2008-04-23 release.  Seems to work.

Questions:

	1)  There's no message when booting about copying cd to ramfs.  I don't think 
this is working anymore.  How can I tell?

         2)  Why does the loading hotplug modules take so long?  I'm talking a 
minute or so.

         3)  aufs usage: if I 'delete' i.e. whiteout a file in the ro filesystem 
how can I restore it i.e. without copying it up?

Dick

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

Serge Leschinsky schrieb:
> Hi  Oliver,
> 
> I think it's a counter overflow (probably 32bit counter). If your uptime is more
> than ~64 days you will see the bug also. :-)
> 
> Moreover I'm not sure it's the first discontinuities, so it may take even less time.
> 

Uh, i test so much in the last days that it will be a problem for me to reach the
counter overflow ;-)

but if it happens i will tell you!


Olli ;-)

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

iD8DBQFIEHCN724ZL5LNhNcRAqgJAKCMsKZaN4Xu9h1ny39FguGxMxYJlgCgiA74
dOZHFnHt0IptMkfjw/s1/Y0=
=JL//
-----END PGP SIGNATURE-----

Hi  Oliver,

I think it's a counter overflow (probably 32bit counter). If your uptime is more
than ~64 days you will see the bug also. :-)

Moreover I'm not sure it's the first discontinuities, so it may take even less time.

--
Serge


Oliver Niesner wrote:
>> Probably I found out a bug in procinfo (not critical, of course)
> 
>> root@Devil:~ # uptime
>>  04:17:40 up 65 days, 20:44,  1 user,  load average: 0.00, 0.00, 0.00
>> root@Devil:~ # procinfo | grep uptime
>> uptime:   1d  5:47:06.00         context :235715659     interrupts: 29951675
> 
>> DL 1.3x

> On my system everything seems ok!
> 
> -->
> 
> root@devil:/ # cat DEVIL-LINUX
> 1.3.5-2008-04-22
> 
> root@devil:/ # uptime
>  09:38:40 up 13:28,  1 user,  load average: 0.22, 0.14, 0.08
> 
> root@devil:/ # procinfo |grep uptime
> uptime:      13:28:06.20         context :  6555032
> root@devil:/ #

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

Serge Leschinsky schrieb:
> Hello,
> 
> Probably I found out a bug in procinfo (not critical, of course)
> 
> root@Devil:~ # uptime
>  04:17:40 up 65 days, 20:44,  1 user,  load average: 0.00, 0.00, 0.00
> root@Devil:~ # procinfo | grep uptime
> uptime:   1d  5:47:06.00         context :235715659     interrupts: 29951675
> 
> DL 1.3x
> 

Hi, Serge!

On my system everything seems ok!

- -->

root@devil:/ # cat DEVIL-LINUX
1.3.5-2008-04-22

root@devil:/ # uptime
 09:38:40 up 13:28,  1 user,  load average: 0.22, 0.14, 0.08

root@devil:/ # procinfo |grep uptime
uptime:      13:28:06.20         context :  6555032
root@devil:/ #

<---

- --- Oliver

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

iD8DBQFIEFXM724ZL5LNhNcRAvhDAKCNxc9hTLOFmCpJvpXNNoagDeoGVwCfcO92
KYsHrXZTyM6+3auZiAUxjTc=
=bcDF
-----END PGP SIGNATURE-----

Hello,

Probably I found out a bug in procinfo (not critical, of course)

root@Devil:~ # uptime
 04:17:40 up 65 days, 20:44,  1 user,  load average: 0.00, 0.00, 0.00
root@Devil:~ # procinfo | grep uptime
uptime:   1d  5:47:06.00         context :235715659     interrupts: 29951675

DL 1.3x

--
Serge

> > Usually I use tcpdump for network traffic reviewing and dumping... Why not add
> > it to DL disabled by default? 
> 
> Yes, that would be a good decision. Well, tcpdump does basically the same stuff,
> but tshark has some nice decoding/protocol features, which could be handy if someone
> use DL mainly for network monitoring.

Sure.  tshark could come in handy at times.

I'll probably turn it on by default in the server config,
at least until we start running into space problems.

> btw. There is a "big" discussion about Union FS.
> I use different USB-sticks for my purposes:
> I plug stick #1 in, if i need DL for monitoring and
> #2 if i need a firewall.
> 
> What if i could use config #1 as default and #2 on demand?
> Everything is stored on the same device?
> That would be useful for me, what's your opinion??

I think it's doable.

Let me finish up with unionfs, and I'll think about it some more.

 - BS

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

Serge Leschinsky schrieb:

> Usually I use tcpdump for network traffic reviewing and dumping... Why not add
> it to DL disabled by default? 

Yes, that would be a good decision. Well, tcpdump does basically the same stuff,
but tshark has some nice decoding/protocol features, which could be handy if someone
use DL mainly for network monitoring.

btw. There is a "big" discussion about Union FS.
I use different USB-sticks for my purposes:
I plug stick #1 in, if i need DL for monitoring and
#2 if i need a firewall.

What if i could use config #1 as default and #2 on demand?
Everything is stored on the same device?
That would be useful for me, what's your opinion??



How much space will it take?

It takes about 10MB 'cause of all the different protocols ;-)


- ----
Oliver

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

iD8DBQFICKLH724ZL5LNhNcRAvsWAJ93VLt58uFzdl9/Jgq1c+Zwx97IWgCfVDAK
FaXXdzf+k4tYsDsM5wdTBpM=
=Q8Hh
-----END PGP SIGNATURE-----

Hi Oliver,

Oliver Niesner wrote:

> 
> What do you think about tshark support in DL?
Usually I use tcpdump for network traffic reviewing and dumping... Why not add
it to DL disabled by default? How much space will it take?

--
Serge

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

>> > 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?
>
> Yup.  (see my other reply)
>
> Besides, if the build scripts used it, the permissions would be correct
> to start with, and we wouldn't have this problem!  :-)

I guess you got a point there. ;-)

-- 

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



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

> > 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?

Yup.  (see my other reply)

Besides, if the build scripts used it, the permissions would be correct
to start with, and we wouldn't have this problem!  :-)

 - BS