berenger.morel@neutralite.org wrote:
> Bob Proulx wrote:
> >I have seen various wifi drivers not be happy across a
> >suspend/hibernate resume. I have needed to unload them on the way
> >down and reload them on the way up. Or unload and reload them after
> >the resume.
>
> Generally speaking, my computer have some troubles to automatically
> change used networks, so I often use the couple ifup/ifdown.
Sure.
> Except that I must be root to do that, it does not hurt me, so I did
> not investigate further.
Give sudo a try. There are various configuration strategies but for
the simplest for you for your netboot in your physical possession I
suggest creating a local file with all permissions enabled.
# apt-get install sudo
# echo 'berenger ALL=(ALL) NOPASSWD: ALL' > /etc/sudoers.d/zz-local
# chmod 0440 /etc/sudoers.d/zz-local
The file must be mode "-r--r-----". Replace berenger with your login
account name. In the default sudo package all files in that directory
are included and merged into the configuration. Using "zz" forces
this file to the end because later rules have higher priority than
earlier rules and we need that rule to be after other rules. The
"NOPASSWD:" configures to not ask for a password for any command.
Obligatory Warning! NOPASSWD is useful when you have physical
security of your own mobile device. It is the physical security that
protects you. If someone steals your device then they can be root on
the machine regardless so adding it does not decrease security.
If you install sudo fresh now then you will of course be correctly set
up. But I say these next things because many people have had sudo set
up previously and have made modifications to the configuration file
and will run into problems due to this. Here are some hints to check
sudo so that if someone has hit a problem they can fix it.
After setting that up return to your normal user and check that it is
set up for you:
$ sudo -l
User berenger may run the following commands on this host:
(ALL) NOPASSWD: ALL
If you don't see this then your /etc/sudoers has been modified from
the default and is missing the "#includedir /etc/sudoers.d" line.
Also make sure that sudo -l lists secure_path with:
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
If it does not then it means your /etc/sudoers has been modified from
the default and is missing the secure_path configuration. This
problem often shows itself by sudo not being able to find commands
because the PATH isn't set up for it and can't find commands in /sbin
or /usr/sbin.
And then with sudo set up you can use it simply to run ifup/ifdown:
$ sudo ifup wlan0
And of course that can be scripted as needed too so that multiple
actions can all be done by the same command. I create scripts for
these purposes. For example:
#!/bin/sh
sudo service ntp stop
sudo service postfix stop
sudo service bind9 stop
sudo service openvpn stop
sudo ifdown wlan0
> Of course, I still do not really understand the "root access needed
> on your physical computer" but using light workarounds is ok for
> me... for now.
I didn't understand these words. But I feel there is an important
question waiting to get out of them.
> >>Hardware/kernel/driver things are still mysterious for me.
> >>I also have some troubles because of mechanical/electrical problems
> >>inside of my computer, which also makes safer for my data to
> >>shutdown.
> >
> >Have you tried suspend to ram? I pretty much only ever suspend to
> >ram. Because my Thinkpad will stay suspended to ram for about seven
> >days without charging and I never leave it unused for that long.
> >So I never use hibernate to disk these days.
>
> My hardware is in a very poor state, an example being the HD
> connection unstable after moves. Power on, at least, will just avoid
> booting "hey, there's no HD there!" and so, just power off, hitting
> a known of me side of the computer and power on makes it working
> anew. I can look into it, but, well, time needed :D
Ouch! Well. Perhaps it is time to start shopping for a more sturdy
machine? Some hardware seems to last forever. Others develop
problems and must be fixed or replaced.
> I think pm-hibernate would be fine too... but suspend is quite risky
> for datas: it happens that I just close the screen, move from train
> to home, reopen it, try to summon some software, and "... not
> found". Ok, just reboot, I know that know :)
You need a new device. But I understand continuing to use it anyway.
My current laptop sometimes loses power. I have seen it do this when
sitting on the table untouched and unmoving. I need to shop and
replace it. But it does this infrequently, once a month or so, and so
hasn't been an urgent enough problem to do yet.
> All this discussion makes me thinking about another feature I like,
> which is to start the computer (for my desktop one) at a time in
> day. It's nice to wake-up to have mpd starting automatically with
> the computer... For hibernation, it is obviously possible, since the
> computer is really shut down, but for suspends?
I have not done anything like that for myself but it would seem
reasonable to do it using a combination of the /etc/acpi scripts to
recognize that the system is waking up from suspend and a user task
process to start up tasks as the user instead of root. Seems
reasonable. Have not tried it myself.
> >The other thing is that I have a fully encrypted disk. [...] That
> >is much longer.
>
> I guess so.
> I've no real use for encrypted datas on my computer, there are no
> very important datas, so security is quite low.
I do keep important data on my laptop so I do need to protect it with
data encryption. But most importantly then I don't need to worry
about *if* I have something there. If my laptop is stolen and it were
not encrypted then I would need to be very concerned about what
happened to be stored there. It is difficult to be completely
disiplined about everything you do on the computer 100% of the time.
Even simple things like browser history is problematic. I think it is
easier to implement the security of encryption at the system level and
then I know it adds that layer even if I make a mistake at another.
> Simply some source codes, which are available on a web repo of mine
> in LGPL... stole it if you want :D
Sure. Upload your software to the world and let them back it up for
you. :-)
> >I do usually run X11 with either fvwm or awesome for my window
> >manager. But that is as far as it goes.)
>
> Of course, as I do not use TTY very often too... well, it happens,
> when I simply need to read a single file or two, and X11 is quite
> slow to start (Near 7s at startup. Hopefully wayland will change
> that...). But usually, I login in the TTY1 which starts X11+i3 at
> login. I guess you know the trick.
It isn't a trick. Using xinit, or the startx helper script around it,
is the traditional way to start X. The xdm/gdm/kdm/lightdm tools came
later.
> The problem with my "harder" is that there is only poweron/poweroff
> button on 1015 pem. That computer is really minimalistic... And I
> like that, because thanks to that, I've no need to move my hands
> (except for few F7/8 keys and touchpad, but I rarely use them).
The Asus Eee PC 1015 pem does have the blue Fn+Fx keys such as Fn+F1
for suspend-sleep. But I can't guess at what the Fn+F3 icon or Fn+F9
icon are for. But Fn+F1 shows a sleep icon for suspending it. (shrug)
> I was referring to installing dbus, policykit, and alike.
> Of course, I have dbus installed, because
> gstreamer0.10-plugins-"good" (needed by opera) depends on it, but I
> mostly see it as a parasite.
Those do seem to be often changing and therefore immature systems.
And also quite complex and getting heavier all of the time. A lot of
people have strong opinions against dbus. I haven't decided yet
myself but it annoys me that emacs requires dbus and therefore my
servers have it installed.
> acpid is installed too here, but I *think* it is useful, so I have
> nothing against it's presence. I've nothing against useful stuff,
> but my requirements to say something is useful are not simply that
> another tool depends on it. This criteria is one of them which make
> me say: that tool is not good, it does things I did not asked him to
> do, where other softwares of my system already do them.
For me it becomes actively bad when I must take action to disable it
because it is doing something bad automatically.
> But I have no "sleep" file in /proc/acpi? And, of course, can not
> create one, since /proc is not a real file system, AFAIK...
Then you don't have the kernel functionality enabled. I forget what
it takes to enable it off the top of my head and lack time to research
it. But if you had the kernel functionality enabled then it would
automatically appear in /proc for it.
> >I just hit the sleep button
> ...
> >There is also a hibernate to disk button
> I do not have them on my netbook :)
According to images available on the web it is Fn+F1. :-)
But from what you have said the interface behind them might not be
enabled on your computer.
> I'm not. I'm already using it and it does not solve all my problems.
> Also, I've always dirty stuff coming on my TTYs. Not very important
> since I rarely use them, but annoying anyway, because sometimes I
> uses them. And I do not think that spawning stupid messages ("acpid:
> client ... had disconnected" is an example, and happens each time I
> move from X11 to TTYs...) is really useful for anyone.
The syslog daemon by default will log messages to the Linux console.
The Linux console is configurable to log only messages of important
messages but *by default* Debian does not configure it. Red Hat by
comparison always does configure it by default. But you can configure
it in Debian too. Here are some notes from my firewall start script:
# The dmesg -nNUMBER sets the level at which the kernel will log
# messages to the console. The level is less than the number.
# To avoid logging KERN_INFO 6 or lower must be used.
#
# #define KERN_EMERG "<0>" /* system is unusable */
# #define KERN_ALERT "<1>" /* action must be taken immediately */
# #define KERN_CRIT "<2>" /* critical conditions */
# #define KERN_ERR "<3>" /* error conditions */
# #define KERN_WARNING "<4>" /* warning conditions */
# #define KERN_NOTICE "<5>" /* normal but significant condition */
# #define KERN_INFO "<6>" /* informational */
# #define KERN_DEBUG "<7>" /* debug-level messages */
#
# The kernel default is 8 so that all messages are logged to the console.
# At least one other distro sets this to 3 in /etc/syscontrol/init
# and so users there never see console messages. A firewall on the
# Internet today is always flooded with probes. People are always pulling
# on the door and trying to lift the windows. The logging to the console
# causes messages to be printed on the console so often that it is
# virtually useless. This is arguably a system policy decision. But
# Debian does not make this policy anywhere else that I can find. So
# Setting this here avoids most of the issues.
dmesg -n5
This could be put into /etc/rc.local for example. Or I am sure
configured through the /etc/sysctl.d/* interface.
> >It is about 30 seconds for me on an Atom machine like your Eee Pc
> >Atom.
>
> I've just made a try to measures (I found that:
> http://www.chronometre-en-ligne.com/ well, it's in french, but there
> is not so many words... but still human error) and I've got 29.368
> to reach the login, and 39.391 to reach fully loaded X11
Almost exactly the same as on my Atom system. Not too bad. Pretty
reasonable for the hardware.
> environment, considering I've validated the kernel selection on
> default choice, write my login and the password (but this one is not
> secure, only one char... I would like to completely remove it, but
> ssh sounds to need one...)
And this is why I think the sudo NOPASSWD configuration for you is the
best suggestion for you. :-)
> I'm not really jealous about your performances, you see :)
It seems identical to my Atom system.
> But, well, I've 20.312 with hibernation and 04.495 with suspend... I
> must admit that it's faster :)
> BIOS is taking something like 10s on that netbook.
The BIOS takes about 10 seconds on every one of my computer systems.
And of course RAM must be initialized before used somewhere and
systems with a lot of ram will need more time to initialize it. But
more ram is still better overwall.
> >I don't think it would be easier for me. Press TAB at the grub boot
> >screen and then edit
> And what about writing a script automatically started at startup,
> which will select the runlevel you want if you hit the key in time,
> or loads a default one?
> And as you said (later in the mail): sudo telinit X ;)
Sure. I already to this but not usually to change runlevel. I often
use laptop mode on my laptop to enable or disable daemons depending
upon whether I am running on AC power or battery. I usually just
extend that interface for these things. You should look into the
laptop-mode-tools package. But doing similar things at boot time
using scripts such as depending upon AC or not is easy too.
> >the much more complex grub2 config.
>
> That's why I do not use grub any longer. Lilo is so simple, that
> adding entries can be made by a newbie in less than 5 minutes.
> In my opinion, most computers have only one OS, which changes very
> rarely. Then there is the kernel updates problems, which is usually
> perfectly managed by the OS itself.
I am mostly using grub2 because I liked grub1. But this would change
if there were a worthy successor.
> Well, of course, you can not edit stuff at boot time...
Which is the best feature of grub1. And grub2 also allows it in a
much less friendly manor.
> but you does not have to protect it with passwords to forbid root
> access without password, too, and that feature is not really used on
> a daily basis. And it's worth for people using hibernation like you
> ;)
If you have physical access to boot the computer then you can always
boot rescue media and become root on the system. (Unless the disk is
encrypted.)
> >But it doesn't hurt to let it run
>
> Of course. But ssh, which was an example, then vsftpd, then alsa
> (sometimes I want calm), then a webserver, then... ends-up by taking
> more than one second. Sometimes, there are also games which starts
> servers at boot-time (!).
Death by 10,000 paper-cuts! :-)
> I will not security as an excuse for me, because my password is very
> lightweight and I do not use encryption, but the more things you
> have running, the more risks you have to have problems, so, for
> normal users, enabling ssh daemon only when needed is not stupid.
If your password is a single letter then sshd running on the public
wan is very scary. Don't do it. In your case, disable sshd. Or
firewall it to disable it.
> >I personally would prefer the scripted approach with suspend-to-ram
> >over the runlevel approach.
>
> This is an idea too. So I wonder if someone still have uses for
> runlevels? Is there is a real difference between runlevels and
> scripts?
There is no effective difference. Runlevels is just the way the
original systems used to decide what to start at boot time. Something
simple was needed because init should be kept simple. Using runlevels
was a simple concept and easy to implement and so it is used. But in
the end there is no difference of result doing it that way or
scripting it another way.
Bob
Attachment:
signature.asc
Description: Digital signature