Re: fsck on boot...revisited
On Thu, Jul 25, 2013 at 09:28:56AM -0500, Tim Nelson wrote:
> I have an interesting use case where a Debian Lenny server runs headless, and
> is at the mercy of poor power conditions (environmental monitoring at a
> remote storage building). We used to have issues with the server not coming
> up after several reboots, but we gave it a bandaid by forcing an fsck on
> every boot (tune2fs...) to correct any issues. This is fine, and has done
> wonders for disk errors.
>
> However...
>
> On occasion, we find that a filesystem error is bad enough that instead of
> auto{matically|magically} fixing the issue and continuing to boot, the system
> hangs, needing a root password entered for a manual fsck to be run.
>
> My question is thus: How do I prevent that requirement to login and run fsck
> manually? Is there some parameter that can be set? Or, am I going about this
> the completely wrong way?
Solve the underlying problem as best you can.
Buy a cheap UPS with a serial or USB interface; run the
appropriate daemon on your server to shut it down automatically
when the power drops. Replace the UPS every year or two.
Now your disks will be much happier.
-dsr-
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130725145011.go31...@randomstring.org
Re: Continuous brute force attempt from own server !!!
On 26/07/13 07:42, J B wrote: Dear list, I'm suffering with a very serious issue and seek guidance. I have a debian server functional at my place which is attached with a leased line connection. Iand I use this box as a gateway. This debian box administer a remote opensuse linux server through this debian box and I use pubkey auth mechanism to log into the remote linux server. At the remote linux server, I can found huge brute force ssh attempt at the different port and surprisingly the attempt is made with the same username which I actually use to llog into the remote box. Some of the messages from log are as below ``` accepted public key from from port 50574 ssh2 ``` The attack is random with a serially increment at port number. If I bloack the ssh connection limit through firewall at the remote box, It actually blocks me to log into in further. Could any one suggest what is happening in my local box ? rootkit ? local box compromising ? What is it ? Please suggest. Thanks That doesn't look like a "brute force attack", that's just a normal *successful* ssh login. Do you have anything on your local box that performs any ssh connection to the remote box, like rsync, scp, sftp etc? Perhaps a cron job. Do these "attacks" happen at fixed times or regular intervals? Do you use ssh to connect between the boxes a lot? If you still can't identify the source of these connections, it could be that your login on your local box has been compromised. Check the auth log on that to see when 'username' has been accessed. -- Dom -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f226d4.2010...@rpdom.net
Re: Continuous brute force attempt from own server !!!
On Fri, Jul 26, 2013 at 08:35:48AM +0100, Dom wrote: >At the remote linux server, I can found huge brute force ssh attempt at the >different >port and surprisingly the attempt is made with the same username which I >actually use >to llog into the remote box. Some of the messages from log are as below > >accepted public key from >from port 50574 ssh2 It's a bit confusing. Are you saying you see lot of connections coming from your local host? if so you can use netstat -tnpa to see tcp network sockets and it should show all the processes connecting to your remote host. mk -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130726075954.GA26729@finrod
Re: Continuous brute force attempt from own server !!!
J B, how have you figured out that the port-scan targets the ssh daemon specifically? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f238bf.5050...@online.de
Re: Continuous brute force attempt from own server !!!
On Fri, 26 Jul 2013 10:52:15 +0200 benjamin kent wrote: > J B, how have you figured out that the port-scan targets > the ssh daemon specifically? > > as from log ``` accepted public key from from port 50574 ssh2 `` -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130726143527.23b9c...@shiva.selfip.org
Re: Continuous brute force attempt from own server !!!
On 07/26/2013 12:05 PM, J B wrote: > accepted public key from from port 50574 ssh2 That looks like a valid log in from "WAN_IP_of_my_local_box" using one of your keys. If it is not you or one of your scripts then start by disabling that key and making a new one for yourself. It's a good idea for keys to be rotated periodically anyway. Regards, /Lars -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f24778.1080...@gmail.com
verify download
while going through the verify procedures as described http://www.debian.org/CD/verify For newer releases, newer and cryptographically stronger checksum algorithms (SHA1, SHA256 and SHA512) are used, and there are equivalent tools available to work with these. paper@Dhost:~/Downloads$ sha1sum debian-7.1.0-amd64-netinst.iso c8fe5de7d4ee9ca5238e660bd6fcfe7dd572c094 debian-7.1.0-amd64-netinst.iso - paper@Dhost:~/Downloads$ sha256sum debian-7.1.0-amd64-netinst.iso 62232b8adc281c04f9985e4a1541481a468b3b2ca1702a0dd7f62fcf56ef101b debian-7.1.0-amd64-netinst.iso --- paper@Dhost:~/Downloads$ sha512sum debian-7.1.0-amd64-netinst.iso b25aea6a759ff8bb415bb66ee9a2dc7b9db272770b238e3ab8bbba54ac1a380b5efeed20114b682ba32f176a028457f3df1b276e0229537af1a97eeb122f357c debian-7.1.0-amd64-netinst.iso - To ensure that the checksums files themselves are correct, use GnuPG to verify them against the accompanying signature files (e.g. MD5SSUMS.sign) The keys used for these signatures are all in the Debian GPG keyring and the best way to check them is to use that keyring to validate via the web of trust. To make life easier for users, here are the fingerprints for the keys that have been used for releases in recent years (with some UIDs removed for clarity): clicking on the link in that paragraph and going to http://keyring.debian.org/ The server may be accessed with gpg by using the --keyserver option in combination with either of the --recv-keys or --send-keys actions. looking at man gpg there are no options and all commands. which command or combo of commands should be used. do i need to set up a key while using an insecure machine. i have been swimming through this jungle of confusion for a few years and am slowly coming to understand its actual structure. while i do work a graveyard shift am in fatigue 24 hours trying to learn the debian way is difficult at times. i have studied C and Bash and many other languages. but the the instructions here and there can be frusterating. thank you, in advance, for the help -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cahjcrbw5embmc1hcv3b7znuztxopmdcppin8tjcm7oquhsh...@mail.gmail.com
Re: verify download
On Fri, Jul 26, 2013 at 03:01:33AM -0700, james gray wrote: > while going through the verify procedures as described > http://www.debian.org/CD/verify > [cut] > > clicking on the link in that paragraph and going to > http://keyring.debian.org/ > > The server may be accessed with gpg by using the --keyserver option in > combination with either of the --recv-keys or --send-keys actions. > > looking at man gpg > > there are no options and all commands. > > which command or combo of commands should be used. $ gpg --verify somefile.sig somefile That, on its own is enough to verify the integrity of somefile. That is, you should get a message saying something like: gpg: Signature made Fri Jun 4 12:38:46 1999 CDT using DSA key ID BB7576AC gpg: Good signature from "Alice (Judge) " The "Good signature" is the bit to look for. If it says "BAD signature", then the file was modified between signing and verifying. You will *probably* also get a message to the effect of: gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Which means that, although the file wasn't modified, you don't trust that Alice was the person who signed it. There exists the possibility that someone modified the file, signed it and you've just verified THAT. The easiest way is simply to check that the fingerprint matches one of those listed at http://www.debian.org/CD/verify. You can be *reasonably* trusting of the Debian Developers. The harder way is to actually meet one of these (or someone who trusts them; look up "Web of Trust") and confirm their key. > > do i need to set up a key while using an insecure machine. No. When verifying or decrypting GPG, you won't need your own key. > > i have been swimming through this jungle of confusion for a few years > and am slowly coming to understand its actual structure. while i do > work a graveyard shift am in fatigue 24 hours trying to learn the > debian way is difficult at times. i have studied C and Bash and many > other languages. but the the instructions here and there can be > frusterating. Be aware that 99% of people don't go to this effort. Most people trust that, if the ISO downloads and installs, it's good. Some people will check against one or two hashsums. Very few people will bother checking ALL hashsums. The chance of a file matching MD5, SHA1, SHA256 AND SHA512 and yet failing to verify its GPG signature is bordering on zero (especially when you consider that GPG may be using one of those hashes itself). signature.asc Description: Digital signature
Re: Unable to log onto cinnamon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/25/2013 07:12 PM, Sharon Kimble wrote: > With a new user I get the background, no panels, and no menus, no > CTRL+F2, still unusable though. > > Thanks Sharon. What were the exact steps you took when you installed Cinnamon? - -- Rares Aioanei -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR8m50AAoJEM3LMAZrw4rHsFUIAKmh/rT+Njq7WKwZ8Os0Aw5z CQrMX+z4uoKR53F5/94TcYZCxiw+8zTYhaG31B5klJNZnKonMVTmw7LaK3DGlSNc CtIrtXS8u2RtIoZpPIttIBGnxpOplbSC9wC+B6v8UjuF1BlwQtvT5nymWpoEasFb ZlTNoWU/3Oh7LeAtxOwyl0L1vrCSqzKUpQfSIILlEGjw4mccmn3sBIOWIJHcLfer byrMS1lAmdV1voJYoHpDGZuTW0JsxBIku/mxBjxV4g6vtidAkPKS2dMUqsf1rEPC rkBjCfhr/SHLFxuruA2wr0TdN3QCVj7bWYsUcy2SPc3ZcU9JHnTcx/DtuXyLYfo= =Jven -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f26e74.5090...@gmail.com
Re: GnomeControlCenter - Funny stuff
On Thursday 25 July 2013 22:05:18 Jean-Marc wrote: > Click on it and wait 5 seconds. > > Thank's for sharing this experience of what you will see with me. Can you not give an idea of what it is, having tantalised us so? I'm not curious enough to install GNOME, but I am curious! Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201307261436.28108.lisi.re...@gmail.com
Re: GnomeControlCenter - Funny stuff
On 26/07/13 14:36, Lisi Reisz wrote: On Thursday 25 July 2013 22:05:18 Jean-Marc wrote: Click on it and wait 5 seconds. Thank's for sharing this experience of what you will see with me. Can you not give an idea of what it is, having tantalised us so? I'm not curious enough to install GNOME, but I am curious! Lisi Oh, nothing drastic, just an un-recoverable error, with X restarting. :-( Not sure I've ever seen that error screen before. When you click on the user name, the label is highlighted, but subsequently and quite magically the font size of that label increases stepwise, until the whole screen is filled and an error screen pops up. Thanks for sharing, J M, will you file a bug report? -- Klaus -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f283af.9050...@gmail.com
Re: PXE, automatic installation and reboot
Hi, I finally opted for some iptables rules: -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A INPUT -m recent --name tftp --update --reap --seconds 5 -j ACCEPT -A INPUT -m conntrack -m set --match-set tftp_hosts src -p udp --dport 69 --ctstate NEW -j REJECT -A INPUT -m conntrack -m recent --name tftp --set -p udp --dport 69 --ctstate NEW -j SET --add-set tftp_hosts src This will allow consecutive TFTP requests with a timeout of 5 seconds. If the host is already in the IP set, it is rejected. -- Jimmy -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1374850587.30420.2.camel@BEWS005
Re: GnomeControlCenter - Funny stuff
On Fri, 26 Jul 2013 15:11:59 +0100 Klaus wrote: > On 26/07/13 14:36, Lisi Reisz wrote: > > On Thursday 25 July 2013 22:05:18 Jean-Marc wrote: > >> Click on it and wait 5 seconds. > >> > >> Thank's for sharing this experience of what you will see with me. > > > > Can you not give an idea of what it is, having tantalised us so? I'm not > > curious enough to install GNOME, but I am curious! Sorry to tantalise you like that, Lisi. I hope you did not suffer too much ;-) > > > > Lisi > > > > > Oh, nothing drastic, just an un-recoverable error, with X restarting. > :-( Not sure I've ever seen that error screen before. Me neither; but you can avoid Gnome3 freezing and a X-restart just by closing the window. > > When you click on the user name, the label is highlighted, but > subsequently and quite magically the font size of that label > increases stepwise, until the whole screen is filled and an error > screen pops up. > > Thanks for sharing, J M, will you file a bug report? Yes, I will. And I will take back you description. Your english being better than mine. > -- > Klaus > Jean-Marc pgpdhKi8r86w2.pgp Description: PGP signature
Re: GnomeControlCenter - Funny stuff - editing the username freezes Gnome3
On Fri, 26 Jul 2013 15:11:59 +0100 Klaus wrote: Hi Klaus, hi everybody, > Oh, nothing drastic, just an un-recoverable error, with X restarting. > :-( Not sure I've ever seen that error screen before. > > When you click on the user name, the label is highlighted, but > subsequently and quite magically the font size of that label > increases stepwise, until the whole screen is filled and an error > screen pops up. > > Thanks for sharing, J-M, will you file a bug report? Bug reported: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717920 > -- > Klaus > Jean-Marc pgpOYPfkxNNvj.pgp Description: PGP signature
Re: GnomeControlCenter - Funny stuff
On Friday 26 July 2013 16:16:43 Jean-Marc wrote: > Sorry to tantalise you like that, Lisi. > I hope you did not suffer too much ;-) No, only a bit. ;-) Curiosity has not yet killed this cat, though it indubitably will eventually. ;-) :-) Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201307261648.25278.lisi.re...@gmail.com
Re: fsck on boot...revisited
> The system in question is running from an SSD, which I assume changes your > assumptions quite a bit. With a traditional HDDs, the loss of power > causes a head crash, etc which does in turn lessen the life of the drive. Actually, I fail to see why a power outage would have any negative effect on an HDD (e.g. why would the "head crash"?). Also, if you use a journalling file system, a power loss should not cause any file system corruption, nor require fsck. Of course, that's the theory, which makes many assumptions some of which may not be verified, but still, I'm curious why you need fsck and see such filesystem corruption. Stefan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jwvmwp9l3q7.fsf-monnier+gmane.linux.debian.u...@gnu.org
Re: Duplicate Icons in Panel
On Thu, 2013-07-25 at 21:07 -0400, Ethan Rosenberg, PhD wrote: In the bottom tray of what? Bottom Panel in Windows (ugh..ugh). In Debian (Hooray..Hooray) a panel. GNOME 3, right? Take a look at the "things" you put to the panel. You doubled one. I can't help since I'm using Xfce. = Ralf - Thanks. Regrettably - Debian 6.0.1 --->GNOME 2.30.2 If it would solve the problem, how do I upgrade to Gnome3? Ethan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f29fb3.8040...@hygeiabiomedical.com
Re: fsck on boot...revisited
On Fri, 2013-07-26 at 11:54 -0400, Stefan Monnier wrote: > > The system in question is running from an SSD, which I assume changes your > > assumptions quite a bit. With a traditional HDDs, the loss of power > > causes a head crash, etc which does in turn lessen the life of the drive. > > Actually, I fail to see why a power outage would have any negative > effect on an HDD (e.g. why would the "head crash"?). In the old days the heads were not driven back, but for around more than 20 years the heads will park by the momentum of the turns, when there should be a blackout. IIRC if the drives didn't turn fast enough, the heads could crash. Today a power outage definitively doesn't cause a crash and AFAIR even my old 42 MB SCSI survived power outages. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1374857611.1024.7.camel@archlinux
Re: fsck on boot...revisited
On 26/07/13 17:53, Ralf Mardorf wrote: On Fri, 2013-07-26 at 11:54 -0400, Stefan Monnier wrote: The system in question is running from an SSD, which I assume changes your assumptions quite a bit. With a traditional HDDs, the loss of power causes a head crash, etc which does in turn lessen the life of the drive. Actually, I fail to see why a power outage would have any negative effect on an HDD (e.g. why would the "head crash"?). In the old days the heads were not driven back, but for around more than 20 years the heads will park by the momentum of the turns, when there should be a blackout. IIRC if the drives didn't turn fast enough, the heads could crash. Today a power outage definitively doesn't cause a crash and AFAIR even my old 42 MB SCSI survived power outages. True. Back in those days the heads on some disks had to be sent a "park" command before powering off and what that did was to move the head to an reserved area of the disk before landing. Modern drives park the heads off the disks completely. I do remember so old 500MB mainframe disk units (14 inch 10 platter or so, 4 per unit) that had a slight fault. The normal procedure was to press the "offline" button, which retracted the heads from the disk, then press the "power" button to turn them off. Due to a glitch in the circuitry this would sometimes result in a surge in the head actuator coil and the heads would move back across the disks just as they stopped spinning, resulting in major damage to the entire unit. Later a small button was fitted which disconnected the coil and we had to hold that down until the disk had stopped spinning. -- Dom -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f2b95f.5050...@rpdom.net
Re: fsck on boot...revisited
On Fri, 2013-07-26 at 19:01 +0100, Dom wrote: > On 26/07/13 17:53, Ralf Mardorf wrote: > > On Fri, 2013-07-26 at 11:54 -0400, Stefan Monnier wrote: > >>> The system in question is running from an SSD, which I assume changes your > >>> assumptions quite a bit. With a traditional HDDs, the loss of power > >>> causes a head crash, etc which does in turn lessen the life of the drive. > >> > >> Actually, I fail to see why a power outage would have any negative > >> effect on an HDD (e.g. why would the "head crash"?). > > > > In the old days the heads were not driven back, but for around more than > > 20 years the heads will park by the momentum of the turns, when there > > should be a blackout. IIRC if the drives didn't turn fast enough, the > > heads could crash. Today a power outage definitively doesn't cause a > > crash and AFAIR even my old 42 MB SCSI survived power outages. > > True. Back in those days the heads on some disks had to be sent a "park" > command before powering off and what that did was to move the head to an > reserved area of the disk before landing. Modern drives park the heads > off the disks completely. > > I do remember so old 500MB mainframe disk units (14 inch 10 platter or > so, 4 per unit) that had a slight fault. The normal procedure was to > press the "offline" button, which retracted the heads from the disk, > then press the "power" button to turn them off. Due to a glitch in the > circuitry this would sometimes result in a surge in the head actuator > coil and the heads would move back across the disks just as they stopped > spinning, resulting in major damage to the entire unit. Later a small > button was fitted which disconnected the coil and we had to hold that > down until the disk had stopped spinning. JFTR in the meantime I read the German Wiki and it claims that heads automatically are parked since 1989, IOW >= 24 years ago there was this issue. http://de.wikipedia.org/wiki/Head-Crash -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1374865587.680.4.camel@archlinux
Re: Unable to log onto cinnamon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > On Fri, 26 Jul 2013 15:41:24 +0300 > Rares Aioanei wrote: > > > > On 07/25/2013 07:12 PM, Sharon Kimble wrote: > > > > > With a new user I get the background, no panels, and no menus, no > > > CTRL+F2, still unusable though. > > > > > > Thanks Sharon. > > What were the exact steps you took when you installed Cinnamon? > > In roots history - 460 install cinnamon 461 tmux detach 462 install notify-osd 463 installplus xnest xserver-xephyr 464 xnest 465 install libmuffin gjs-internals-1.0 libgnome-menu-3.0 gconf-2.0 libstartup-notification-1.0 the install is an alias for 'sudo apt-get install' Thanks Sharon - -- A taste of linux = http://www.sharons.org.uk/index.html efever = http://www.efever.blogspot.com/ efever = http://sharon04.livejournal.com/ Debian testing, Fluxbox 1.3.5, LibreOffice 4.0.4.2 Registered Linux user 334501 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBCAAGBQJR8swEAAoJEJPDUMFfwu1GtsQP/RMV7qzBFHYYPimpYYiqqhyQ zKfIdkU2DaEquaHrv7hTbuDKP5KhyImUlXzi1sagsiSSFAA/W19H9dI6sDIAFkkU yLckvwSCg+6Qxn1IVFyAbqJ/pxU1xT6NdIl35V01x/rXPzHY9bVmOS8vOhvuwfZu suLeEHSBVrRp6DPyHLgAaKX36DuNdYF6HkidaPzHjLc09xDsMYR4X2utbWoVxlFP HZAUmqQmcT5D3U2zbSJdLR4PVCjClCxQM/UN8Ewo7tuE3/lYgP2YDpn3Dwcl7SvY Chn+ghJjiRucWhK1j7jm+i4H3bZxHa4knkNPOgXa9M49srO3AmwaEhhyHm+SST9x bQAeE7cioaRM1eWONnXSYWROkFrwwguIUYtbexS5+s2QJbbt3q0jDcG6Ib6kcwTP M1YDKFQlbpje+vuDTrSwbJgJkqELf5SThOxhBDWgYWjHrvFgB9/jUeHK3a9b42Yu ss+LbH6zD58yG96gDzV5Yzsj6qOqHbq3p9tbgcBsF+A5cspYf1btaQH7H9U7N2w0 rbvx+0/VrB6bgxi9bGG5LbtFnmDrUup9jVFSw43t2MHt5V7iujfcZyzImR8k+2+O Yeick3Q5cLWyryUzgSS9aR5/9FsmY1c6UEOKeZHpKsRo6qcMG3u2I9wjGHo1azIY 7FSjynMaqp6KnB7yoq1D =9DUR -END PGP SIGNATURE-
Re: GnomeControlCenter - Funny stuff
On Fri, Jul 26, 2013 at 03:11:59PM +0100, Klaus wrote: > On 26/07/13 14:36, Lisi Reisz wrote: > >On Thursday 25 July 2013 22:05:18 Jean-Marc wrote: > >>Click on it and wait 5 seconds. > >> > >>Thank's for sharing this experience of what you will see with me. > > > >Can you not give an idea of what it is, having tantalised us so? I'm not > >curious enough to install GNOME, but I am curious! > > > >Lisi > > > > > Oh, nothing drastic, just an un-recoverable error, with X > restarting. :-( Not sure I've ever seen that error screen before. > > When you click on the user name, the label is highlighted, but > subsequently and quite magically the font size of that label > increases stepwise, until the whole screen is filled and an error > screen pops up. > > Thanks for sharing, J M, will you file a bug report? Are you sure it's not an easter egg? :) -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130726193047.GC3387@tal
Re: GnomeControlCenter - Funny stuff
On Sat, 2013-07-27 at 07:30 +1200, Chris Bannister wrote: > Are you sure it's not an easter egg? :) [rocketmouse@archlinux ~]$ apt-get moo bash: apt-get: command not found Phew! Some distros favour stability over comedy. What happens if you run "apt-get moo"? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1374867589.680.9.camel@archlinux
Re: fsck on boot...revisited
Roger Leigh wrote:
> green wrote:
> > Tim Nelson wrote:
> > > On occasion, we find that a filesystem error is bad enough that
> > > instead of auto{matically|magically} fixing the issue and continuing
> > > to boot, the system hangs, needing a root password entered for a
> > > manual fsck to be run.
> > >
> > > My question is thus: How do I prevent that requirement to login and
> > > run fsck manually? Is there some parameter that can be set? Or, am I
> > > going about this the completely wrong way?
> >
> > You mentioned the FSCKFIX option; according to rcS(5) man page,
> > setting it to "yes" in /etc/default/rcS will do what you want. This
> > causes fsck to be run with -y instead of -p which is somewhat
> > dangerous but hopefully will in your case successfully repair the
> > filesystem.
I always set FSCKFIX=yes in /etc/default/rcS and think that is the
best default.
> From a usability point of view, there have been many requests
> over the years to make FSCKFIX=yes the default. However, from
> a safety point of view, this is not fine due to the risk of
> unrecoverable data corruption if it does the wrong thing.
The problem is that a vanishingly small number of people know how to
drive a filesystem debugger and repair a broken filesystem better than
the automated tools. Many more people operate headless computers as
servers. If you, the reader of this message, are one of the elite
souls who can manually fix a corrupted filesystem then that is
awesome. But for the rest of us we don't have the needed knowledge
and skills to do so.
For the larger majority of users the current default setting of
FSCKFIX=no is a problem because it will result in a system that won't
boot without a human on the console to manually answer yes to the fsck
questions. On a desktop you are there and just do it. On a server
you need to get on the console. Typically that requires a support
request in the simple case if the machine is in a data center. But
for many of us it would mean a long drive into another city hosting
the system in order to physically touch the hardware, attach a
console, and answer yes. For more of us the FSCKFIX=yes setting is a
much better default.
> We would prefer the admin to take responsibility for any needed
> actions prior to fsck (imaging the disc, backups, etc.)
I must object to this. I do not personally know anyone in the real
world that I could eat lunch with who has the skills to manually
repair a corrupted filesystem. I am confident that if it were
possible to conduct a fair poll of the readers of debian-user that an
extremely small percentage of readers would have the skill to do so.
(I am sure that some do. You reading this might be one of those few.)
And yet we are all using Debian systems. For the vast majority of us
we must count on the automated fsck to repair the filesystem. For
most of us if the filesystem needs an fsck then we would answer yes to
proceed with the fsck. And if the fsck is unable to do the repair
then we would fall back to restoring from backup. I know that I would
create a new filesystem and would restore from backup in that case. A
backup is always still needed for safety and RAID does not remove the
need for it.
And so I object to the idea that allowing the admin to choose to fsck
or not is giving the admin any real choice. It really isn't much
choice. I don't think it is any real choice at all. It feels simply
like a way to way to offload and deflect blame. It is now always
possible to point fingers at the local admin. "If you lost data then
it is your fault because you pushed the button." And yet for most
that is the only thing they can do. I myself would push the button.
About the only other option would be to take each disk and make a bit
copy of each of the disks in the system. Save those copies off. Then
if something goes wrong they can send those full bit copies to someone
else who has the skills to possibly recover the data. That would
certainly always be a safe recipe whenever a system crashes and needs
an fsck.
So say you have a simple system with two 1T disks in a RAID1 mirror.
You would only need two more 1T disks to make a full bit copy of both
disks. You would only need an additional system in which to mount
those disks onto and to use as a host for making the copy. You only
need a few hours of your time to physically pull the disks and do the
copy. And to be careful and not make an additional mistake making a
simple problem more complicated. With a full copy then you could
always repeat the restoration several times using different techniques
and definitely increase your odds of success. If you ever need to
fsck the system then the safest recipe would be to always do this.
But how many people reading debian-user have these resources of extra
disks and systems? I could certainly do this for myself but even I
consider that too much trouble. I simply run the fsck and expect that
99 times out of a 100 (numbers I ju
Re: GnomeControlCenter - Funny stuff
Ralf Mardorf wrote: > Chris Bannister wrote: > > Are you sure it's not an easter egg? :) > > [rocketmouse@archlinux ~]$ apt-get moo > bash: apt-get: command not found > > Phew! Some distros favour stability over comedy. Are you implying that having the "apt-get" command on the system reduces stability? :-) > What happens if you run "apt-get moo"? https://en.wikipedia.org/wiki/Easter_egg_(media) http://en.wikipedia.org/wiki/Aptitude_(software) Bob signature.asc Description: Digital signature
Re: fsck on boot...revisited
On 26/07/13 20:06, Ralf Mardorf wrote: On Fri, 2013-07-26 at 19:01 +0100, Dom wrote: On 26/07/13 17:53, Ralf Mardorf wrote: On Fri, 2013-07-26 at 11:54 -0400, Stefan Monnier wrote: The system in question is running from an SSD, which I assume changes your assumptions quite a bit. With a traditional HDDs, the loss of power causes a head crash, etc which does in turn lessen the life of the drive. Actually, I fail to see why a power outage would have any negative effect on an HDD (e.g. why would the "head crash"?). In the old days the heads were not driven back, but for around more than 20 years the heads will park by the momentum of the turns, when there should be a blackout. IIRC if the drives didn't turn fast enough, the heads could crash. Today a power outage definitively doesn't cause a crash and AFAIR even my old 42 MB SCSI survived power outages. True. Back in those days the heads on some disks had to be sent a "park" command before powering off and what that did was to move the head to an reserved area of the disk before landing. Modern drives park the heads off the disks completely. I do remember so old 500MB mainframe disk units (14 inch 10 platter or so, 4 per unit) that had a slight fault. The normal procedure was to press the "offline" button, which retracted the heads from the disk, then press the "power" button to turn them off. Due to a glitch in the circuitry this would sometimes result in a surge in the head actuator coil and the heads would move back across the disks just as they stopped spinning, resulting in major damage to the entire unit. Later a small button was fitted which disconnected the coil and we had to hold that down until the disk had stopped spinning. JFTR in the meantime I read the German Wiki and it claims that heads automatically are parked since 1989, IOW>= 24 years ago there was this issue. http://de.wikipedia.org/wiki/Head-Crash Yep, we had a couple of platters similar to those IBM ones on our office wall as "trophies" :) I was lucky in that my own first hard disk (10MB) survived several unexpected sudden power outages without any noticeable problems. It was still working 20 years later - but very slow, it used a stepper motor to move the heads. It seemed fast in those days when I was used to using 5.25" floppies on my home computer. -- Dom -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f2d539.8000...@rpdom.net
Re: Continuous brute force attempt from own server !!!
On Fri 26 Jul 2013 at 12:55:04 +0300, Lars Noodén wrote: > disabling that key and making a new one for yourself. It's a good idea > for keys to be rotated periodically anyway. Does this 'good idea' have reasons to support it? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/26072013212420.2e0af51bd...@desktop.copernicus.demon.co.uk
Jak dzwonić bez limitu już za 19 zł miesięcznie?
Otwórz tą wiadomość aplikacją obsługującą wiadomości HTML
Re: GnomeControlCenter - Funny stuff
On Fri, 2013-07-26 at 13:57 -0600, Bob Proulx wrote: > Ralf Mardorf wrote: > > Chris Bannister wrote: > > > Are you sure it's not an easter egg? :) > > > > [rocketmouse@archlinux ~]$ apt-get moo > > bash: apt-get: command not found > > > > Phew! Some distros favour stability over comedy. > > Are you implying that having the "apt-get" command on the system > reduces stability? :-) The truth about the rabbit who brings the Easter egg: Rabbit attacks snowmen with hairdryer for carrot nose http://d3j5vwomefv46c.cloudfront.net/photos/large/47304649.jpg?1259971141 They even kill snowman, just because their noses are aphrodisiacs in the rabbits minds. The Easter egg is a symbol for the evil. Do you consider "super cow powers" as something good? Every year sharks kill 10 people. Every year 100 people die from being stepped on by cows. http://www.laughaday.org/wp-content/uploads/2013/04/The-cow-killer.jpg So how can you trust a distribution that makes jokes about atrocities? The Easter rabbit and cows are monsters. Maneater http://3.bp.blogspot.com/-Key07E0MRoM/UJL5qlHsgLI/BpE/TJsKP94_OJ4/s400/killer_rabbit.jpg -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1374875177.680.27.camel@archlinux
Re: fsck on boot...revisited
Bob Proulx wrote at 2013-07-26 14:51 -0500: > I always set FSCKFIX=yes in /etc/default/rcS and think that is the > best default. I agree with Bob's comments about this, in general, and have just now gone and set FSCKFIX=yes on a particular server because it would be better for it to boot with a partially corrupted rootfs than hang during boot while waiting for input. I hope it never matters, the system is on a UPS. It does seem good to somehow notify the user/admin when severe corruption has been encountered (eg. on a desktop: "press y to try fixing everything"), but also easier to pick up the pieces using backups (and trusting that the fs is no longer corrupted) than worry about whether is okay for each of 500 times. signature.asc Description: Digital signature
Re: GnomeControlCenter - Funny stuff
Jean-Marc, 25.07.2013: > Hi guys, > > Are you a Gnome3 user ? > Do you want to try something funny ? > Just open the System Settings, click on "User Accounts" and try to change > your name. > You can do it just in clicking on your name to switch to an edit mode. > Click on it and wait 5 seconds. > > Thank's for sharing this experience of what you will see with me. After reading the reports of what happens, I tried this, and nothing happens. This is on wheezy, using Gnome 3 but I am in fallback mode (forced by my graphics card not being up to snuff). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130726225105.ga1...@cs.utexas.edu
SOLVED: export vs. save menu in gimp2.8 - simple and lasting solution
Hello, it has now been months that Gimp developers seem to have decided that their "product vision" in Gimp2.8 (debian/unstable) is more relevant than the workflow of their users. People who use Gimp *a lot* keep clicking "Save as" instead of "Export" because that is what they're used to. Because it is natural. If you think that it is trivial to make that workflow mistake over and over - then you are a casual Gimp user and can stop reading. If you use Google and search for "export save gimp" you can witness what happens when marketing takes over the development. There seems to be this product-vision-apologetics that they can ignore their users because they are not getting paid by them anyway. Old user will just be replaced by new users. Nobody will notice that transition except in the feedback, which isn't monetary but just a few angry posts in the internet. Since Debian (like all other distributions) will have to (or has to) update to Gimp2.8 in the stable branch I dedicated a chroot jail to Gimp2.6 and will explain here how you can do it yourself. Creating a chroot jail for a single application is very easy. # the directory in which the chroot jail will exist mkdir chroot_gimp2.6 # run debootstrap it will install a minimal debian and gimp2.6 # this will take a while debootstrap --variant=minbase --include=gimp squeeze chroot_gimp2.6 ftp://ftp.debian.org/debian # import your filesystem to /mnt (inside chroot jail) mount / chroot_gimp2.6/mnt --bind # run gimp from inside the chroot jail chroot chroot_gimp2.6 gimp Enjoy Gimp2.6 and the workflow you are used to. No further updates/changes of your Distribution will take Gimp2.6 workflow away from you. This will be reposted for your convenience when debian/stable switches to Gimp2.8. Dirk -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f32ab1.2060...@pwnoogle.com
