On Fri, Oct 22, 2010 at 5:58 AM,
<debian-user-digest-request@lists.debian.org> wrote:
Content-Type: text/plain
debian-user-digest Digest Volume 2010 : Issue 1688
Today's Topics:
Re: XFS and Power Failures [Was: Lin [ Stan Hoeppner <stan@hardwarefreak.c ]
Re: Debian 6.0 'Squeeze' home server [ Pinguim Ribeiro <pinguim.ribeiro@gm ]
Re: Debian stock kernel config -- CO [ Stan Hoeppner <stan@hardwarefreak.c ]
Re: dpkg issue [ =?UTF-8?B?SsO2cmctVm9sa2VyIFBlZXR6? ]
Re: scrollbar on left side [ Roel Schroeven <rschroev_nospam_ml@ ]
Re: ping packet loss when size gt 15 [ Chris Davies <chris-usenet@roaima.c ]
Re: I can't get the Linux kernel RDS [ =?iso-8859-1?q?Camale=F3n?= <noelam ]
Re: text-only login is root? [ "=?iso-8859-1?q?Jes=FAs_M=2E?= Nava ]
restricting number of user logins [ Mag Gam <magawake@gmail.com> ]
Re: text-only login is root? [ "=?iso-8859-1?q?Jes=FAs_M=2E?= Nava ]
problems with USB disk [ lee <lee@yun.yagibdah.de> ]
Date: Fri, 22 Oct 2010 03:48:57 -0500
From: Stan Hoeppner <stan@hardwarefreak.com>
To: debian-user@lists.debian.org
Subject: Re: XFS and Power Failures [Was: Linux filesystems]
Message-ID: <[🔎] 4CC14FF9.5090909@hardwarefreak.com">[🔎] 4CC14FF9.5090909@hardwarefreak.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Volkan YAZICI put forth on 10/21/2010 5:04 AM:
> On Tue, 27 Jul 2010, Volkan YAZICI <yazicivo@ttmail.com> writes:
>> On Tue, 27 Jul 2010, Stan Hoeppner <stan@hardwarefreak.com> writes:
>>> What write operations were you performing at the time you pulled the plug?
>>> Unless you were writing the superblock it'd be almost impossible to hose the
>>> filesystem to the point it couldn't mount. Were you doing a resize operation
>>> when you pulled the plug? xfs_growfs? As far as recovery, it's automatic
>>> upon mounting the XFS filesystem. What do you mean, precisely, by "couldn't
>>> *recover* the / fs"?
>>
>> Vanilla XFS with noatime,notail like basic mount options. The test was
>> simple, I was just typing "SELECT 1" from a psql command line (this
>> query shouldn't even hit to disk, it just basically returns 1) and
>> unplugged machine. At boot, I dropped to fsck command line. At command
>> prompt, I manually fiddled around with fsck of xfs to recover the
>> unmounted / filesystem, but had no luck. (I also tried recommendations
>> and informative messages supplied by manpages and command
>> outputs/warnings.) Also if you would Google, it shouldn't be hard to
>> spot similar experiences from other people.
>
> Another scenario, same failure. I have a squeeze installed notebook and
> having troubles with X. It crashes for some driver specific reasons and
> I need to hard-reset the notebook. 1-2 times I found WindowMaker missing
> its workspaces, and I didn't have time to inspect the problem. Now I
> lost all of my Opera bookmarks (~500 collected in years). Thanks XFS,
> but no, you're not power-failure. (BTW, I "kill -9"ed Opera many times,
> and it restored all of its settings properly. I don't think it is an
> Opera or WindowMaker related bug.)
Open your files with O_PONIES and all your filesystem problems will
magically disappear.
Please educate yourself by reading this http://lwn.net/Articles/351422/
and then reply to your own comments above.
Actually, anyone reading this post should read the article and comments
at that link. There is way too much misinformation running around and
too many people taking positions publicly (especially on this list) that
are 180 degrees opposite of fact with regard to correct/proper
filesystem behavior.
--
Stan
Date: Fri, 22 Oct 2010 08:48:52 +0000 (UTC)
From: Pinguim Ribeiro <pinguim.ribeiro@gmail.com>
To: debian-user@lists.debian.org
Subject: Re: Debian 6.0 'Squeeze' home server - Installation guide
Message-ID: <[🔎] loom.20101022T104657-224@post.gmane.org">[🔎] loom.20101022T104657-224@post.gmane.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
lee <lee <at> yun.yagibdah.de> writes:
>
> On Wed, Oct 20, 2010 at 08:25:03PM +0000, Pinguim.ribeiro wrote:
> >
> > I mean the popularity-contest depends on exim4 | mail-transport-agent,
> > packages to be installed later and not by the debian installer.
>
> You would select to install exim4-daemon-heavy anyway, along with
> clamav and spamassassin. The installer installs these for you, but
> it´s up to you to set them up.
>
I'll install postfix: easy to setup and integrates clamav and
spamassassin too
> If you need IMAP, you´d install courier-imap (if you don´t want to use
> cyrus). I haven´t tried courier-imap yet, but it seems to be pretty
> much the only IMAP server that supports maildir.
>
I'm using dovecot: it also supports maildir
> Having that said, once you have set up a minimal system capable of
> providing the services you need, you could put the output of 'dpkg
> --get-selections' into the guide :)
>
Great idea! I will!
thanks once again, Lee!
Fernando Ribeiro
Date: Fri, 22 Oct 2010 04:51:03 -0500
From: Stan Hoeppner <stan@hardwarefreak.com>
To: debian-user@lists.debian.org
Subject: Re: Debian stock kernel config -- CONFIG_NR_CPUS=32?
Message-ID: <[🔎] 4CC15E87.7050700@hardwarefreak.com">[🔎] 4CC15E87.7050700@hardwarefreak.com>
Content-Type: text/plain; charset=windows-1251
Content-Transfer-Encoding: 7bit
Ron Johnson put forth on 10/22/2010 2:00 AM:
> On 10/22/2010 12:53 AM, Arthur Machlas wrote:
>> On Thu, Oct 21, 2010 at 8:15 PM, Andrew Reid<reidac@bellatlantic.net>
>> wrote:
>>> But I'm curious if anyone on the list knows the rationale for
>>> distributing kernels with this set to 32. Is that just a
>>> reasonable number that's never been updated? Or is there some
>>> complication that arises after 32 cores, and should I be more
>>> careful about tuning other parameters?
>>
>> I've always set the number of cores to exactly how many I have x2 when
>> I roll my own, which on my puny systems is either 4 or 8. I seem to
>> recall reading that there is a slight performance hit for every core
>> you support.
>
> Correct. The amount of effort needed for cross-CPU communication, cache
> coherency and OS process coordination increases much more than linearly
> as you add CPUs.
All of these things but the scheduler, what you call "process
coordination", are invisible to the kernel for the most part and are
irrelevant to the discussion of CONFIG_NR_CPUS.
> Crossbar communication (introduced first, I think, by DEC/Compaq in
> 2001) eliminated a lot of the latency in multi-CPU communications which
> plagues bus-based systems.
Crossbar bus controllers have been around for over 30 years, first
implemented by IBM in its mainframes in the late 70s IIRC. Many
RISC/UNIX systems in the 90s implemented crossbar controllers, including
Data General, HP, SGI, SUN, Unisys, etc.
You refer to the Alpha 21364 processor introduced in the
ES47/GS80/GS1280, which did not implement a crossbar for inter-socket
communication. The 21364 implemented a NUMA interconnect based on a
proprietary directory protocol for multiprocessor cache coherence.
These circuits in NUMA machines are typically called "routers", and,
functionally, replace the crossbar of yore.
> AMD used a similar mesh in it's dual-core CPUs (not surprising, since
> many DEC engineer went to AMD). Harder to design, but much faster.
You make it sound as if AMD _chose_ this design _over_ a shared bus.
There never was such a choice to be made. Once you implement multiple
cores on a single die you no longer have the option of using a shared
bus such as GTL as the drive voltage is 3.3v, over double the voltages
used within the die. By definition buses are _external_ to ICs, and
connect ICs to one another. Buses aren't used within a die. Discrete
data paths are.
> Intel's first (and 2nd?) gen multi-core machines were bus-based; easier
> to design, quicker to get to market, but a lot slower.
This is because they weren't multi-core chips, but Multi Chip Modules,
or MCMs: http://en.wikipedia.org/wiki/Multi-Chip_Module Communication
between ICs within an MCM is external communication, thus a bus can be
used, as well as NUMA which IBM uses in its pSeries (Power5/6/7) MCMs
and Cray used on the X1 and X1E.
> (OP's machine is certainly NUMA, where communication between cores on a
> chip is much faster than communication with cores on a different chip.)
At least you got this part correct Ron. ;)
Back to the question of the thread, the answer, as someone else already
stated, is that the only downside to setting CONFIG_NR_CPUS= to a value
way above the number of physical cores in the machine is kernel
footprint, but it's not very large given the memories of today's
machines. Adding netfilter support will bloat the kernel footprint far
more than setting CONFIG_NR_CPUS=256 when you only have 48 cores in the box.
--
Stan
Date: Fri, 22 Oct 2010 12:24:40 +0200
From: =?UTF-8?B?SsO2cmctVm9sa2VyIFBlZXR6?= <jvpeetz@web.de>
To: debian-user@lists.debian.org
Subject: Re: dpkg issue
Message-ID: <i9roog$lgf$1@dough.gmane.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
First try
dpkg --update-avail
If this doesn't help clean-up the local repository of retrieved package
files
apt-get clean
and rebuild the repository
apt-get update
or
aptitude update
--
Best regards,
Jörg-Volker.
Date: Fri, 22 Oct 2010 12:24:46 +0200
From: Roel Schroeven <rschroev_nospam_ml@fastmail.fm>
To: debian-user@lists.debian.org
Subject: Re: scrollbar on left side
Message-ID: <i9rope$jug$1@dough.gmane.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
lee wrote:
> On Thu, Oct 21, 2010 at 11:39:22PM +0200, Andreas Weber wrote:
>> On 2010-10-21 22:48, lee wrote:
>>> On a side note: Someone once asked me why the text is moving up when
>>> you move the scrollbar down. Where´s the logic in that? Why isn´t the
>>> text moving up together with the scroll bar?
>> Seriously? It indicates the position in the document, and so it behaves.
>
> Yes, seriously, and I do see the point. You move the text with the
> scrollbar, so why does the text move into the opposite direction of
> the scrollbar?
Because it doesn't move the text, it moves the viewing window in the text.
Date: Fri, 22 Oct 2010 10:43:43 +0100
From: Chris Davies <chris-usenet@roaima.co.uk>
To: debian-user@lists.debian.org
Subject: Re: ping packet loss when size gt 1500
Message-ID: <[🔎] fv28p7xlb4.ln2@news.roaima.co.uk">[🔎] fv28p7xlb4.ln2@news.roaima.co.uk>
Adam Hardy <adam.ant@cyberspaceroad.com> wrote:
> What I need is a ping test or something that I can put in smokeping
> to alert me when I forget, e.g. this morning there was a power outage
> that took out the modem.
I think there are others here making suggestions for that.
> What do you mean by 'clamped'?
"Locked to". At the risk of stating the obvious, do take a look at
https://blue-labs.org/howto/mtu-mss.php. What I'm not sure about is
whether the clamping actually means a maximum value, or whether it would
even refuse to allow the MTU to be reduced.
> I dropped these firewall rules just now and "ping -s 1473
> mktgw1.ibllc.com" loses all packets, so our thread pretty much only
> concerns the situation when this firewall is down.
Possibly. If there's something else blocking ICMP then your firewall
ruleset will be masked by that other device. But if you managed to
resolve the issue for the remote device your firewall would still get
in the way and muddy the results.
> My actual question is: what would fail to get through when that firewall
> was up? For my testing purposes.
If I've read the ruleset correctly, it drops all ICMP. This includes
host-unreachable, port-unreachable, packet-too-big, in addition to the
well known echo/response pair (ping).
Chris
Date: Fri, 22 Oct 2010 11:32:26 +0000 (UTC)
From: =?iso-8859-1?q?Camale=F3n?= <noelamac@gmail.com>
To: debian-user@lists.debian.org
Subject: Re: I can't get the Linux kernel RDS exploit to exploit my
machine...
Message-ID: <[🔎] pan.2010.10.22.11.32.26@gmail.com">[🔎] pan.2010.10.22.11.32.26@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
On Thu, 21 Oct 2010 16:49:43 -0500, Ron Johnson wrote:
> I installed my kernel back on 01-Oct, so it should be vulnerable, but
> it's not, even when I modprobed the rds modules.
(...)
> [*] Failed to resolve kernel symbols.
Mmm... by reading the "c" file I think that is not the message you should
get but "[*] Exploit failed to get root." or "[*] Got root!" (for
affected and vulnerable systems) :-)
The sample file got stuck at resolving some kernel symbols and then
exits. The question is why :-?
Greetings,
--
Camaleón
Date: Fri, 22 Oct 2010 13:47:31 +0200
From: "=?iso-8859-1?q?Jes=FAs_M=2E?= Navarro" <jesus.navarro@undominio.net>
To: debian-user@lists.debian.org
Cc: post id <postid@att.net>
Subject: Re: text-only login is root?
Message-Id: <[🔎] 201010221347.31191.jesus.navarro@undominio.net">[🔎] 201010221347.31191.jesus.navarro@undominio.net>
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hi, postid:
On Thursday 21 October 2010 23:49:03 post id wrote:
> I've set up a minimal system on one of my machines and used no login
> manager
Of course you do. If you weren't using one, you wouldn't be able to log in=
to=20
the system.
> -- I login at the prompt
See? What you don't use is a *graphical* login manager.
> and type startx to start the graphical =20
> session. Now I read a claim that if one didn't use a login manager to log
> in and start X, then _one_=A0 was logging in with root privileges. That doe=
sn't
> appear to be true since I don't seem to have root privileges,
Not.
You log into the system as whatever user and thereafter you run programs un=
der=20
that user, being the X-Window manager (the graphical session) one of them.
Maybe you were misguided by the fact that the X system needs, no matter how=
it=20
is run, some high privileges (it needs some low lever access to your system=
,=20
graphic memory, for instance) and it's a so called "setuid program" (which=
=20
means the program itself runs under the "root" effective user... always, ev=
en=20
if a graphical login manager is involved). Anyway, that seems to be=20
something a bit more technical than you need to know now: for all your=20
practical purposes, the graphical environment will still give you just the=
=20
privileges you already got when you started your session from the command=20
prompt.
> although when=20
> I do ctrl-alt-f1 I get a list of messages such as "Restore TV PLL," etc.
> rather than a command prompt.
By means of "startx" you started a command basically as any other else.
Try this:
Once you start your command session, execute the command 'ls -lR /' (this w=
ill=20
recursively list all the files in your system). You will see it takes quit=
e=20
long to run and that you won't be returned to a command prompt till it's=20
finished. That's the usual way for all commands, startx included. Since=20
startx didn't finish while you still have your GUI at AltGr-7 terminal, no=
=20
command prompt is returned.
But unix-like systems seem to have a solution for everything: foreground=20
long-running commands (like startx) can be "sent to background" by means of=
=20
the ampersand operator, like this: 'startx &'. By doing this, you=20
temporarily dettach the command from its controlling terminal and because o=
f=20
that a command prompt is returned.
> I don't get that on my other machines running=20
> graphical login managers.
A graphical login manager is a "daemon": a kind of program specifically=20
developed not to need a controlling terminal to be launched (and usually=20
meant to be automatically started at boot up).
Again, try this:
Once you start your non-graphical session, execute the command 'ps -efH'. =
You=20
will see quite a long list of already running programs: all of them are=20
daemons. On your machines using a graphical login manager you will see it=
=20
somewhere in the output of ps (xdm, gdm, kdm... whatever you happen to be=20
using).
> Do I have a security problem here?
I hope you understand now by yourself that, no, you don't have any security=
=20
problem because of this. That's the way things are expected to work.
> If so, will =20
> just installing a lightweight login manager (xdm?) cure it or do I need to
> change some settings somewhere? I'd be thankful for advice. Please cc me
> since I'm not currently subscribed to the list.
The question is: if all you do from command prompt is login, then startx, t=
hen=20
start working from within the GUI, why do you take the extra hassle? Insta=
ll=20
your graphical login manager of choice and get done with it. Even if most =
of=20
what you do on your desktop is non-graphical, the X-Window manager is an=20
effective way to be able to launch multiple terminals and work from them. I=
=20
for one hasn't owned a text-only desktop/laptop for ages.
Cheers.
Date: Fri, 22 Oct 2010 07:57:12 -0400
From: Mag Gam <magawake@gmail.com>
To: debian-user <debian-user@lists.debian.org>
Subject: restricting number of user logins
Message-ID: <AANLkTi=qysi2_HgspA9EbsTTb8F-VBWKptHpv4nnoLLB@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Currently we do alot of `rsync -e ssh` to a host. Is it possible to
restrict only 5 logins per user on the server? My goal is to avoid
having 100s of these sshd processes running on the server which will
slow it down.
Date: Fri, 22 Oct 2010 13:57:24 +0200
From: "=?iso-8859-1?q?Jes=FAs_M=2E?= Navarro" <jesus.navarro@undominio.net>
To: debian-user@lists.debian.org
Cc: post id <postid@att.net>
Subject: Re: text-only login is root?
Message-Id: <[🔎] 201010221357.25038.jesus.navarro@undominio.net">[🔎] 201010221357.25038.jesus.navarro@undominio.net>
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi, postid:
On Friday 22 October 2010 02:26:38 post id wrote:
[...]
> So how do I shut down X properly? On this laptop I
> usually do "shutdown -h now" from a console when I'm
> ready to quit.
That certainly will stop the X environment since what you are doing is
completly halting the machine.
In order to just stop the X environment but still running your computer you
can always do it "brute force": the key combination Ctrl-Alt-Delete will
forcibly stop "just" the X environment. By doing this, you will see you are
returned to the controlling terminal and that the command prompt will be
restored (since the "startx program" is now stopped; remember my previous
message about it).
If startx is configured, as I suspect, to start not only the X-Windows system
but a window/desktop manager too (xfce, KDE, Gnome, whatever), there will be
somewhere within the window manager an option to shut it down (depending on
the environment, it will be accesable using your right mouse button or an
entry somewhere on the desktop bar). This will allow for the GUI to
properly "clean itself" prior to stop so it should be considered the proper
way.
But again, by what you say it seems that all you do from the text console is
launching your GUI and once you end up with your GUI you don't mean completly
stopping your computer. Given that, I'd say you'd be better off by
installing a graphical login manager (you yourself suggested xdm) and forget
about all this.
Cheers.
Date: Fri, 22 Oct 2010 14:07:09 +0200
From: lee <lee@yun.yagibdah.de>
To: debian-user <debian-user@lists.debian.org>
Subject: problems with USB disk
Message-ID: <[🔎] 20101022120709.GA17611@yun.yagibdah.de">[🔎] 20101022120709.GA17611@yun.yagibdah.de>
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Hi,
I惴 having trouble copying files for backup purposes to an USB disk
with rsync. Copying the files sometimes fails with "Input/output error
(5)", and I惴 getting messages in the syslog like these:
[128625.090339] sd 11:0:0:0: [sdf] Unhandled sense code
[128625.090342] sd 11:0:0:0: [sdf] Result: hostbyte=0x00 driverbyte=0x08
[128625.090345] sd 11:0:0:0: [sdf] Sense Key : 0x3 [current]
[128625.090348] sd 11:0:0:0: [sdf] ASC=0x11 ASCQ=0x0
[128625.090350] sd 11:0:0:0: [sdf] CDB: cdb[0]=0x28: 28 00 67 d0 99 65 00 00 10 00
[128625.090354] end_request: I/O error, dev sdf, sector 1741724005
[128627.397801] sd 11:0:0:0: [sdf] Unhandled sense code
[128627.397811] sd 11:0:0:0: [sdf] Result: hostbyte=0x00 driverbyte=0x08
[128627.397821] sd 11:0:0:0: [sdf] Sense Key : 0x3 [current]
[128627.397830] sd 11:0:0:0: [sdf] ASC=0x11 ASCQ=0x0
[128627.397839] sd 11:0:0:0: [sdf] CDB: cdb[0]=0x28: 28 00 67 d0 99 6d 00 00 08 00
[128627.397858] end_request: I/O error, dev sdf, sector 1741724013
[128627.397894] EXT4-fs error (device sdf3): __ext4_get_inode_loc: unable to read inode block - inode=52298807, block=209191011
[128629.945331] sd 11:0:0:0: [sdf] Unhandled sense code
[128629.945340] sd 11:0:0:0: [sdf] Result: hostbyte=0x00 driverbyte=0x08
[128629.945349] sd 11:0:0:0: [sdf] Sense Key : 0x3 [current]
[128629.945359] sd 11:0:0:0: [sdf] ASC=0x11 ASCQ=0x0
[128629.945367] sd 11:0:0:0: [sdf] CDB: cdb[0]=0x28: 28 00 67 d0 99 65 00 00 10 00
[128629.945386] end_request: I/O error, dev sdf, sector 1741724005
[128632.219655] sd 11:0:0:0: [sdf] Unhandled sense code
[128632.219664] sd 11:0:0:0: [sdf] Result: hostbyte=0x00 driverbyte=0x08
[128632.219673] sd 11:0:0:0: [sdf] Sense Key : 0x3 [current]
[128632.219682] sd 11:0:0:0: [sdf] ASC=0x11 ASCQ=0x0
[128632.219690] sd 11:0:0:0: [sdf] CDB: cdb[0]=0x28: 28 00 67 d0 99 6d 00 00 08 00
[128632.219708] end_request: I/O error, dev sdf, sector 1741724013
If this wasn愒 an USB disk, I would assume that the disk has
failed. But with USB, I惴 not so sure: can this be some sort of
problem with USB, like a connection problem?
Sometimes copying the files works just fine, sometimes not. If the
disk was actually broken, I悲 rather expect the copying to fail every
time. What might be going on here?