On Mon, Apr 22, 2013 at 07:51:42PM +0100, Jonathan Dowland wrote:
> On Sun, Apr 21, 2013 at 12:31:25AM +0100, Kevin Chadwick wrote:
> > Jonathan Dowland wrote:
> > > If you were a faithful follower of Kernighan UNIX philosophy, you
> > > wouldn't touch those nasty BSDs with a bargepole.
> >
> > R
On Sun, Apr 21, 2013 at 12:31:25AM +0100, Kevin Chadwick wrote:
> > On Wed, Apr 17, 2013 at 09:51:02PM +0100, Kevin Chadwick wrote:
> > > And that's a Linux problem where some BSDs put lots of effort into
> > > compliance only to have the standard changed to suit linux due to
> > > pressure.
> >
>
> On Wed, Apr 17, 2013 at 09:51:02PM +0100, Kevin Chadwick wrote:
> > And that's a Linux problem where some BSDs put lots of effort into
> > compliance only to have the standard changed to suit linux due to
> > pressure.
>
> Which standard, POSIX?
http://www.itwire.com/business-it-news/open-sourc
Hello Roger,
Excerpt from myself:
-- --
> insserv clearly complains instead that other services are affected by this
> change. Generally to a admin insserv seems to be nicer API over update-rc.d to
> me. Apart from that, by this i found a major bug in rc-update(). Will fix
> that.
i have que
On Wed, Apr 17, 2013 at 09:51:02PM +0100, Kevin Chadwick wrote:
> And that's a Linux problem where some BSDs put lots of effort into
> compliance only to have the standard changed to suit linux due to
> pressure.
Which standard, POSIX?
> POSIX is a very good thing. Do you disagree? I could perhap
On Wed, Apr 17, 2013 at 09:52:04PM +0100, Kevin Chadwick wrote:
> And did it boot slower than with init scripts and waste valuable
> memory. Lookup systemd on the buildroot list and you will see. Debian
> may run on even a cheap toaster one day but systemd would causes issues
> when that is possibl
Hello
Excerpt from Roger Leigh:
-- --
> update-rc.d foo disable|enable
>
> is one method.
-- --
i did played further around with this. First have a look at this:
# find /etc/rc[S0-6].d/ -iname '*mountkernfs.sh*'
/etc/rcS.d/S01mountkernfs.sh
# update-rc.d mountkernfs.sh disable
update-rc.
Hello Roger
Excerpt from Roger Leigh:
-- --
>> Yes, the man page says it swaps the S for a K.
>> e.g. say we have the following link:
>> /etc/rc2.d/K10cups
>>
>> Then afaik - and please correct if i am wrong - init will call the stop part
>> of
>> this initscript when ever runlevel 2 is entere
On Wed, Apr 17, 2013 at 08:55:42PM +0200, Thilo Six wrote:
> Hello Roger
>
>
> Excerpt from Roger Leigh:
>
> >>> update-rc.d foo disable|enable
>
> -- --
> >> It might be a nuisance but running the stop part of the initscript isn't
> >> the
> >> same as not touching it all?
> >
> > Sorry, I
> On 04/16/2013 03:02 PM, Kevin Chadwick wrote:
> >>> Lets not pollute this useful thread with systemd
> >> It seems a thread about init systems and administration/tweaking of them
> >> is the
> >> most appropriate place for systemd to be mentioned. Not least that it can
> >> solve
> >> the pro
> > I believe very strongly that it is. universality with Linux supporting
> > smaller and smaller Arm chips is part of what I was touching on in the
> > paragraph you had a hard time deciphering. This is something BSD is
> > having a hard time competing with atleast in my experience of wanting
> >
> Although, I accept there is no real excuse for my rudeness.
No worries, I have a thick actually english skin as I hope those I talk
to do too. If you think that's rude, you are probably a gent.
--
___
'Write programs that do
Joel Roth wrote:
> I suppose the answer is that there is no shortcut to
> administering a system than learning the details.
Nope. No such thing as a free lunch.
And in the free(dom) software community we have the additional free
market burden of many different sources. There are many different
Hello Roger
Excerpt from Roger Leigh:
>>> update-rc.d foo disable|enable
-- --
>> It might be a nuisance but running the stop part of the initscript isn't the
>> same as not touching it all?
>
> Sorry, I don't quite understand the question here. update-rc.d
> never starts or stops anything--
Bob Proulx wrote:
> Joel Roth wrote:
> > Roger Leigh wrote:
> > > Getting rid of all the /etc/default disable options will be a release
> > > goal for jessie.
> >
> > Good. I'd prefer to be rid of /etc/default entirely!
>
> So you would rather that people edit the /ec/init.d/* scripts
> themselve
Joel Roth wrote:
> Roger Leigh wrote:
> > Getting rid of all the /etc/default disable options will be a release
> > goal for jessie.
>
> Good. I'd prefer to be rid of /etc/default entirely!
So you would rather that people edit the /ec/init.d/* scripts
themselves and manage them as conffiles at up
On 04/16/2013 03:02 PM, Kevin Chadwick wrote:
Lets not pollute this useful thread with systemd
It seems a thread about init systems and administration/tweaking of them is the
most appropriate place for systemd to be mentioned. Not least that it can solve
the problem the OP had. It should not be
On 04/16/2013 11:55 AM, Thilo Six wrote:
Hello Michael,
Excerpt from Michael Biebl:
-- --
+ dropping human readable textfiles in favour of c binary code, which
makes it
needless more complex to debug the whole show.
That's non-sense. systemd unit files are text-files in ini-like format
and
Roger Leigh wrote:
> Getting rid of all the /etc/default disable options will be a release
> goal for jessie.
Good. I'd prefer to be rid of /etc/default entirely!
For example, I just learned about /etc/default/keyboard.
Why not /etc/keyboard or /etc/keyboard.default? Having a central
location fo
On Tue, Apr 16, 2013 at 08:30:45PM -0400, staticsafe wrote:
> On 4/16/2013 19:33, Chris Bannister wrote:
> > On Tue, Apr 16, 2013 at 10:21:02PM +0100, Kevin Chadwick wrote:
> >> I believe very strongly that it is. universality with Linux supporting
> >
On Tue, Apr 16, 2013 at 10:21:02PM +0100, Kevin Chadwick wrote:
> I believe very strongly that it is. universality with Linux supporting
> smaller and smaller Arm chips is part of what I was touching on in the
> paragraph you had a hard time deciphering. This is something BSD is
> having a hard tim
On 4/16/2013 19:33, Chris Bannister wrote:
> On Tue, Apr 16, 2013 at 10:21:02PM +0100, Kevin Chadwick wrote:
Yes and do you know it was designed to do just what it does for a good
reason in 32 kb of code. Hello world is 8kb
>>>
>>> Not relevant to choosing an init system.
>>
>> I believ
On Tue, Apr 16, 2013 at 10:21:02PM +0100, Kevin Chadwick wrote:
> > > Yes and do you know it was designed to do just what it does for a good
> > > reason in 32 kb of code. Hello world is 8kb
> >
> > Not relevant to choosing an init system.
>
> I believe very strongly that it is. universality wi
Rick Thomas wrote:
> Bob Proulx wrote:
> >I have been using Debian for many years now. In all of that time I
> >have never wanted to "manage" init scripts. I always wonder. What
> >are people trying to do?
>
> For an example of where one will want to "manage" the init scripts,
> take a look at
On Mon, Apr 15, 2013 at 09:09:15PM +0200, Thilo Six wrote:
> > update-rc.d foo disable|enable
> >
> > is one method.
>
> Thank you for sharing this!
> It might be a nuisance but running the stop part of the initscript isn't the
> same as not touching it all?
Sorry, I don't quite understand the q
On Mon, Apr 15, 2013 at 11:21:00AM -0500, Yaro Kasear wrote:
> [systemd] has a concurrent startup, meaning it brings a system up and down
> *very* quickly by starting independent units at the same time.
> Standard SysV init generally cannot do this, though it's hard to
> account for how initscripts
> > Yes and do you know it was designed to do just what it does for a good
> > reason in 32 kb of code. Hello world is 8kb
>
> Not relevant to choosing an init system.
I believe very strongly that it is. universality with Linux supporting
smaller and smaller Arm chips is part of what I was touc
On Tue, Apr 16, 2013 at 09:06:31PM +0100, Kevin Chadwick wrote:
> Yes and do you know it was designed to do just what it does for a good
> reason in 32 kb of code. Hello world is 8kb
Not relevant to choosing an init system.
> I am saying it is easy for anyone to follow edit and lookup a man page
> On Tue, Apr 16, 2013 at 10:33:47AM +0100, Kevin Chadwick wrote:
> > I think you miss the point which is those unit files depend on C code
>
> So do classic init scripts:
>
> $ file /sbin/init
> /sbin/init: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses
> > Lets not pollute this useful thread with systemd
>
> It seems a thread about init systems and administration/tweaking of them is
> the
> most appropriate place for systemd to be mentioned. Not least that it can
> solve
> the problem the OP had. It should not be ignored or avoided from bein
Hello Michael,
Excerpt from Michael Biebl:
-- --
+ dropping human readable textfiles in favour of c binary code, which
makes it
needless more complex to debug the whole show.
>>> That's non-sense. systemd unit files are text-files in ini-like format
>>> and much more readable th
On 04/16/2013 04:33 AM, Kevin Chadwick wrote:
+ dropping human readable textfiles in favour of c binary code, which makes it
needless more complex to debug the whole show.
That's non-sense. systemd unit files are text-files in ini-like format
and much more readable then shell scripts with all th
On Mon, Apr 15, 2013 at 09:20:03PM +0100, Kevin Chadwick wrote:
> Lets not pollute this useful thread with systemd
It seems a thread about init systems and administration/tweaking of them is the
most appropriate place for systemd to be mentioned. Not least that it can solve
the problem the OP had.
On Tue, Apr 16, 2013 at 10:33:47AM +0100, Kevin Chadwick wrote:
> I think you miss the point which is those unit files depend on C code
So do classic init scripts:
$ file /sbin/init
/sbin/init: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), fo
> > + dropping human readable textfiles in favour of c binary code, which makes
> > it
> > needless more complex to debug the whole show.
>
> That's non-sense. systemd unit files are text-files in ini-like format
> and much more readable then shell scripts with all their boiler plate.
I think
Am 16.04.2013 04:26, schrieb Yaro Kasear:
> On 04/15/2013 07:13 PM, Michael Biebl wrote:
>> Am 15.04.2013 21:35, schrieb Thilo Six:
>>> + dropping human readable textfiles in favour of c binary code, which
>>> makes it
>>> needless more complex to debug the whole show.
>> That's non-sense. systemd
Am 16.04.2013 04:26, schrieb Yaro Kasear:
> UNLESS, does anyone know if journalctl works fine inside a
> LiveCD/DVD/USB/Ferret/Whatever on another systemd setup? Or, maybe as a
> better way to put it, use a live media's journalctl to use a non-running
> systemd's journal?
Sure, that works: journal
On 04/15/2013 07:13 PM, Michael Biebl wrote:
Am 15.04.2013 21:35, schrieb Thilo Six:
+ dropping human readable textfiles in favour of c binary code, which makes it
needless more complex to debug the whole show.
That's non-sense. systemd unit files are text-files in ini-like format
and much more
On Tue, 16 Apr 2013 02:12:20 +0200
Michael Biebl wrote:
> Am 15.04.2013 20:12, schrieb Celejar:
> > What's wrong with sysv-rc-conf (although it won't work for some of the
> > fancier stuff you have in mind, such as running daemons "on demand")?
>
> It's orphaned and hasn't seen any updates for o
Am 15.04.2013 21:35, schrieb Thilo Six:
> + dropping human readable textfiles in favour of c binary code, which makes it
> needless more complex to debug the whole show.
That's non-sense. systemd unit files are text-files in ini-like format
and much more readable then shell scripts with all their
Am 15.04.2013 20:12, schrieb Celejar:
> What's wrong with sysv-rc-conf (although it won't work for some of the
> fancier stuff you have in mind, such as running daemons "on demand")?
It's orphaned and hasn't seen any updates for over 6 years.
--
Why is it that all of the instruments seeking inte
On Mon, 15 Apr 2013 08:39:27 -0400
Stefan Monnier wrote:
> > I have been using Debian for many years now. In all of that time I
> > have never wanted to "manage" init scripts. I always wonder. What
> > are people trying to do?
> > What is more complicated than this. If you want it then insta
Hello Yaro,
Excerpt from Yaro Kasear:
-- --
> Systemd has "assimilated" udev,
-- --
> Related to the above two downsides, systemd is not really a crowning
> example of a developer following the UNIX Philosophy of "one simple task
> and do it well."
-- --
> Administrators might not like
>> file-rc "works", but only just. I would not be surprised if it was
>> removed for the next stable release--it's simply incompatible with
>> dependency-based booting.
That's a shame, I would take direct editing of runlevel.conf over
dependency-based booting myself.
>> When you are using dyn
Hello Siard,
Excerpt from Siard:
> Thilo Six wrote:
>> gentoo has a rather nice API for an administrator to handle
>> initscripts s.th. i always missed in debian.
>
> Isn't sysv-rc-conf what you are looking for?
Thank you for your help. I am aware of the existents of 3rd party managing tools
o
Hello Roger,
Excerpt from Roger Leigh:
-- --
> update-rc.d foo disable|enable
>
> is one method.
Thank you for sharing this!
It might be a nuisance but running the stop part of the initscript isn't the
same as not touching it all?
-- --
> Getting rid of all the /etc/default disable options
Hello Bob,
Excerpt from Bob Proulx:
> Thilo Six wrote:
>> Subject: administration of initscripts
>> ...in debian has been no pleasure for some time now.
>
> Sorry to hear that. Why not?
I was looking for the "offical" way of dealing with initscript for some time
now. If you look online mostly
Thilo Six wrote:
> gentoo has a rather nice API for an administrator to handle
> initscripts s.th. i always missed in debian.
Isn't sysv-rc-conf what you are looking for?
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas.
Am 15.04.2013 17:26, schrieb Erwan David:
> And disabling them in /etc/default prevent launching them after boot
> (see my need on the other tread).
"update-rc.d disable" is the proper way to disable a service from
starting at boot time.
--
Why is it that all of the instruments seeking intell
On Mon, Apr 15, 2013 at 03:55:33PM +0100, Roger Leigh wrote:
> Getting rid of all the /etc/default disable options will be a release
> goal for jessie.
Very glad to hear that. Services that come shipped with an /etc/default file
that disables the daemon 'by default' really irk me. Not least puppet
On 04/15/2013 05:02 AM, Kevin Chadwick wrote:
I have been using Debian for many years now. In all of that time I
have never wanted to "manage" init scripts. I always wonder. What
are people trying to do?
Hi Bob,
For an example of where one will want to "manage" the init scripts,
take a look
On Mon, Apr 15, 2013 at 05:28:02PM +0200, Erwan David wrote:
> Le 15/04/2013 16:55, Roger Leigh a écrit :
> >On Mon, Apr 15, 2013 at 08:39:27AM -0400, Stefan Monnier wrote:
> >>>I have been using Debian for many years now. In all of that time I
> >>>have never wanted to "manage" init scripts. I
Le 15/04/2013 16:55, Roger Leigh a écrit :
On Mon, Apr 15, 2013 at 08:39:27AM -0400, Stefan Monnier wrote:
I have been using Debian for many years now. In all of that time I
have never wanted to "manage" init scripts. I always wonder. What
are people trying to do?
What is more complicated th
Le 15/04/2013 14:39, Stefan Monnier a écrit :
I have been using Debian for many years now. In all of that time I
have never wanted to "manage" init scripts. I always wonder. What
are people trying to do?
What is more complicated than this. If you want it then install it.
If you don't want it
On Mon, Apr 15, 2013 at 08:39:27AM -0400, Stefan Monnier wrote:
> > I have been using Debian for many years now. In all of that time I
> > have never wanted to "manage" init scripts. I always wonder. What
> > are people trying to do?
> > What is more complicated than this. If you want it then
> I have been using Debian for many years now. In all of that time I
> have never wanted to "manage" init scripts. I always wonder. What
> are people trying to do?
> What is more complicated than this. If you want it then install it.
> If you don't want it then remove or purge it. With those
On Mon, Apr 15, 2013 at 11:02:19AM +0100, Kevin Chadwick wrote:
> > > I have been using Debian for many years now. In all of that time I
> > > have never wanted to "manage" init scripts. I always wonder. What
> > > are people trying to do?
> >
> > Hi Bob,
> >
> > For an example of where one
> > I have been using Debian for many years now. In all of that time I
> > have never wanted to "manage" init scripts. I always wonder. What
> > are people trying to do?
>
> Hi Bob,
>
> For an example of where one will want to "manage" the init scripts,
> take a look at the thread in debi
On Apr 14, 2013, at 10:10 PM, Bob Proulx wrote:
I have been using Debian for many years now. In all of that time I
have never wanted to "manage" init scripts. I always wonder. What
are people trying to do?
Hi Bob,
For an example of where one will want to "manage" the init scripts,
take
Thilo Six wrote:
> Subject: administration of initscripts
> ...in debian has been no pleasure for some time now.
Sorry to hear that. Why not?
> Well the reason i write this, is i found a solution that works for me which i
> would like to share with you.
Thank you for sharing.
> Following goals
Peter Valdemar Morch wrote:
Hi there,
We have 100s of almost identical machines that need to be kept up-to-date with
apt-get dist-upgrade .
Having to run apt-get dist-upgrade manually on all of them is just not working
(taking too much man-power) due to having to answer the same Y/N debconf(?
On Sat, Apr 21, 2007 at 10:31:21AM +0200, "Peter Valdemar M?rch (vol)" wrote:
> Douglas Allan Tutty dtutty-at-porchlight.ca |volatile-lists| wrote:
> >I use aptitude (this is not a troll, please), and I use it interactivly.
> >I have only those pacakges that I specifically _want_ installed marked
>
On Sat, Apr 21, 2007 at 10:31:21AM +0200, "Peter Valdemar Mørch (vol)" wrote:
> Douglas Allan Tutty dtutty-at-porchlight.ca |volatile-lists| wrote:
> >I use aptitude (this is not a troll, please), and I use it interactivly.
> >I have only those pacakges that I specifically _want_ installed marked
>
On Sat, 21 Apr 2007 10:31:21 +0200
"Peter Valdemar Mørch (vol)" <[EMAIL PROTECTED]> wrote:
> Douglas Allan Tutty dtutty-at-porchlight.ca |volatile-lists| wrote:
> > I use aptitude (this is not a troll, please), and I use it
> > interactivly. I have only those pacakges that I specifically _want_
>
Here goes this term "package breakage" again. Do you know what it is
and how it arises? Most of the time, dist-upgrade just decides to
install a couple of extra packages. But some other times... I just
never figured out what makes the difference and what the possible
problems and solutions
Douglas Allan Tutty dtutty-at-porchlight.ca |volatile-lists| wrote:
I use aptitude (this is not a troll, please), and I use it interactivly.
I have only those pacakges that I specifically _want_ installed marked
as manual with everything else being automatic.
Aa! What is *THIS*? "manual" co
> """
> export aptopt=
> $ROOTCMD apt-get $aptopt -f -y dist-upgrade """
Sorry for the late reply.. been busy.
You know, you could always use apt-get -simulate dist-upgrade on your
machines. Check the output and leave a token somewhere that then allows the
machines to do the upgrade for real.
On Thu, Apr 19, 2007 at 03:55:06PM +0200, Peter Valdemar M?rch wrote:
> Ok, but what is the alternative? I find that without dist-upgrade, I end
> up with a constantly growing number of packages in the
> "The following packages have been kept back"
> category.
>
My 2 C worth. Preface: I've ne
On Thu, Apr 19, 2007 at 10:37:54AM -, Peter Valdemar Morch wrote:
> We have 100s of almost identical machines that need to be kept
> up-to-date with apt-get dist-upgrade .
>
> Having to run apt-get dist-upgrade manually on all of them is just not
> working (taking too much man-power) due to ha
Alex Samad wrote:
> If you have 100's of machines all in production or atleast all having to be
> kept to the same package setup.
>
> why not setup yor own repo (and extend it to your down release) could
> correspond to your SOE, when it comes time to update, go through the testing
> phase, once y
If you have 100's of machines all in production or atleast all having to be
kept to the same package setup.
why not setup yor own repo (and extend it to your down release) could
correspond to your SOE, when it comes time to update, go through the testing
phase, once your happy with all the new pac
Georgi Alexandrov wrote:
Too much is going on in testing, unstable and experimental but not in
the stable branch.
Mmm I'd say that having less package changes would be more reason to
monitor the process instead of just throwing it out there. :P From the
look of it there applications that wi
Daniel Palmer wrote:
> Peter Valdemar Mørch wrote:
>> Ok, but what is the alternative? I find that without dist-upgrade, I
>> end up with a constantly growing number of packages in the
>> "The following packages have been kept back"
>> category.
> Jamming dist-upgrade into a cron job will cause pro
Daniel Palmer daniel-at-cardboardbox.org.uk |volatile-lists| wrote:
Jamming dist-upgrade into a cron job will cause problems when a package
doesn't upgrade cleanly.. for example mysql is getting upgraded, the
server will stop and not come back up. Even worse if a kernel upgrade
doesn't create t
FAI works with standard debian kernels or require a special patched one ?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Peter Valdemar Mørch wrote:
Ok, but what is the alternative? I find that without dist-upgrade, I
end up with a constantly growing number of packages in the
"The following packages have been kept back"
category.
Jamming dist-upgrade into a cron job will cause problems when a package
doesn't upgr
Daniel Palmer daniel-at-cardboardbox.org.uk |volatile-lists| wrote:
Georgi Alexandrov wrote:
Or you can:
for i in `seq 10-150`; do ssh [EMAIL PROTECTED] apt-get update && apt-get
-y dist-upgrade &>/var/log/apt-upgrade.log; done
The automatic dist-upgrade is a bad idea in my opinion. Asking
Daniel Palmer wrote:
> Georgi Alexandrov wrote:
>> Or you can:
>> for i in `seq 10-150`; do ssh [EMAIL PROTECTED] apt-get update && apt-get
>> -y dist-upgrade &>/var/log/apt-upgrade.log; done
>>
>>
>
> The automatic dist-upgrade is a bad idea in my opinion. Asking for
> package breakage.
Depen
Georgi Alexandrov wrote:
Or you can:
for i in `seq 10-150`; do ssh [EMAIL PROTECTED] apt-get update && apt-get
-y dist-upgrade &>/var/log/apt-upgrade.log; done
The automatic dist-upgrade is a bad idea in my opinion. Asking for
package breakage.
--
To UNSUBSCRIBE, email to [EMAIL PROTECT
cedric briner wrote:
> Peter Valdemar Morch wrote:
>> Hi there,
>>
>> We have 100s of almost identical machines that need to be kept
>> up-to-date with apt-get dist-upgrade .
> Okay, I'm not an expert but I'll go like this.
>>
>> Having to run apt-get dist-upgrade manually on all of them is just no
Peter Valdemar Morch wrote:
Hi there,
We have 100s of almost identical machines that need to be kept up-to-date with
apt-get dist-upgrade .
Okay, I'm not an expert but I'll go like this.
Having to run apt-get dist-upgrade manually on all of them is just not working
(taking too much man-powe
On Thu, Apr 19, 2007 at 10:37:54AM -, Peter Valdemar Morch wrote:
> Is there a smarter way? How does one manage many, many debian installations
> without having to give each one special manual treatment? Ideally I'd like
> this to be a fully automated operation and only be
> notified of any
From: [EMAIL PROTECTED]
Subject: Autoresponder
Sehr geehrter Absender,
vielen Dank für Ihre Mail an [EMAIL PROTECTED] Wir werden sie schnellstmöglich
an den zuständigen Kollegen weiterleiten.
Sollten Sie jedoch zu einem unserer Produkte technische oder inhaltliche Fragen
haben, wenden Sie sich
On Fri, Oct 19, 2001 at 09:49:20AM +0200, R. Alexander wrote:
...
> I just lazily have a look from now and then at the df output, sometimes
> check the faillog and other mundane tasks ...
>
> Is there a some sort of interface which could concentrate the more important
> indicators/warnings/chores
Hi David, I work at Western university and we added a user shutdown. We
told it when you log in to execute shutdown -h now and that is it. That
might be the easiest way to do it. A little time consuming but other then
that not the headaches that you could get if the system were to go down.
If y
If she has access to the system, just tell her to do a ctrl-all-del, and
then when the machine reboots turn it off during the memory check.
Shaya
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
>> Why not just tell her to use Control-Alt-Delete to shut down the system?
>> Debian will perform an orderly shutdown and reboot the machine, at which
>> time it can be safely powered off.
>>
>> No magic necessary.
>>
>> Regards,
>>
>> Jeff
>>
>> --
>> Make it idiot-proof, and someone will br
[EMAIL PROTECTED] wrote:
>
> I am running a Debian system right now as a web development staging server.
> At
> present, it is only on a local network, but could conceivably become a gateway
> to the Internet as well. So for the time being, it is basically a two-user
> system (me and my wife).
>
> What would be the best way to enable her to run the shutdown command, without
> creating a giant security hole which might bite me in the @*% should this
> machine ever become a gateway? My thoughts up to this point:
>
> 1) Creating a group consisting of my wife and myself, and doing a setu
On Fri, 15 Aug 1997 [EMAIL PROTECTED] wrote:
> What would be the best way to enable her to run the shutdown command, without
> creating a giant security hole which might bite me in the @*% should this
> machine ever become a gateway? My thoughts up to this point:
Why don't you use sudo? It allo
Why not just tell her to use Control-Alt-Delete to shut down the system?
Debian will perform an orderly shutdown and reboot the machine, at which
time it can be safely powered off.
No magic necessary.
Regards,
Jeff
--
Make it idiot-proof, and someone will breed a better idiot.
PGP mail welcome
91 matches
Mail list logo
