On Wednesday 01 September 2010 12:52:40 erik quanstrom wrote:
> > Also, a logical fallacy: Since X could sometimes be used to thwart Y,
> > then Y is useless in all cases.
>
> i think the correct statement of the thinking (or
> at least my thinking) is
>
> we want to assert X, but
>
> Also, a logical fallacy: Since X could sometimes be used to thwart Y, then
> Y is useless in all cases.
i think the correct statement of the thinking (or
at least my thinking) is
we want to assert X, but
since Y defeats X, we require !Y to assert X.
in something closer to eng
On Wed, Sep 1, 2010 at 2:51 PM, erik quanstrom wrote:
>> Those are reasonable points, definitely. Since I'm usually the only
>> one to use my servers (except at Sandia, where I share with Ron),
>> abusing my admin privs isn't a big deal.
>
> hey, isn't that the windows security model! :-)
>
> ser
On Wednesday 01 September 2010 2:56:03 bau...@gmail.com wrote:
> > you'd be left with defending against ^T^Tr, ^P, etc.
> > but then again, the power button or network cable is sooo
> > convienent. heck, just take the machine home. :-P.
>
> who care user/pass when you can pull of hard drives :-)
> Those are reasonable points, definitely. Since I'm usually the only
> one to use my servers (except at Sandia, where I share with Ron),
> abusing my admin privs isn't a big deal.
hey, isn't that the windows security model! :-)
seriously, don't you open yourself up to more mistakes,
if you make
On Wed, Sep 1, 2010 at 2:14 PM, erik quanstrom wrote:
>> rio is such a minor thing to run on today's massive machines, I'm not
>> sure I really see the problem in starting it on your cpu server
>> anyway. I frequently set them up to launch into rio because:
>> 1. It's easier to fix things when I c
On Wed, Sep 01, 2010 at 01:44:46PM -0400, John Floren wrote:
> rio is such a minor thing to run on today's massive machines, I'm not
> sure I really see the problem in starting it on your cpu server
> anyway. I frequently set them up to launch into rio because:
- When a keyboard and a mouse are at
> rio is such a minor thing to run on today's massive machines, I'm not
> sure I really see the problem in starting it on your cpu server
> anyway. I frequently set them up to launch into rio because:
> 1. It's easier to fix things when I can cat /dev/kprint in a window
> rather than have it consta
On Wed, Sep 1, 2010 at 2:22 PM, erik quanstrom wrote:
> On Wed Sep 1 12:58:54 EDT 2010, benave...@gmail.com wrote:
>> you right, I thought conslock was rob's lock program
>>
>> http://plan9.bell-labs.com/sources/patch/sorry/robs-bits/
>
> i hate doing this, but that depends on rio, too. the open
On Wed, Sep 1, 2010 at 1:22 PM, erik quanstrom wrote:
> On Wed Sep 1 12:58:54 EDT 2010, benave...@gmail.com wrote:
>> you right, I thought conslock was rob's lock program
>>
>> http://plan9.bell-labs.com/sources/patch/sorry/robs-bits/
>
> i hate doing this, but that depends on rio, too. the open
On Wed Sep 1 12:58:54 EDT 2010, benave...@gmail.com wrote:
> you right, I thought conslock was rob's lock program
>
> http://plan9.bell-labs.com/sources/patch/sorry/robs-bits/
i hate doing this, but that depends on rio, too. the open of
/dev/screen -> error() -> exits("fatal error");
- erik
you right, I thought conslock was rob's lock program
http://plan9.bell-labs.com/sources/patch/sorry/robs-bits/
On Wed, Sep 1, 2010 at 12:11 PM, erik quanstrom wrote:
> On Wed Sep 1 00:23:45 EDT 2010, benave...@gmail.com wrote:
>> now there's also screenlock(8)
>>
>> http://plan9.bell-labs.com/m
On Wed Sep 1 00:23:45 EDT 2010, benave...@gmail.com wrote:
> now there's also screenlock(8)
>
> http://plan9.bell-labs.com/magic/man2html/8/screenlock
>
> similar to conslock, but authenticates against the auth server
not similar. it depends on rio.
- erik
On 31 August 2010 at 13:45, Skip Tavakkolian <9...@9netics.com>wrote:
> see: /n/sources/contrib/steve/rc/conslock
>
> if you have more than one cpu, change this line:
> pwd=$home/lib/conslock.hash
> to
> pwd=$home/lib/conslock.^$sysname^.hash
works well! :-) If some say I'll leave cpu
On 31 August 2010 at 11:04, erik quanstrom wrote:
> i didn't suggest lock for cpu servers since it requires
> rio. seems silly to run rio on the console just to lock it.
> and unfortunately, i think this method would also interfere
> with the serial console. and it wouldn't be immune to
> a three
On 31 August 2010 at 10:55, John Floren wrote:
>
> This seems to come up every so often. The usual answer, and the one
> which I use, is "who cares?" :) Where is your CPU server located? Are
> there that many untrustworthy types passing through every day?
ok, you unmasked me :-) It was only a te
Don't do this under drawterm, at least not on Windows. It'll gobble
your mouse right up, or at least it did mine.
Of course, there's no reason to run this in drawterm, since your host
OS is certain to have its own screen locker...
John
On Wed, Sep 1, 2010 at 12:21 AM, Federico G. Benavento
wrot
now there's also screenlock(8)
http://plan9.bell-labs.com/magic/man2html/8/screenlock
similar to conslock, but authenticates against the auth server
On Tue, Aug 31, 2010 at 5:45 PM, Skip Tavakkolian <9...@9netics.com> wrote:
> see: /n/sources/contrib/steve/rc/conslock
>
> if you have more than o
see: /n/sources/contrib/steve/rc/conslock
if you have more than one cpu, change this line:
pwd=$home/lib/conslock.hash
to
pwd=$home/lib/conslock.^$sysname^.hash
here's something quite old which used to work:
http://mirtchovski.com/lanlp9/rlock/index.html
for cpu servers, I sometimes add cat /dev/kmesg /dev/kprint to cpurc.
as the console does not run rio and you can't hit Del to kill them,
they suffice to lock the keyboard.
there was also the lock program from Rob Pike, IIRC, posted here long
ago, I think.
perhaps not
On Tue, Aug 31, 2010 at 5:25
Steve has a conslock in sources. I have a couple of CPUs in open areas
that I lock using it. Put it as the last action in /cfg/machine/cpurc
to lock on startup.
Sent from my iPhone
On Aug 31, 2010, at 8:04 AM, erik quanstrom
wrote:
There is also, somewhere, a screen locker program that
In short. Physical access trumps all other locking mechanisms anyway.
CPU servers were not meant to be workstations, and the lack of a screen lock
shows that. But then workstations are easily stolen. 2 were taken from the
building where I work in the last weeks at a law firm office (we share ou
> There is also, somewhere, a screen locker program that (I think) Rob
> wrote a few years back; I compiled it and used it successfully last
> year, and you could certainly stick that in your cpustart to
> automatically lock the screen. However, for the life of me I can't
> find the code right now,
On Tue, Aug 31, 2010 at 10:20 AM, wrote:
>
> Hi all,
> how to lock (protect by password) the cpu console? In default install
> afterboot the console is logged by user bootes. Is there a way to avoid this?
>
> tia,
>
> bye
>
> --
> Maurizio Boriani
> irc: #defo...@freenode.net
> PGP key: 0x
On Tue, Aug 31, 2010 at 3:20 PM, wrote:
>
>how to lock (protect by password) the cpu console? In default
> install
> afterboot the console is logged by user bootes. Is there a way to avoid
> this?
>
>
>
Usually, you'll find people put it in a cupboard or room that you can
physically lock.
On Tue Aug 31 10:21:42 EDT 2010, bau...@gmail.com wrote:
>
> Hi all,
> how to lock (protect by password) the cpu console? In default install
> afterboot the console is logged by user bootes. Is there a way to avoid this?
>
the quick answer is that it's not possible out of the box.
previou
27 matches
Mail list logo
