Re: problem with corrupted root password
Comer Duncan wrote: > However, today in the process of trying to spawn a root terminal (in > Accessories) and going through a cycle of trying to get authorized but > being prevented by repeated complaints that the system password I used was > not correct, I now find that I can not get logged in in single-user mode! > I have thus royally screwed up. So, how can I get the system password > changed to something new? Did you get added to the sudo group? If you are lucky then you did and you can use your own password instead of root. $ sudo passwd root $ su - # Worth a try. Remember that sudo asks for your password not root's password. Also you can use sudo to list what sudo actions are available to you. $ sudo -l Bob signature.asc Description: Digital signature
Re: Disable server so it does not start on reboot (even after upgrade)?
Tony Baldwin wrote: > Andrei POPESCU wrote: > > Xavi wrote: > > > First I do: > > > > > > sudo update-rc.d -f apache2 remove > > > > > > and then, to assert the rc.d links are not recreated, > > > I recreate them stopped in all runlevels: > > > > > > sudo update-rc.d apache2 stop 80 0 1 2 3 4 5 6 . Was that associated with some previous thread? > > Or one could just use 'disable'. Or it could be removed. Why have it installed if it isn't going to be running? apt-get remove apache2 Personally I "purge" instead of remove but I know I have etckeeper keeping /etc backed up along with a real off system backup too. So I can purge things without thinking knowing if I didn't want that I could recover the /etc conffiles from backup. > Couldn't you just turn apache2 off in rcconf? If one mentions rcconf then one might as well mention chkconfig too. Basically the same thing but perhaps more familiar to people coming from other software distributions. > Or did I miss something in this thread? This thread has little context. :-( Bob signature.asc Description: Digital signature
Re: Have I been hacked?
Brian wrote: > Bob Proulx wrote: > > Brian wrote: > I am still going to maintain that "TwasBrilligAndTheSlithyToves" is a > more than adquate password for logging in *on-line*. If I were to lack > trust in the maintenence of security at a site I might consider a change > of heart. But then - what would I base my judgement on. apart from the > theoretcal possibility? > > > I won't say that the technique you show above is a bad thing. But the > > current wisdom is that it isn't good enough anymore because after > > analyzing millions of real world passwords, programs can now guess > > what humans will do much of the time. So what you really need is > > something other than what a human would produce. > > We are still on off-line cracking? How does this sound? Oops. You caught me. Everyone else continued to talk about offline cracking and I had pretty much given up and lost track of the topic. But you were specifically said online and emphasized it. My bad. Although I was trying to address specifically the trust in site security. It is only a matter of time before a high profile site is so mired in its own bureaucracy that they lose track of its own security and expose this information. Historically speaking. But the original poster was talking about a personal Debian system. For a personal system one could probably get away with using a pretty weak password. Your password method would be a pretty strong one for a personal system. If the system is compromised to the point that /etc/shadow with the hashes exposed for an offline attack then you should scrape it clean and install from known good pristine sources and start again using all different passwords than before. The weak password wouldn't have been the problem in that case. The attack could only have only have come through some other vector into the machine. Bob P.S. Before leaving remote web sites entirely behind... Most important is to use a unique password per site. Then using a strong password only if I care about having that data cracked. I use my fair share of weak throwaway passwords on weak throwaway sites. But I never reuse them across sites. signature.asc Description: Digital signature
Re: problem with corrupted root password
On 14/01/15 04:26 PM, Rob Owens wrote: On Wed, Jan 14, 2015 at 03:07:09PM -0500, Comer Duncan wrote: I recently got wheezy up and running. I installed xfce4 and like it. However, today in the process of trying to spawn a root terminal (in Accessories) and going through a cycle of trying to get authorized but being prevented by repeated complaints that the system password I used was not correct, I now find that I can not get logged in in single-user mode! I have thus royally screwed up. So, how can I get the system password changed to something new? Thanks for help and apologies for making such an error. Boot using a Live CD, then as root: mount /dev/sda1 /mnt/sda1 (or whatever device is your root partition) chroot /mnt/sda1 passwd I'd change the chroot command to chroot /mnt/sda1 bash to ensure you get the correct shell. System Rescue CD, for example, uses zsh by default so chrooting with specifying the shell will get you a not-found error. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54b6f53e.60...@torfree.net
Re: Have I been hacked?
Brian writes: > I can remember "TwasBrilligAndTheSlithyToves" and associate it with an > account. > Before signing up I do >echo TwasBrilligAndTheSlithyToves | sha1sum | base64 | cut -c -30 > The output is what I give to a site as a password. > Furthermore, before any future logins I can run the command again to get > the same password. Or you can install one of the software packages that do that for you. -- John Hasler jhas...@newsguy.com Elmwood, WI USA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87oaq1dmkh@thumper.dhh.gt.org
Re: Have I been hacked?
On Wed 14 Jan 2015 at 18:52:06 +0900, Joel Rees wrote: > 2015/01/13 5:17 "Brian" : > > > > strikes me as a pretty good one for an ssh login. (I have capitalised > > some letters for readability, not to add complexity). Personally, I find > > it easy to remember and associate with ssh and my account. I cannot see > > why it is not a good password for me. > > Just remember that fail2ban only does temporary tarpitting, and only if the > attacks are repeated to quickly. How about http://whyscream.net/wiki/index.php/Fail2ban_monitoring_Fail2ban#Warning:_pick_the_right_jail > > The automated probes wouldn't get close to cracking it. > > Think of a bot farm continuously hitting a crowd of targets, once a second, > cycling through spoofed IPs, using informed strategies instead of pure > brute force. If they can spoof one IP, they can spoof another. Does this increase the number of connections per second? > > The danger might > > be a directed attack - from friends, associates, colleagues etc. If they > > knew about my fixation on Lewis Carroll they might have a go at breaking > > in. > > If they think you have something they want, people you don't know will find > out about your interests. Blog posts, posts here, etc. 500,000.000 million on the internet at least. It's not my turn yet. > > Actually, it would be ok as a password for banking access too. There > > surely cannot be a banking site which does not take action after a > > number of failed logins. Maybe not using fail2ban, but a similar > > approach which protects both parties. > > Means you end up going to the bank in person, to get the lock removed. The telephone? People would be heavily critical if a bank did not take steps to monitor logins and act on unusual activity. > Banks aren't perfect, though. You could come to considerable trouble > should, for instance, a bank employee decide to do a little investigating > passwords in her spare time, without permission. > > But it's your bank account. Go for it. I have no knowledge or control over what goes on in a bank, Why lose sleep over worrying about it? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150114215653.gc15...@copernicus.demon.co.uk
Re: Have I been hacked?
On Tue 13 Jan 2015 at 22:16:12 -0700, Bob Proulx wrote: > Brian wrote: > > Seeing that my argument that enforcing (if it is possible) an > > unmemorable password is not in the best interests of security doesn't > > gain any tracton, let me try a different tack. > > > > The password > > > > TwasBrilligAndTheSlithyToves > > > > strikes me as a pretty good one for an ssh login. (I have capitalised > > some letters for readability, not to add complexity). Personally, I find > > it easy to remember and associate with ssh and my account. I cannot see > > why it is not a good password for me. > > Why passwords have never been weaker—and crackers have never been stronger > http://arstechnica.com/security/2012/08/passwords-under-assault/ > > Most importantly, a series of leaks over the past few years containing > more than 100 million real-world passwords have provided crackers with > important new insights about how people in different walks of life > choose passwords on different sites or in different settings. The > ever-growing list of leaked passwords allows programmers to write > rules that make cracking algorithms faster and more accurate; password > attacks have become cut-and-paste exercises that even script kiddies > can perform with ease. > > To summarize the problem it is that you as a human are unique in the > universe, just like everyone else. Analyzing 100 million passwords > exposes the human bias that you introduce that you don't realize you > are introducing. It is "big data" removing the uniqueness and > reducing the search space. A good article. There is a follow-up at http://arstechnica.com/security/2013/03/how-i-became-a-password-cracker/ Although it affects a user, the lack of security at a site is not fixable by him and is not his responsibility. If usernames and hashes are exposed to an off-line attack I would agree the only certain protection is a long, complex password comprising random characters. It would be beyond the present techniques to match the hash in any realistic time. I am still going to maintain that "TwasBrilligAndTheSlithyToves" is a more than adquate password for logging in *on-line*. If I were to lack trust in the maintenence of security at a site I might consider a change of heart. But then - what would I base my judgement on. apart from the theoretcal possibility? > I won't say that the technique you show above is a bad thing. But the > current wisdom is that it isn't good enough anymore because after > analyzing millions of real world passwords, programs can now guess > what humans will do much of the time. So what you really need is > something other than what a human would produce. We are still on off-line cracking? How does this sound? Memorable passwords are good. Long, complex passwords are also good. One needn't exclude the other. I can remember "TwasBrilligAndTheSlithyToves" and associate it with an account. Before signing up I do echo TwasBrilligAndTheSlithyToves | sha1sum | base64 | cut -c -30 The output is what I give to a site as a password. Furthermore, before any future logins I can run the command again to get the same password. Isn't this on-line and off-line cracking taken care of? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150114215605.gb15...@copernicus.demon.co.uk
Re: problem with corrupted root password
On Wed, Jan 14, 2015 at 03:07:09PM -0500, Comer Duncan wrote: > I recently got wheezy up and running. I installed xfce4 and like it. > > However, today in the process of trying to spawn a root terminal (in > Accessories) and going through a cycle of trying to get authorized but > being prevented by repeated complaints that the system password I used was > not correct, I now find that I can not get logged in in single-user mode! > I have thus royally screwed up. So, how can I get the system password > changed to something new? > > Thanks for help and apologies for making such an error. Boot using a Live CD, then as root: mount /dev/sda1 /mnt/sda1 (or whatever device is your root partition) chroot /mnt/sda1 passwd signature.asc Description: Digital signature
problem with corrupted root password
I recently got wheezy up and running. I installed xfce4 and like it. However, today in the process of trying to spawn a root terminal (in Accessories) and going through a cycle of trying to get authorized but being prevented by repeated complaints that the system password I used was not correct, I now find that I can not get logged in in single-user mode! I have thus royally screwed up. So, how can I get the system password changed to something new? Thanks for help and apologies for making such an error. Comer
Re: Directories changing their side when copied!
On 01/14/2015 09:16 AM, Rodolfo Medina wrote: Hi all. I realized that the same directory, once copied onto vfat pendrive with `cp' or also `rsync', have a size (detected with `du') that doesn't match with the source. Different block sizes. http://lists.slug.org.au/public/slug/2004/07/msg3.html :) Ric -- My father, Victor Moore (Vic) used to say: "There are two Great Sins in the world... ..the Sin of Ignorance, and the Sin of Stupidity. Only the former may be overcome." R.I.P. Dad. Linux user# 44256 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54b6be88.4070...@gmail.com
Re: Find obsolete packages without using aptitude?
Bob Proulx wrote: > Try this: > >apt-show-versions | grep -v uptodate > > Or read my answer posted here Saturday: > >https://lists.debian.org/debian-user/2015/01/msg00358.html Thanks, excellent. I'll try to improve the variety of my search phrases, and digging deeper in the archive before posting next time. -- Fredrik Jonson -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/slrnmbd6gi.g6k.fred...@biggles.jonson.org
Re: Directories changing their side when copied!
On 14.1.2015 16:16, Rodolfo Medina wrote: Hi all. I realized that the same directory, once copied onto vfat pendrive with `cp' or also `rsync', have a size (detected with `du') that doesn't match with the source. diff -r /original/dir /pendrive/dir -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54b67b7a.8000...@pp.nic.fi
Re: Directories changing their side when copied!
On 01/14/2015 at 09:16 AM, Rodolfo Medina wrote: > Hi all. > > I realized that the same directory, once copied onto vfat pendrive > with `cp' or also `rsync', have a size (detected with `du') that > doesn't match with the source. > > Please help. This is probably because du reports "size on disk" - that is, the amount by which the available space on the disk would be increased if the file weren't present - rather than the actual number of bytes in the file, and the difference between those two numbers will vary depending on what filesystem the file is sitting on. Specifically, FAT-based filesystems have different overhead from EXT* filesystems, which are probably what a modern Debian system is using by default. Thus, since du reports "total size including filesystem overhead", the space consumed by a file on a FAT FS will likely be different from the space consumed by that file on an EXT FS. The principle underlying this has been reported by Windows at least as far back as Windows 95. If you right-click on a file in the Windows file-manager program (Windows Explorer) and choose Properties, the resulting dialog will give you two different file-size values; I believe they're labeled "size in bytes" and "size on disk". The latter is what du reports, and is what differs depending on what filesystem the file is sitting on. -- The Wanderer hopes that this is less confusing to read than it felt like when he was writing it The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Directories changing their side when copied!
Hi all. I realized that the same directory, once copied onto vfat pendrive with `cp' or also `rsync', have a size (detected with `du') that doesn't match with the source. Please help. Thanks, Rodolfo -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87vbk95twq@gmail.com
Re: Have I been hacked?
Bob Proulx writes: > So what you really need is something other than what a human would > produce. And pwgen does that just fine: a different 12 character random password for every site. -- John Hasler jhas...@newsguy.com Elmwood, WI USA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnm1fnx8@thumper.dhh.gt.org
Re: Disable server so it does not start on reboot (even after upgrade)?
On Tue, Jan 13, 2015 at 11:49:38PM +0200, Andrei POPESCU wrote: > On Vi, 09 ian 15, 15:02:34, Xavi wrote: > > First I do: > > > > sudo update-rc.d -f apache2 remove > > > > and then, to assert the rc.d links are not recreated, > > I recreate them stopped in all runlevels: > > > > sudo update-rc.d apache2 stop 80 0 1 2 3 4 5 6 . > > Or one could just use 'disable'. Couldn't you just turn apache2 off in rcconf? Or did I miss something in this thread? ./tony -- http://tonybaldwin.me -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150114134739.ga27...@myownsite.me
Re: Recent upgrade 'broke' sleep & hibernate in KDE Plasma Battery Monitor
On Wed, 14 Jan 2015 06:58:00 -0500 Mike McGinn wrote: > Don't complain about my top post. I don't care and will ignore you. We'll complain about not trimming the post. Cheers, Ron. -- 99 percent of lawyers give the rest a bad name. -- http://www.olgiati-in-paraguay.org -- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150114090603.7bb41...@ron.cerrocora.org
Re: Recent upgrade 'broke' sleep & hibernate in KDE Plasma Battery Monitor
See Bug#774461. Download the kernel patch and see if it fixes your problem. Send an email to 774...@bugs.debian.org if it does. I had the same problem and used "reportbug" to report a bug against the kernel - which led me to the fix. Don't complain about my top post. I don't care and will ignore you. Mike On Wednesday, January 14, 2015 06:17:12 Alex wrote: > Hi > > I ran the following upgrade through Synaptic (see relevant excerpt from > /var/log/apt/history.log below) and ever since that upgrade KDE Plasma > Battery Monitor now no longer functions as it used to do. > > Choosing 'sleep' causes the laptop to do what appears to be an emergency > 'shutdown -h' without saving anything - not even the users .bash_history > file > Choosing 'hibernate' causes the laptop to be an emergency 'shutdown -r' > without saving anything - not even the users .bash_history file and > promptly goes into a reboot - not the desired result. > > Excerpt from /var/log/apt/history.log begins << > > Start-Date: 2015-01-12 20:26:15 > Commandline: synaptic > Install: libllvm3.0:amd64 (3.0-10, automatic) > Upgrade: libgnustep-base1.22:amd64 (1.22.1-4, 1.22.1-4+deb7u1), > base-files:amd64 (7.1wheezy7, 7.1wheezy8), libebackend-1.2-2:amd64 > (3.4.4-3, 3.4.4-3+deb7u1), wireless-regdb:amd64 (2014.06.13-1~deb7u1, > 2014.10.07-1~deb7u1), clamav:amd64 (0.98.4+dfsg-0+deb7u2, > 0.98.5+dfsg-0+deb7u2), clamav-base:amd64 (0.98.4+dfsg-0+deb7u2, > 0.98.5+dfsg-0+deb7u2), libapt-inst1.5:amd64 (0.9.7.9+deb7u6, > 0.9.7.9+deb7u7), libclamav6:amd64 (0.98.4+dfsg-0+deb7u2, > 0.98.5+dfsg-0+deb7u2), apache2-mpm-prefork:amd64 (2.2.22-13+deb7u3, > 2.2.22-13+deb7u4), libedata-book-1.2-13:amd64 (3.4.4-3, 3.4.4-3+deb7u1), > linux-image-3.2.0-4-amd64:amd64 (3.2.63-2+deb7u2, 3.2.65-1), > linux-headers-3.2.0-4-amd64:amd64 (3.2.63-2+deb7u2, 3.2.65-1), > apache2-utils:amd64 (2.2.22-13+deb7u3, 2.2.22-13+deb7u4), > libdatetime-timezone-perl:amd64 (1.58-1+2014h, 1.58-1+2014j), > gnustep-base-common:amd64 (1.22.1-4, 1.22.1-4+deb7u1), apt-utils:amd64 > (0.9.7.9+deb7u6, 0.9.7.9+deb7u7), libedata-cal-1.2-15:amd64 (3.4.4-3, > 3.4.4-3+deb7u1), debian-archive-keyring:amd64 (2014. > 1~deb7u1, 2014.3~deb7u1), apache2.2-common:amd64 (2.2.22-13+deb7u3, > 2.2.22-13+deb7u4), apt:amd64 (0.9.7.9+deb7u6, 0.9.7.9+deb7u7), > linux-headers-3.2.0-4-common:amd64 (3.2.63-2+deb7u2, 3.2.65-1), > gnustep-base-runtime:amd64 (1.22.1-4, 1.22.1-4+deb7u1), libcurl3:amd64 > (7.26.0-1+wheezy11, 7.26.0-1+wheezy12), libcurl3:i386 > (7.26.0-1+wheezy11, 7.26.0-1+wheezy12), tzdata-java:amd64 > (2014h-0wheezy1, 2014j-0wheezy1), libedataserver-1.2-16:amd64 (3.4.4-3, > 3.4.4-3+deb7u1), apache2.2-bin:amd64 (2.2.22-13+deb7u3, > 2.2.22-13+deb7u4), clamav-docs:amd64 (0.98.4+dfsg-0+deb7u2, > 0.98.5+dfsg-0+deb7u2), libebook-1.2-13:amd64 (3.4.4-3, 3.4.4-3+deb7u1), > curl:amd64 (7.26.0-1+wheezy11, 7.26.0-1+wheezy12), libapt-pkg4.12:amd64 > (0.9.7.9+deb7u6, 0.9.7.9+deb7u7), libcamel-1.2-33:amd64 (3.4.4-3, > 3.4.4-3+deb7u1), file:amd64 (5.11-2+deb7u6, 5.11-2+deb7u7), > libecal-1.2-11:amd64 (3.4.4-3, 3.4.4-3+deb7u1), clamav-freshclam:amd64 > (0.98.4+dfsg-0+deb7u2, 0.98.5+dfsg-0+deb7u2), tzdata:amd64 > (2014h-0wheezy1, 2014j-0wheezy1), apache2-doc:amd64 (2.2. > 22-13+deb7u3, 2.2.22-13+deb7u4), evolution-data-server-common:amd64 > (3.4.4-3, 3.4.4-3+deb7u1), evolution-data-server:amd64 (3.4.4-3, > 3.4.4-3+deb7u1), openssl:amd64 (1.0.1e-2+deb7u13, 1.0.1e-2+deb7u14), > libcurl3-gnutls:amd64 (7.26.0-1+wheezy11, 7.26.0-1+wheezy12), > linux-libc-dev:amd64 (3.2.63-2+deb7u2, 3.2.65-1), > libedataserverui-3.0-1:amd64 (3.4.4-3, 3.4.4-3+deb7u1), binutils:amd64 > (2.22-8, 2.22-8+deb7u2), clamav-daemon:amd64 (0.98.4+dfsg-0+deb7u2, > 0.98.5+dfsg-0+deb7u2), libmagic1:amd64 (5.11-2+deb7u6, 5.11-2+deb7u7), > libssl1.0.0:amd64 (1.0.1e-2+deb7u13, 1.0.1e-2+deb7u14), libssl1.0.0:i386 > (1.0.1e-2+deb7u13, 1.0.1e-2+deb7u14) > End-Date: 2015-01-12 20:30:17 > > >> Excerpt from /var/log/apt/history.log ends > > Both of these options used to work perfectly until this upgrade. > > This is VERY problematic for us, as we are on stand-alone solar power, > and the ability to 'sleep' our laptops, saves us energy that we would > otherwise have to run a diesel generator in order to meet our > electricity requirements. Not only is this costly to our pockets, it is > also costly to the environment, and the diesel fumes stink us out of > house and home if the wind is from the wrong direction. > > I have included excerpts from the file /var/log/pm-suspend.log (pre > upgrade - working and post upgrade - broken) as debugging information > below: > > > Excerpt from /var/log/pm-suspend.log (pre upgrade - working) starts << > > Initial commandline parameters: > Mon Jan 12 16:50:47 AEDT 2015: Running hooks for suspend. > Running hook /usr/lib/pm-utils/sleep.d/000kernel-change suspend suspend: > > /usr/lib/pm-utils/sleep.d/000kernel-change suspend suspend: success. > Running hook /usr/lib/pm-utils/sleep.d/00logging suspend suspend: > Linux debacer
Recent upgrade 'broke' sleep & hibernate in KDE Plasma Battery Monitor
Hi I ran the following upgrade through Synaptic (see relevant excerpt from /var/log/apt/history.log below) and ever since that upgrade KDE Plasma Battery Monitor now no longer functions as it used to do. Choosing 'sleep' causes the laptop to do what appears to be an emergency 'shutdown -h' without saving anything - not even the users .bash_history file Choosing 'hibernate' causes the laptop to be an emergency 'shutdown -r' without saving anything - not even the users .bash_history file and promptly goes into a reboot - not the desired result. Excerpt from /var/log/apt/history.log begins << Start-Date: 2015-01-12 20:26:15 Commandline: synaptic Install: libllvm3.0:amd64 (3.0-10, automatic) Upgrade: libgnustep-base1.22:amd64 (1.22.1-4, 1.22.1-4+deb7u1), base-files:amd64 (7.1wheezy7, 7.1wheezy8), libebackend-1.2-2:amd64 (3.4.4-3, 3.4.4-3+deb7u1), wireless-regdb:amd64 (2014.06.13-1~deb7u1, 2014.10.07-1~deb7u1), clamav:amd64 (0.98.4+dfsg-0+deb7u2, 0.98.5+dfsg-0+deb7u2), clamav-base:amd64 (0.98.4+dfsg-0+deb7u2, 0.98.5+dfsg-0+deb7u2), libapt-inst1.5:amd64 (0.9.7.9+deb7u6, 0.9.7.9+deb7u7), libclamav6:amd64 (0.98.4+dfsg-0+deb7u2, 0.98.5+dfsg-0+deb7u2), apache2-mpm-prefork:amd64 (2.2.22-13+deb7u3, 2.2.22-13+deb7u4), libedata-book-1.2-13:amd64 (3.4.4-3, 3.4.4-3+deb7u1), linux-image-3.2.0-4-amd64:amd64 (3.2.63-2+deb7u2, 3.2.65-1), linux-headers-3.2.0-4-amd64:amd64 (3.2.63-2+deb7u2, 3.2.65-1), apache2-utils:amd64 (2.2.22-13+deb7u3, 2.2.22-13+deb7u4), libdatetime-timezone-perl:amd64 (1.58-1+2014h, 1.58-1+2014j), gnustep-base-common:amd64 (1.22.1-4, 1.22.1-4+deb7u1), apt-utils:amd64 (0.9.7.9+deb7u6, 0.9.7.9+deb7u7), libedata-cal-1.2-15:amd64 (3.4.4-3, 3.4.4-3+deb7u1), debian-archive-keyring:amd64 (2014. 1~deb7u1, 2014.3~deb7u1), apache2.2-common:amd64 (2.2.22-13+deb7u3, 2.2.22-13+deb7u4), apt:amd64 (0.9.7.9+deb7u6, 0.9.7.9+deb7u7), linux-headers-3.2.0-4-common:amd64 (3.2.63-2+deb7u2, 3.2.65-1), gnustep-base-runtime:amd64 (1.22.1-4, 1.22.1-4+deb7u1), libcurl3:amd64 (7.26.0-1+wheezy11, 7.26.0-1+wheezy12), libcurl3:i386 (7.26.0-1+wheezy11, 7.26.0-1+wheezy12), tzdata-java:amd64 (2014h-0wheezy1, 2014j-0wheezy1), libedataserver-1.2-16:amd64 (3.4.4-3, 3.4.4-3+deb7u1), apache2.2-bin:amd64 (2.2.22-13+deb7u3, 2.2.22-13+deb7u4), clamav-docs:amd64 (0.98.4+dfsg-0+deb7u2, 0.98.5+dfsg-0+deb7u2), libebook-1.2-13:amd64 (3.4.4-3, 3.4.4-3+deb7u1), curl:amd64 (7.26.0-1+wheezy11, 7.26.0-1+wheezy12), libapt-pkg4.12:amd64 (0.9.7.9+deb7u6, 0.9.7.9+deb7u7), libcamel-1.2-33:amd64 (3.4.4-3, 3.4.4-3+deb7u1), file:amd64 (5.11-2+deb7u6, 5.11-2+deb7u7), libecal-1.2-11:amd64 (3.4.4-3, 3.4.4-3+deb7u1), clamav-freshclam:amd64 (0.98.4+dfsg-0+deb7u2, 0.98.5+dfsg-0+deb7u2), tzdata:amd64 (2014h-0wheezy1, 2014j-0wheezy1), apache2-doc:amd64 (2.2. 22-13+deb7u3, 2.2.22-13+deb7u4), evolution-data-server-common:amd64 (3.4.4-3, 3.4.4-3+deb7u1), evolution-data-server:amd64 (3.4.4-3, 3.4.4-3+deb7u1), openssl:amd64 (1.0.1e-2+deb7u13, 1.0.1e-2+deb7u14), libcurl3-gnutls:amd64 (7.26.0-1+wheezy11, 7.26.0-1+wheezy12), linux-libc-dev:amd64 (3.2.63-2+deb7u2, 3.2.65-1), libedataserverui-3.0-1:amd64 (3.4.4-3, 3.4.4-3+deb7u1), binutils:amd64 (2.22-8, 2.22-8+deb7u2), clamav-daemon:amd64 (0.98.4+dfsg-0+deb7u2, 0.98.5+dfsg-0+deb7u2), libmagic1:amd64 (5.11-2+deb7u6, 5.11-2+deb7u7), libssl1.0.0:amd64 (1.0.1e-2+deb7u13, 1.0.1e-2+deb7u14), libssl1.0.0:i386 (1.0.1e-2+deb7u13, 1.0.1e-2+deb7u14) End-Date: 2015-01-12 20:30:17 >> Excerpt from /var/log/apt/history.log ends Both of these options used to work perfectly until this upgrade. This is VERY problematic for us, as we are on stand-alone solar power, and the ability to 'sleep' our laptops, saves us energy that we would otherwise have to run a diesel generator in order to meet our electricity requirements. Not only is this costly to our pockets, it is also costly to the environment, and the diesel fumes stink us out of house and home if the wind is from the wrong direction. I have included excerpts from the file /var/log/pm-suspend.log (pre upgrade - working and post upgrade - broken) as debugging information below: Excerpt from /var/log/pm-suspend.log (pre upgrade - working) starts << Initial commandline parameters: Mon Jan 12 16:50:47 AEDT 2015: Running hooks for suspend. Running hook /usr/lib/pm-utils/sleep.d/000kernel-change suspend suspend: /usr/lib/pm-utils/sleep.d/000kernel-change suspend suspend: success. Running hook /usr/lib/pm-utils/sleep.d/00logging suspend suspend: Linux debacer 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u2 x86_64 GNU/Linux Module Size Used by xt_limit 12638 8 xt_tcpudp 12570 7 ipt_LOG12605 8 ipt_MASQUERADE 12594 0 xt_DSCP12643 0 ipt_REJECT 12502 1 nf_conntrack_irc 12427 0 nf_conntrack_ftp 12605 0 xt_state 12503 6 iptable_nat12928 0 nf_nat 18242 2 iptable_nat,ipt_MASQUERADE nf_c
Re: Have I been hacked?
2015/01/13 5:17 "Brian" : > > On Sun 11 Jan 2015 at 16:43:34 -0700, Bob Proulx wrote: > > > Brian wrote: > > > Bob Proulx wrote: > > > > Complete agreement. I want to go further and say that a password that > > > > you can remember without needing to write it down is probably not a > > > > good password. > > > > > > Security of an ssh login is aimed at allowing access to some but denying > > > it to others. An authorised user who cannot remember his 20 character > > > password has experienced a security failure. > > > > Security is the part of the system designed to make it not only hard > > to use but the design goal is to prevent it from being used. > > Seeing that my argument that enforcing (if it is possible) an > unmemorable password is not in the best interests of security doesn't > gain any tracton, let me try a different tack. > > The password > > TwasBrilligAndTheSlithyToves TwasNotBrilligNAND might have been a stronger password until we talked about these. Both are dead meat now. Or perhaps tVaS nicht BrIlLiG NAND, although it, too, should be considered dead meat now that we have mentioned it in public. Do a bit of l33t$peak on it and it could have been strong enough to use. If I had refrained from mentioning it, at least. > strikes me as a pretty good one for an ssh login. (I have capitalised > some letters for readability, not to add complexity). Personally, I find > it easy to remember and associate with ssh and my account. I cannot see > why it is not a good password for me. Just remember that fail2ban only does temporary tarpitting, and only if the attacks are repeated to quickly. > The automated probes wouldn't get close to cracking it. Think of a bot farm continuously hitting a crowd of targets, once a second, cycling through spoofed IPs, using informed strategies instead of pure brute force. If they can spoof one IP, they can spoof another. > The danger might > be a directed attack - from friends, associates, colleagues etc. If they > knew about my fixation on Lewis Carroll they might have a go at breaking > in. If they think you have something they want, people you don't know will find out about your interests. Blog posts, posts here, etc. > Actually, it would be ok as a password for banking access too. There > surely cannot be a banking site which does not take action after a > number of failed logins. Maybe not using fail2ban, but a similar > approach which protects both parties. Means you end up going to the bank in person, to get the lock removed. Banks aren't perfect, though. You could come to considerable trouble should, for instance, a bank employee decide to do a little investigating passwords in her spare time, without permission. But it's your bank account. Go for it. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Apache or Radius crash
Hi, I installed an Apache with Radius-Authentification on my Debian7. An authentification is requested when entering a directory (Mitarbeiter) and the access was granted if I typ in the correct credentials. All fine! But I would like to make it more secure and enabled https, and now a programm (apache?) exit with a segfault. [Wed Jan 14 09:20:34 2015] [info] Initial (No.1) HTTPS request received for child 9 (server software.adint.dir:443) [Wed Jan 14 09:20:34 2015] [debug] mod_auth_radius-2.0.c(1185): Radius Auth for: software.adint.dir requests /Mitarbeiter/ : file=/var/www/data/Mitarbeiter/ [Wed Jan 14 09:20:34 2015] [debug] mod_auth_radius-2.0.c(1216): No cookie found. Trying RADIUS authentication.\n [Wed Jan 14 09:20:34 2015] [notice] child pid 6012 exit signal Segmentation fault (11) I can use it with http an all is fine, but with https the process terminate. Any suggestions? Regards Carsten smime.p7s Description: S/MIME Cryptographic Signature
Re: unable to boot with systemd (works with sysvinit)
On Sb, 10 ian 15, 12:33:36, Johannes Schauer wrote: > Hi, > > I'm not subscribed, so please keep me CC-ed. > > I'm unable to boot my laptop with systemd which worked before. I'm unable to > tell the changes I made since the last time it worked because according to my > uptime, the last time I rebooted was September last year. > cgroup /sys/fs/cgroup cgroup defaults 0 0 This is *probably* unrelated, but I would remove it anyway. It shouldn't be necessary unless you do fancy stuff with cgroups (other than what systemd already does). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: netwok issues
On Sb, 10 ian 15, 13:10:07, Pascal Hambourg wrote: > Francesco Pietra a écrit : > > Replaced defective Tyan-double-opterons server mainboard with a minimal > > asus H81M-K-intel i3, maintaining the same two mirror-raid HDs with debian > > amd64 wheezy. > > > > Now, network is only establised at a ZyXEL router when loading gnome, > > thereafter slogin to my amd64 server occurs regularly. Before that, at the > > linux prompt, no network with the H81M-K. Command > > New motherboard with integrated NIC means new MAC address, which means > new interface name (eth0 -> eth1) because of udev persistent naming > rules. Check the new interface name with "ifconfig -a" or "ip addr". If > the interface was configured in /etc/network/interfaces, update its name > accordingly. ... or /etc/udev/rules.d/70-persistent-net.rules Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Tip: Search Command Line Commands w/First Letters And Tab
On Vi, 09 ian 15, 20:33:41, Cindy-Sue Causey wrote: > > Very cool. My thoughts are always that maybe someone else doesn't know > it exists, and maybe they know of just the right wish list where this > feature or a tweak of it would be perfect for the next upgrade of > something else Debian out there. :) In bash (but probably other shells have similar functionality) press Ctrl-r and start typing *any* part of a recent command ;) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: help in purging old packages
On Vi, 09 ian 15, 16:54:39, Darac Marjal wrote: > On Fri, Jan 09, 2015 at 11:23:17AM -0500, Comer Duncan wrote: > >Hi, > > > >I have a situation in which I am running wheezy 7.7 and for various > >reasons now want to purge all packages which for some reason are still > >present from etch, lenny, and squeeze. What I would like to know is how > >can I purge all such packages using dpkg? I can not seem to find how to > >select just those old packages for purging. Can those who know about this > >please help? aptitude search '?narrow(?installed,?not(?archive(^stable$)))' If you are satisfied with the result replace 'search' with 'purge'. > If you want to purge all packages which are installed and installable, > but where the version is the same as in an earlier release... that's > probably going to need some scripting :) I must be misunderstanding something, but why would anyone want to remove those? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
