Hi
I had very similar problems with squid_2.4.6-2woody9_i386.deb yesterday
and resolved them, like you, by reinstalling the previous package
(squid_2.4.6-2woody8_i386.deb).
[EMAIL PROTECTED] wrote:
> Looking in the logfiles shows, that squid 2.4.6-2woody9 restarts very
> often:
>
> upuaut:~# gre
David Barroso wrote:
* James Miller ([EMAIL PROTECTED]) wrote:
If memory serves.. AXFR is a zone transfer... So, at your firewall, would
want to only allowing TCP queries from your backup (secondary,
trinary..etc.) dns servers (on the outside of your firewall) and limit
everyone else to UDP quer
David Barroso wrote:
* James Miller ([EMAIL PROTECTED]) wrote:
If memory serves.. AXFR is a zone transfer... So, at your firewall, would
want to only allowing TCP queries from your backup (secondary,
trinary..etc.) dns servers (on the outside of your firewall) and limit
everyone else to UDP queries
Dariush Pietrzak wrote:
'su -s /bin/bash -c "cmd" user '
sounds like a very bs argument
Do you understand the term 'breakage' ?
How about the idea that changing something in the system may force to you
to rewrite parts of code?
Hence my original question. OK, it doesn't break cron, it doe
I.R.van Dongen wrote:
If the shells are changed, there are some really big consequences, but
Such as? Please share your knowledge. :-)
Cheers,
Tobias
Dariush Pietrzak wrote:
accounts? Do we risk breaking anything if we perform an
s/\/bin\/sh$/\/bin\/false/ ?
Yes, you'll run into trouble trying to run cronjobs as those system users,
No, cron jobs work just fine. I've got a user named 'mirror' with
/bin/true as shell and it performs FTP m
Dariush Pietrzak wrote:
'su -s /bin/bash -c "cmd" user '
sounds like a very bs argument
Do you understand the term 'breakage' ?
How about the idea that changing something in the system may force to you
to rewrite parts of code?
Hence my original question. OK, it doesn't break cron, it does brea
I.R.van Dongen wrote:
If the shells are changed, there are some really big consequences, but
Such as? Please share your knowledge. :-)
Cheers,
Tobias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hi
We recently noticed that a stock woody install produces an /etc/passwd
in which most, if not all, system users have a valid shell entry of
/bin/sh. They're all unable to login due to having no valid password,
but best UNIX security practice typically involves giving accounts that
don't nee
Dariush Pietrzak wrote:
accounts? Do we risk breaking anything if we perform an
s/\/bin\/sh$/\/bin\/false/ ?
Yes, you'll run into trouble trying to run cronjobs as those system users,
No, cron jobs work just fine. I've got a user named 'mirror' with
/bin/true as shell and it performs FTP mirror
Hi
We recently noticed that a stock woody install produces an /etc/passwd
in which most, if not all, system users have a valid shell entry of
/bin/sh. They're all unable to login due to having no valid password,
but best UNIX security practice typically involves giving accounts that
don't need
Dariush Pietrzak wrote:
On Mon, Sep 22, 2003 at 10:18:20PM +0200, Bernd Eckenfels wrote:
FTP is a firewal nightmare,
You think?
Not only he thinks that way. It's an accepted fact within the InfoSec
community.
Firewalls are nightmare, and the only result of prefering
http-only protocols
Dariush Pietrzak wrote:
On Mon, Sep 22, 2003 at 10:18:20PM +0200, Bernd Eckenfels wrote:
FTP is a firewal nightmare,
You think?
Not only he thinks that way. It's an accepted fact within the InfoSec
community.
Firewalls are nightmare, and the only result of prefering
http-only protocols is what
13 matches
Mail list logo
