On Fri, 2011-03-04 at 10:25 +0200, Andrei Popescu wrote:
> On Jo, 03 mar 11, 21:12:48, Steven wrote:
> > I'm running testing, that snippet does exist in /etc/skel but like I
> > said above, I'm not seeing the console being cleared.
>
> Files in /etc/skel are copied to the $HOME of a new user, not
On Jo, 03 mar 11, 21:12:48, Steven wrote:
> I'm running testing, that snippet does exist in /etc/skel but like I
> said above, I'm not seeing the console being cleared.
Files in /etc/skel are copied to the $HOME of a new user, not sourced.
If you removed the copies from your $HOME it won't work.
On Wed, 2011-03-02 at 19:33 +, Steven Ayre wrote:
> Normal users will clear screen on logout, root will not.
>
That was the case in Etch, I'm not sure about Lenny, but both squeeze
and testing/wheezy don't behave like that on my machine.
>
>
> On 23 February 2011 22:26, Sven Joachim wrote
Normal users will clear screen on logout, root will not.
-Steve
On 23 February 2011 22:26, Sven Joachim wrote:
> On 2011-02-23 23:14 +0100, Ron Johnson wrote:
>
>> On 02/23/2011 03:11 PM, Carlos Mennens wrote:
>>> 1. Screen from console is not cleared as root or regular user once you log
>>>
I was more thinking about whether a script existed that wraps it so
it'd only send the mail if there was >0 programs to restart. At the
moment you'd get an email every time it ran. Easy to write one though.
-Steve
On 28 February 2011 16:20, Ron Johnson wrote:
> On 02/28/2011 02:41 AM, Steven Ayr
On 02/28/2011 02:41 AM, Steven Ayre wrote:
/usr/sbin/checkrestart in package debian-goodies tells you what processes
are using obsolete libraries and can usually tell you which services to
restart.
Nice! I hadn't heard of that before.
Is there anything already existing that can run as a cronjo
Hi, shawn:
En fecha Sábado, 26 de Febrero de 2011, shawn wilson escribió:
> On Fri, Feb 25, 2011 at 7:30 PM, John Hasler wrote:
> > Andrei Popescu wrote:
> > > But there is no 100% way to tell the machine is clean, so you will
> > > have to wipe and reinstall anyway.
> >
> > But if the machine i
> /usr/sbin/checkrestart in package debian-goodies tells you what processes
> are using obsolete libraries and can usually tell you which services to
> restart.
Nice! I hadn't heard of that before.
Is there anything already existing that can run as a cronjob and
periodically let the admin know if
In , shawn
wilson wrote:
>On Sun, Feb 27, 2011 at 1:32 PM,
>Boyd Stephen Smith Jr. wrote:
>> In <4d685bbb.2010...@gmail.com>, Aaron Toponce wrote:
>> >More garbage. There are _many_ good reasons to reboot a UNIX or
>> >GNU/Linux server:
>> >
>> >* Forcing applications to use the new libraries.
>
On 02/27/2011 04:56 PM, shawn wilson wrote:
On Sun, Feb 27, 2011 at 1:32 PM, Boyd Stephen Smith Jr.<
b...@iguanasuicide.net> wrote:
In<4d685bbb.2010...@gmail.com>, Aaron Toponce wrote:
More garbage. There are _many_ good reasons to reboot a UNIX or
GNU/Linux server:
* Forcing applications t
On Sun, Feb 27, 2011 at 1:32 PM, Boyd Stephen Smith Jr. <
b...@iguanasuicide.net> wrote:
>
> In <4d685bbb.2010...@gmail.com>, Aaron Toponce wrote:
> >More garbage. There are _many_ good reasons to reboot a UNIX or
> >GNU/Linux server:
> >
> >* Forcing applications to use the new libraries.
>
> Poo
In <4d685bbb.2010...@gmail.com>, Aaron Toponce wrote:
>More garbage. There are _many_ good reasons to reboot a UNIX or
>GNU/Linux server:
>
>* Proper maintenance ensuring all services start on boot.
Good reason.
>* Cleaning out stale memory and swap as a "refresh".
Poor reason; almost all of thi
On Fri, Feb 25, 2011 at 8:56 PM, Aaron Toponce wrote:
>
> On 02/25/2011 06:35 PM, shawn wilson wrote:
> > however, if you are a restaurant with a small web site, you are probably
> > not getting that many visitors in the first place (defacement isn't
> > going to cost you much), you probably aren'
On 02/25/2011 06:35 PM, shawn wilson wrote:
> i don't think your examples are very good / secure. however, if you want
> security, you might go with openbsd.
http://allthatiswrong.wordpress.com/2010/01/20/the-insecurity-of-openbsd/
Security isn't a binary function, and it's not something that is
On 02/25/2011 06:16 PM, shawn wilson wrote:
> 'nothing but time' - you know that businesses spend tons of money to get
> more 9s of uptime.
> if a website grosses $500 an hour (for ads or for what they sell) and
> you wipe the box and reinstall, you might have lost $2k (if you're real
> good at set
On Fri, Feb 25, 2011 at 8:06 PM, Ron Johnson wrote:
> On 02/25/2011 06:30 PM, John Hasler wrote:
>
>> Andrei Popescu wrote:
>>
>>> But there is no 100% way to tell the machine is clean, so you will
>>> have to wipe and reinstall anyway.
>>>
>>
>> But if the machine is in fact clean you will have
On Fri, Feb 25, 2011 at 7:30 PM, John Hasler wrote:
> Andrei Popescu wrote:
> > But there is no 100% way to tell the machine is clean, so you will
> > have to wipe and reinstall anyway.
>
> But if the machine is in fact clean you will have lost nothing but time.
> Which is better: to know for sur
On 02/25/2011 06:30 PM, John Hasler wrote:
Andrei Popescu wrote:
But there is no 100% way to tell the machine is clean, so you will
have to wipe and reinstall anyway.
But if the machine is in fact clean you will have lost nothing but time.
Which is better: to know for sure that the Russian maf
Andrei Popescu wrote:
> But there is no 100% way to tell the machine is clean, so you will
> have to wipe and reinstall anyway.
But if the machine is in fact clean you will have lost nothing but time.
Which is better: to know for sure that the Russian mafia got all your
customer records or suspect
On Fri, Feb 25, 2011 at 3:13 PM, Andrei Popescu wrote:
> On Vi, 25 feb 11, 12:42:51, Sjoerd Hardeman wrote:
> > The fact that a compromised user account = a compromised machine is
> > of course very true. However, when detected it might be that the
> > attacker did not manage yet to get root permi
On Vi, 25 feb 11, 12:42:51, Sjoerd Hardeman wrote:
> The fact that a compromised user account = a compromised machine is
> of course very true. However, when detected it might be that the
> attacker did not manage yet to get root permissions. Thus, it buys
> some time.
But there is no 100% way to
On Feb 25, 2011 8:40 AM, "Aaron Toponce" wrote:
>
> On Fri, Feb 25, 2011 at 12:42:51PM +0100, Sjoerd Hardeman wrote:
> > SQL injecting and web forms will not work for ssh directly, unless
> > you have a very poorly configured apache+mysql-config. Of course
> > there are ways of obtaining someone's
On Fri, Feb 25, 2011 at 12:42:51PM +0100, Sjoerd Hardeman wrote:
> SQL injecting and web forms will not work for ssh directly, unless
> you have a very poorly configured apache+mysql-config. Of course
> there are ways of obtaining someone's password.
Heh. SQL injections can get you all sorts of th
Aaron Toponce schreef:
On Thu, Feb 24, 2011 at 04:51:30PM -0600, Boyd Stephen Smith Jr. wrote:
For example, you might let one user "sudo" without a password, disable root
logins via ssh, have every other user (including root) be disabled in
/etc/shadow, disable password logins via ssh, and have
Dr. Ed Morbius schreef:
on 17:25 Thu 24 Feb, Sjoerd Hardeman (sjo...@lorentz.leidenuniv.nl) wrote:
Dr. Ed Morbius schreef:
on 16:24 Wed 23 Feb, Boyd Stephen Smith Jr. (b...@iguanasuicide.net) wrote:
On Wednesday 23 February 2011 15:11:25 Carlos Mennens wrote:
3. Debian installer defaults to c
On Thu, Feb 24, 2011 at 04:51:30PM -0600, Boyd Stephen Smith Jr. wrote:
> For example, you might let one user "sudo" without a password, disable root
> logins via ssh, have every other user (including root) be disabled in
> /etc/shadow, disable password logins via ssh, and have all other non-root
On Thursday 24 February 2011 16:29:22 Aaron Toponce wrote:
> On Thu, Feb 24, 2011 at 05:21:51PM +0100, Sjoerd Hardeman wrote:
> > No, it is not. When root logins are allowed, you only need to know
> > one password. When root-logins are not allowed, you need to know two
> > passwords *and* a user na
On Thu, Feb 24, 2011 at 05:21:51PM +0100, Sjoerd Hardeman wrote:
> No, it is not. When root logins are allowed, you only need to know
> one password. When root-logins are not allowed, you need to know two
> passwords *and* a user name.
You assume that the only way into an SSH server is through us
on 17:25 Thu 24 Feb, Sjoerd Hardeman (sjo...@lorentz.leidenuniv.nl) wrote:
> Dr. Ed Morbius schreef:
> >on 16:24 Wed 23 Feb, Boyd Stephen Smith Jr. (b...@iguanasuicide.net) wrote:
> >>On Wednesday 23 February 2011 15:11:25 Carlos Mennens wrote:
> >
> >>>3. Debian installer defaults to creating user
On Jo, 24 feb 11, 17:21:51, Sjoerd Hardeman wrote:
> >
> >Security by obscurity my friend. Security by obscurity.
> No, it is not. When root logins are allowed, you only need to know
> one password. When root-logins are not allowed, you need to know two
> passwords *and* a user name.
The username
On Thu, Feb 24, 2011 at 11:25 AM, Sjoerd Hardeman
wrote:
> Dr. Ed Morbius schreef:
>>
>> The most compelling argument I could think of would be that NFS *still*
>> only allows a maximum of (IIRC) 16 groups IDs to be associated with a
>> given user.
>
> Since when does nfs keep track of the groups
Dr. Ed Morbius schreef:
on 16:24 Wed 23 Feb, Boyd Stephen Smith Jr. (b...@iguanasuicide.net) wrote:
On Wednesday 23 February 2011 15:11:25 Carlos Mennens wrote:
3. Debian installer defaults to creating user group names which is just a
mess.
Actually, I prefer user group names. I'm not sure I
Aaron Toponce schreef:
On Thu, Feb 24, 2011 at 10:18:20AM +0100, Klistvud wrote:
4. The sshd daemon allows root logins by default.
Oh brother. The ssh daemon also allows logins via passwords. I assume
you think this is less secure as well, as ssh keys should be the
preferred method. We should
Hi,
On Thu, Feb 24, 2011 at 07:25:39AM -0700, Aaron Toponce wrote:
> On Thu, Feb 24, 2011 at 10:18:20AM +0100, Klistvud wrote:
> > 4. The sshd daemon allows root logins by default.
>
> Oh brother. The ssh daemon also allows logins via passwords. I assume
> you think this is less secure as well, a
On Thu, Feb 24, 2011 at 10:18:20AM +0100, Klistvud wrote:
> 4. The sshd daemon allows root logins by default.
Oh brother. The ssh daemon also allows logins via passwords. I assume
you think this is less secure as well, as ssh keys should be the
preferred method. We should also change the port off
On Feb 24, 2011 7:34 AM, "Eduardo M KALINOWSKI"
wrote:
>
> On Qui, 24 Fev 2011, Klistvud wrote:
>>
>> 4. The sshd daemon allows root logins by default.
>
>
> The reason for that is explained in README.Debian of the sshd package. You
may not agree with it (and can easily change the setting), but it
On Qui, 24 Fev 2011, Klistvud wrote:
4. The sshd daemon allows root logins by default.
The reason for that is explained in README.Debian of the sshd package.
You may not agree with it (and can easily change the setting), but
it's not "ununderstable".
--
"To YOU I'm an atheist; to God, I
Dne, 23. 02. 2011 22:11:25 je Carlos Mennens napisal(a):
1. Screen from console is not cleared as root or regular user once
you log out.
2. Users home directories get created with 755 permissions. Anyone can
access your home directory and files.
3. Debian installer defaults to creating user g
on 16:24 Wed 23 Feb, Boyd Stephen Smith Jr. (b...@iguanasuicide.net) wrote:
> On Wednesday 23 February 2011 15:11:25 Carlos Mennens wrote:
> > 3. Debian installer defaults to creating user group names which is just a
> > mess.
>
> Actually, I prefer user group names. I'm not sure I have a really
On 2011-02-23 23:14 +0100, Ron Johnson wrote:
> On 02/23/2011 03:11 PM, Carlos Mennens wrote:
>> 1. Screen from console is not cleared as root or regular user once you log
>> out.
>>
>
> You're allowed to create /etc/bash.bash_logout which does:
> if [ "$SHLVL" = 1 ]; then
> [ -x /usr/bin/cle
On Wednesday 23 February 2011 15:11:25 Carlos Mennens wrote:
> 1. Screen from console is not cleared as root or regular user once you log
> out.
Do you want /sbin/init to clear/reset the vt before respawning a process,
/sbin/login to do so before it outputs anything, or do you want /etc/skel to
On 02/23/2011 03:11 PM, Carlos Mennens wrote:
1. Screen from console is not cleared as root or regular user once you log out.
You're allowed to create /etc/bash.bash_logout which does:
if [ "$SHLVL" = 1 ]; then
[ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q
fi
2. Users home
On Wed, Feb 23, 2011 at 04:11:25PM -0500, Carlos Mennens wrote:
> 1. Screen from console is not cleared as root or regular user once you log
> out.
If you use bash, add this to ~/.bash_logout:
case "$(tty)" in
/dev/tty[0-9][0-9]*) clear
esac
You could also get getty do the blanking as well i
1. Screen from console is not cleared as root or regular user once you log out.
2. Users home directories get created with 755 permissions. Anyone can
access your home directory and files.
3. Debian installer defaults to creating user group names which is just a mess.
Obviously these are not cri
44 matches
Mail list logo
