from:"e"

On 20120620_081652, didier gaumet wrote:
 Le Tue, 19 Jun 2012 22:33:44 -0600,
 Paul E Condon pecon...@mesanetworks.net a écrit :
 
  Thanks, but...
  
  I think I have already tried that, and I tried again just now, just to
  make sure, and again I got the standard Bad Archive Mirror
  message. That message suggests that either the archive is not
  available, or that there is not a valid Release file in it. 
 [...]
 
 Hi Paul,
 
 Your CD, being from the lenny=stable era, probably attempts to
 access stable release but it does not exists on an archive
 repository. Replacing stable by lenny could do the trick
 

Thanks, didier
This is what must be happening. And I have no way to edit an iso image
to do the replacement, so I can't use the archive to get a working
debian installation on the box and then dist-upgrade to something
more modern. Oh well ...

But now I know to stop trying, which is progress of a sort.
Again, thanks.

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120620085541.gc21...@big.lan.gnu

Re: netinst on old dell hardware

On 20120620_083247, Brian wrote:
On Tue 19 Jun 2012 at 22:33:44 -0600, Paul E Condon wrote:

On 20120620_004441, Brian wrote:

I'd put archive.debian.org for the mirror hostname.

[Snip]

I think I have already tried that, and I tried again just now, just to
make sure, and again I got the standard Bad Archive Mirror
message. That message suggests that either the archive is not
available, or that there is not a valid Release file in it. . . . . . .

I used the mini.iso from

http://archive.debian.org/debian/dists/Debian-5.0/main/installer-i386/current/images/netboot/

successfully.

Thanks, but I'm no longer confident that loading Lenny on the box will get
me closer to my larger goal, which is loading Squeeze and eventually Wheezy
on it. I had earlier tried to load Squeeze on directly but couldn't get the
screen to display anything readable, just disorganized patches of light. My
mistake was to use my trusty Squeeze businesscard CD. If I had used my Squeeze
netinst CD I would have seen different behavior. Using netinst, there is a
dialog
about how to set up the monitor drivers. Answer the questions and get a usable
image. But... At first the install goes just like many that I have done before,
until in the midst of installing the packages of the target system there is
an error message saying that it cannot install a deb called python2.6-minimal.
This package is needed for setting up some of the following packages. The
options offered are try again, or do something else. Neither path leads to
a bootable system either because there is no installed kernel or grub won't
install for lack of some essential tool. Its late at night here. I
get some rest and maybe come up the a revised project on which I can ask
for help that does me some good, rather good answers to too narrow a question.

Thanks
--
Paul E Condon
pecon...@mesanetworks.net

--
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/20120620092002.gd21...@big.lan.gnu

Re: netinst on old dell hardware

On 20120620_121804, Teemu Likonen wrote:
 Paul E. Condon [2012-06-20 02:55:41 -0600] wrote:
 
  On 20120620_081652, didier gaumet wrote:
  Your CD, being from the lenny=stable era, probably attempts to
  access stable release but it does not exists on an archive
  repository. Replacing stable by lenny could do the trick
 
  This is what must be happening. And I have no way to edit an iso image
  to do the replacement, so I can't use the archive to get a working
  debian installation on the box and then dist-upgrade to something more
  modern.
 
 Doesn't the expert install method allow editing sources.list?
 (I'm not sure.)

It allows selecting a mirror from a long list of existing mirrors and
typing in the name of an unlisted mirror, but not editing a line in
sources.list format. In this case the built in name on the CD is
surely 'stable' and *not* 'lenny', as support or named releases was
not yet fully implemented back then. Didier reminded me of that. I
think this fact pretty is a show stopper for what I was hoping to
do. I am rethinking my goals and objectives today.




-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120620200754.ga11...@big.lan.gnu

Re: netinst on old dell hardware

On 20120620_130712, Brian wrote:
On Wed 20 Jun 2012 at 03:20:02 -0600, Paul E Condon wrote:

On 20120620_083247, Brian wrote:

I used the mini.iso from

http://archive.debian.org/debian/dists/Debian-5.0/main/installer-i386/current/images/netboot/

successfully.

Thanks, but I'm no longer confident that loading Lenny on the box will get
me closer to my larger goal, which is loading Squeeze and eventually Wheezy
on it.

The goal is achievable. If other techniques don't give you a readable
screen display or lead to errors it may be the only way to go. Anyway,
there is nothing like doing it to see where you can get, so, having an
hour or two to kill this morning, here is brief set of instructions and
a description of the outcome.

1, Downloaded a Lenny netinst iso from

http://www.debian.org/releases/lenny/debian-installer/

and burnt it to a CD.

2. Booted the iso. Chose expert mode. Got to the configuring the package
manager stage and gave archive.debian.org as the mirror and /debian/
as the directory. As with the mini iso, the netinst iso contacted the
mirror, downloaded what it needed and got on with preparing for
offering to install software. I do not understand why you should have
a problem with this step because archive.debian.org is structured
like any other archive.

3. Deselected the desktop task and installed just the bare minimum.

4. Went with GRUB 2 as the boot loader to put in the MBR of the first
hard disk.

5. Booted to Lenny. Altered sources.list to point to a Squeeze archive.

Ok. Trying to repeat your work, I accomplish all steps thru 4,
but I cannot boot to Lenny. Instead I get error message :

Error: Couldn't read file
Press any key to continue...

I press a key and get:

Error: You need to load the kernel first.
Press any key to continue...

Clearly food for thoughts about debugging the hardware.
Why isn't the kernel there? I answered all questions about kernel by
accepting the offered defaults.
Ideas?

( My idea is that maybe there is not enough RAM on this box. How much
should be needed? This box has 512MB according to sticker on it from
the vendor. )

--
Paul E Condon
pecon...@mesanetworks.net

netinst on old dell hardware

2012-06-19 Thread Paul E Condon

I purchased a dell desktop pc recently intending to
use it as a untility server for things like backup
and print serving, and I am having trouble installing
Debian on it. I've been using Debian since Potato was
new, so I didn't expect difficult problems. I want to
install wheezy, since daily backup and print are services
that if they break don't cut be off from getting help
from this list, which I know that I need on a frequent
basis.

But I am already in need of help:

The Squeeze netinstall CD that I have used for several previous
installs on other hardware won't work on this hardware. It doesn't
initialize the flat screen display properly. There is a Debian swirl
but response to keyboard commands which should be screen displays on
which I type answers, or menus from which I can select options are
replaced by a jibberish of tiny rectangles, mostly empty but some
having a single tiny letter. This is a real show stopper on installing
Squeeze.  The same is true for Squeeze bizcard, and Wheezy bizcard.

But my old Lenny netinstall CD *does*work*. Now I need a repository to
point it at. I've found archive.kernel.org (I'm in USA). But I'm
having trouble composing the exact string that I need to type into the
screen on my new(to me) computer. And, I have never had a good
understanding of the magic involved in the apt-get system. I know about
the option 'enter inforation manually' in the menu of countries. 
But what do I enter there? 

And in the screen that follows asking for 'Debian archive mirror
directory:' which is prefilled with a default of '/debian/', should I
accept /debian/ or replace it? with what?

Lastly, there is a question about a proxy. I don't believe I have a
proxy, but using archive.kernel.org might necessitate one. I hope not.
Proxy?

Please help.

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120619175600.ga16...@big.lan.gnu

Re: netinst on old dell hardware

2012-06-19 Thread Paul E Condon

On 20120619_211919, keith wrote:
 On Tue, 2012-06-19 at 11:56 -0600, Paul E Condon wrote:
  I purchased a dell desktop pc recently intending to
  use it as a untility server for things like backup
  and print serving, and I am having trouble installing
  Debian on it. I've been using Debian since Potato was
  new, so I didn't expect difficult problems. I want to
  install wheezy, since daily backup and print are services
  that if they break don't cut be off from getting help
  from this list, which I know that I need on a frequent
  basis.
  
  But I am already in need of help:
  
  The Squeeze netinstall CD that I have used for several previous
  installs on other hardware won't work on this hardware. It doesn't
  initialize the flat screen display properly. There is a Debian swirl
  but response to keyboard commands which should be screen displays on
  which I type answers, or menus from which I can select options are
  replaced by a jibberish of tiny rectangles, mostly empty but some
  having a single tiny letter. This is a real show stopper on installing
  Squeeze.  The same is true for Squeeze bizcard, and Wheezy bizcard.
  
  But my old Lenny netinstall CD *does*work*. Now I need a repository to
  point it at. I've found archive.kernel.org (I'm in USA). But I'm
  having trouble composing the exact string that I need to type into the
  screen on my new(to me) computer. And, I have never had a good
  understanding of the magic involved in the apt-get system. I know about
  the option 'enter inforation manually' in the menu of countries. 
  But what do I enter there? 
  
  And in the screen that follows asking for 'Debian archive mirror
  directory:' which is prefilled with a default of '/debian/', should I
  accept /debian/ or replace it? with what?
  
  Lastly, there is a question about a proxy. I don't believe I have a
  proxy, but using archive.kernel.org might necessitate one. I hope not.
  Proxy?
  
  Please help.
  
  -- 
  Paul E Condon   
  pecon...@mesanetworks.net
  
  
 Sounds like you need to use the non graphical install option.
 
 Basically, go with the defaults offered, unless you have a specific need
 for changing anything.

I didn't request graphical install. That comes AFTER the place in the sequence
where I get to choose non-graphical or graphical. I always choose non-graphical
when I have the opportunity. The non-graphical has used Xwindows* automatically
for some time now and paints a pretty picture from the get-go. In any case, I
still would like to try to install Lenny from an archival mirror in order to
see if see if there is a way out of buying newer, more expensive hardware.

Thanks for responding.


* note: I don't know that X is involved in painting the screen graphics on
boot up from the Debian install CDs. When I think about it, X seems like
an awfully heavy weight way to paint a picture. Suffice to say I don't want
and have never selected graphical install.

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120619210328.ga21...@big.lan.gnu

Re: netinst on old dell hardware

2012-06-19 Thread Paul E Condon

On 20120620_004441, Brian wrote:
 On Tue 19 Jun 2012 at 11:56:00 -0600, Paul E Condon wrote:
 
 [Snip]
 
  But my old Lenny netinstall CD *does*work*. Now I need a repository to
  point it at. I've found archive.kernel.org (I'm in USA). But I'm
  having trouble composing the exact string that I need to type into the
  screen on my new(to me) computer. And, I have never had a good
  understanding of the magic involved in the apt-get system. I know about
  the option 'enter inforation manually' in the menu of countries. 
  But what do I enter there? 
 
 I'd put archive.debian.org for the mirror hostname.
  
  And in the screen that follows asking for 'Debian archive mirror
  directory:' which is prefilled with a default of '/debian/', should I
  accept /debian/ or replace it? with what?
 
 Accept it.
  
  Lastly, there is a question about a proxy. I don't believe I have a
  proxy, but using archive.kernel.org might necessitate one. I hope not.
  Proxy?
 
 Not necessary.

Thanks, but...

I think I have already tried that, and I tried again just now, just to
make sure, and again I got the standard Bad Archive Mirror
message. That message suggests that either the archive is not
available, or that there is not a valid Release file in it.  I have
looked at the site with iceweasel, the site is available, and a readme
says it contains Lenny, but I don't know where to look in order to
see if it contains a valid Lenny release file. I find it hard to believe
that it contains all that I see, but not a release file in the proper
place, but maybe yes. OTOH maybe its there and I didn't find and netinstCD
didn't find it as well. I've looked at the Debian archive mirror in Europe
with iceweasel and it looks to be no different than archive.kernel.org


Is there another site with Lenny files that is more accessable for use
with a netinst CD ? Maybe the archive is optimized for downloading of
individual packages, one at a time, and doesn't really understand the
way CDs are programmed to get stuff.

Ideas?

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120620043344.gb21...@big.lan.gnu

Re: Sugestions for New Releases of Debian

2012-06-09 Thread Paul E Condon

On 20120609_101334, ARAVIND CHAK wrote:
 I'm new here but presume that this will be circulated in THE Deb-LIST.

Several replys already give point-by-point answers to your post. I
want to mention that in all issues about files, their types, and where
they should be placed, it is important that you be aware of the FHS,
Filesystem Heirarchy Standard.  It is a document that is shipped with
every release of Debian that I have ever encountered and gives the
rational for most of the file placements.  I think there will be no
movement whatsoever on the part of Debian towards something else,
unless the issues raised, and decided, in FHS are addressed in a
proposal for change. Find a copy. Read it. Even if you decide to do
your own thing, it is useful to check your vision against the FHS to
be sure you haven't left anything out. Of course, you could still miss
something, but the probability is a lot less with FHS than without.

Everyone has their own vision of what traditional Debian is. Usually
that vision is the release of Debian that was current at the time they
first became Debian aware. There is a short history of Debian in
Wikipedia. I'm too new to Debian to say how good or bad that history
is, but it seems OK to me. I have long wished that someone with real
Social Science creds would study us as a counter example to the
maunderings of Ayn Rand.

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120609163714.ga9...@big.lan.gnu

Re: asm/ioctls.h in kernel headers

2012-06-08 Thread Karl E. Jorgensen

On Fri, Jun 08, 2012 at 11:24:08AM +0100, Bijoy Lobo wrote:
 Hello all,
 
 I have a Makefile which calls asm/ioctls.h, although I am faced with this
 error,
 
 /usr/include/bits/ioctls.h:24:24: error: asm/ioctls.h: No such file or
 directory

Do you have the linux-libc-dev package installed?  This package provides 
/usr/include/asm/ioctls.h ...

If you are looking for a file which should come from a debian package,
you can search for it in your already-installed packages - e.g.:

   dpkg --search /usr/include/asm/ioctls.h

for searching packages you do not (yet) have installed, try 
http://packages.debian.org under the heading Search the contents of packages 
- there are files of that name in several packages:


http://packages.debian.org/search?searchon=contentskeywords=ioctls.hmode=exactfilenamesuite=stablearch=any

Hope this helps

-- 
Karl E. Jorgensen


-- 
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/20120608104058.GA20904@hawking

Re: the ghost of UEFI and Micr0$0ft

2012-06-07 Thread Paul E Condon

On 20120607_213632, Christofer C. Bell wrote:
 On Thu, Jun 7, 2012 at 5:34 PM, Roger Leigh rle...@codelibre.net wrote:
 
  Let's be clear what this is.  I have to get *permission* from someone
  else, to run a program on my own computer.  To actually use my
  computer to do my stuff, I have to take extraordinary steps to get
  someone else to grant me access.  That's *fundamentally wrong*.
 
 No, we need to be clear that you do *not* have to get permission from
 someone else to run a program on your computer.  You can get
 permission from *yourself* by using your own signing key.  The only
 downside is that you can't distribute your custom kernel without also
 providing the signing key to whomever is going to *also use it with
 secure boot* (they are free to disable secure boot, of course, or sign
 it with their *own* key, just like you did).
 
 This new world doesn't tie you to Microsoft or any other company.
 
 -- 
 Chris

Of course, after this infrastructure is in place, people will start
discovering other uses for this identity key that 'everybody' has,
like controlling access to the internet, and neat tricks like
that. But that has nothing to do with software freedom. A self-signed
key would surely not be accepted for these new infringements of our
liberty.

I hope I haven't thought of something that is unthinkable and thereby
marked myself as an evil person in the eyes of those who are watching.


-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120608053509.gb15...@big.lan.gnu

Re: System crashes for no apparent reason

2012-06-06 Thread Karl E. Jorgensen

 15:17:01 xander /USR/SBIN/CRON[7557]: (root) CMD (   cd /  
 run-parts --report /etc/cron.hourly)
 Jun  5 16:12:35 xander dhclient: DHCPREQUEST on eth0 to 192.168.1.1 port 67
 Jun  5 16:12:35 xander dhclient: DHCPACK from 192.168.1.1
 Jun  5 16:12:35 xander dhclient: bound to 192.168.1.2 -- renewal in 
 34670 seconds.
 Jun  5 16:17:01 xander /USR/SBIN/CRON[7608]: (root) CMD (   cd /  
 run-parts --report /etc/cron.hourly)
 Jun  5 16:31:21 xander kernel: [79307.749897] [drm] nouveau 
 :01:00.0: Setting dpms mode 0 on vga encoder (output 0)
 Jun  5 17:17:01 xander /USR/SBIN/CRON[7663]: (root) CMD (   cd /  
 run-parts --report /etc/cron.hourly)
 Jun  5 18:11:30 xander kernel: [85317.130389] [drm] nouveau 
 :01:00.0: Setting dpms mode 3 on vga encoder (output 0)
 Jun  5 18:11:30 xander kernel: [85317.150673] [drm] nouveau 
 :01:00.0: Setting dpms mode 0 on vga encoder (output 0)
 Jun  5 18:11:30 xander kernel: [85317.150685] [drm] nouveau 
 :01:00.0: Output VGA-1 is running on CRTC 0 using output A
 Jun  5 18:11:30 xander kernel: [85317.324416] [drm] nouveau 
 :01:00.0: Load detected on output A
 Jun  5 18:11:31 xander kernel: [85317.551962] [drm] nouveau 
 :01:00.0: Setting dpms mode 3 on vga encoder (output 0)
 Jun  5 18:11:31 xander kernel: [85317.572244] [drm] nouveau 
 :01:00.0: Setting dpms mode 0 on vga encoder (output 0)
 Jun  5 18:11:31 xander kernel: [85317.572251] [drm] nouveau 
 :01:00.0: Output VGA-1 is running on CRTC 0 using output A
 Jun  5 18:17:01 xander /USR/SBIN/CRON[7767]: (root) CMD (   cd /  
 run-parts --report /etc/cron.hourly)
 Jun  5 18:54:21 xander kernel: [87887.751760] [drm] nouveau 
 :01:00.0: Setting dpms mode 3 on vga encoder (output 0)
 Jun  5 19:17:01 xander /USR/SBIN/CRON[7873]: (root) CMD (   cd /  
 run-parts --report /etc/cron.hourly)
 Jun  5 21:08:47 xander kernel: imklog 4.6.4, log source = /proc/kmsg 
 started.
 Jun  5 21:08:47 xander rsyslogd: [origin software=rsyslogd 
 swVersion=4.6.4 x-pid=1259 x-info=http://www.rsyslog.com;] (re)start

Pretty uneventful too... 

 If there is anything here that points to a problem, please let me know.  
 If there is any other data that would help diagnose this, I will do my 
 best to provide it.

An experiment which may exclude the video drivers from the equation:
Try NOT starting X ?  If it still crashes without X ever being
started, then it points towards the problem being elsewhere...

Another thing that may help: If you have another system on the
network, configure (r)syslog to log to the remote system.  When a
system crashes it may not be able to write logs locally, but often
network logging still works. This may allow you to capture log entries
regarding the crash itself.

To diagnose a completely dead system: Does Caps Lock work? (enough to
toggle the light)

Does it respond to Ping? (if not Ping: how about ARP?)

If it dies due to a kernel panic, you may be able to get it to
automagically reboot by adding panic=60 to the kernel command line
(will make it reboot 60 seconds after a kernel panic). Obviously this
will not solve the problem, but may make the system less unusable
while the probelm is still ongoing...

-- 
Karl E. Jorgensen
IT Operations


-- 
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/20120606093244.GH5642@hawking

Re: what did hwinfo do to my machine? - SOLVED

2012-06-06 Thread Karl E. Jorgensen

On Tue, Jun 05, 2012 at 03:29:12PM +0100, Camaleón wrote:
 
 The CSI people always say that evidence never lie. I'd say the same 
 stands for logs and messages :-)

Unless you're working with custom-written in-house applications
written by developers who unwittingly aspire to have their work
exhibited on thedailytwf.com ...

Welcome to my life.

-- 
Karl E. Jorgensen
IT Operations


-- 
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/20120606093741.GI5642@hawking

Re: Any command to control the upload bandwidth of a running program

2012-06-06 Thread Karl E. Jorgensen

On Wed, Jun 06, 2012 at 12:26:46PM +0100, J. Bakshi wrote:
 
 Dear list,
 
 I wonder if there is any linux command which can decrease / reshape
 the bandwidth usage of a running program. Say upload via scp..

This will largely be application specific - unless you want to go the traffic 
shaping route.

For scp: check out the -l option:

 -l limit
 Limits the used bandwidth, specified in Kbit/s.

Hope this helps

-- 
Karl E. Jorgensen


-- 
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/20120606115734.GJ5642@hawking

Re: ssh error - Write failed: Broken pipe

2012-05-24 Thread Karl E. Jorgensen

Hi - entering this thread late...

On Wed, May 23, 2012 at 07:46:29PM +0100, Gary Dale wrote:
 I'm connecting at various times to different Debian/Squeeze servers from 
 my Debian/Wheezy workstation using ssh. No matter which server I connect 
 to, I find that if I move a lot of data on the remote server, I get 
 kicked out of my ssh session with a Write failed: Broken pipe error.

I've seen that before and it took us ages to narrow down - in our case
(admittedly your case may be different), it was the combination of
network interface MTU and packet fragmentation.  Reducing the MTU on
our local network interface (on the server which runs the SSH client)
to 1450 (rather than the default 1500) solved it consistently:

   sudo ifconfig eth0 mtu 1450

(to make the effect permanent, tweak /etc/network/interfaces and/or
network manager config)

Unfortunately we never found the root cause of the problem: Packet
fragmentation is normally handled transparently by the TCP layer and
there were no VPNs or VLANs involved.

 This doesn't happen immediately. It usually occurs after some period of 
 time, during which time the cp or rsync command is moving data from one 
 location to another (gigabytes typically). So far as I can tell, the 
 operation finished successfully.

Interesting.

 
 This is repeatable 100% of the time.
 
 typical commands:
 cp /tmp/backups/* /media/dvd
 rsync /tmp/backups/file /media/dvd/file

Hm. These commands would not use the network - unless /tmp or /media
happen to be NFS mounted, ISCSI-backed or similar - and neither
involves ssh...

 I have even encountered it with
 if cmp /media/backupmedia/backup-set /home/shares/backup/backup-set; 
 then echo OK; fi

Hm.. this example does not involve ssh at all!?  And (apparantly) not
network either?

 although this sometimes works. I think it depends on the exact size of 
 the file. The cmp operation seems to not trigger it as fast as rsync or cp.
 
 If I'm not moving large amounts of data on the server, the ssh session 
 is stable and will sit for as long as I want. I only get disconnected 
 when I'm moving data around on the remote machine.

That is consistent with the symptoms we saw before decreasing the MTU.

Hope this helps
-- 
Karl E. Jorgensen
IT Operations


-- 
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/20120524113910.GQ17862@hawking

Re: ssh error - Write failed: Broken pipe

2012-05-24 Thread Karl E. Jorgensen

On Wed, May 23, 2012 at 08:25:20PM +0100, Gary Dale wrote:
 On 23/05/12 03:07 PM, elbbit wrote:
  On 23/05/12 19:46, Gary Dale wrote:
  This is repeatable 100% of the time.
  I get this error on my ISP.  I have found they are inspecting the
  internet packets and terminating if there is too little back-and-forth
  traffic.  My ISP is a mobile phone network over 3G so they are probably
  trying to keep the bandwidth for phones only.
 
  I do -o ServerAliveInterval=5 which has my ssh client ping the server
  every 5 seconds to keep it alive.
 
  To summarise, I get rid of broken pipe errors by using this command line
 
  ssh -o ServerAliveInterval=5 u...@server.com
 
  Hope this helps,
  elbbit
 I can try it, but as I said, I have a stable connection when I'm not 
 doing anything. I can leave an ssh shell open overnight and it will be 
 there in the morning. It's only when I'm moving bits around on the 
 remote machine that I get disconnected.

ah. I misunderstood your scenario in my previous mail... sorry.

So the ssh breakage is (somehow) triggered by moving bits around on
the remote machine only - not by moving lots of bits through the SSH
connection.

Anything in the logs on the remote machine? these files may contain relevant 
stuff:
 /var/log/syslog
 /var/log/daemon.log
 /var/log/kern.log

.. basically all of them... look for files in /var/log which were
touched around the time (or later) of the problem.

Hope this helps

-- 
Karl E. Jorgensen
IT Operations


-- 
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/20120524114601.GR17862@hawking

Re: dhclient does not recognize config file

2012-05-24 Thread Karl E. Jorgensen

Hi

On Thu, May 24, 2012 at 03:33:21PM +0100, Paul Zimmerman wrote:
 dhclient in Squeeze pays no attention to the config file at 
 /etc/dhcp/dhclient.conf

How about /etc/dhcp3/dhclient.conf ?


-- 
Karl E. Jorgensen
IT Operations


-- 
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/20120524154453.GV17862@hawking

Re: Questions about Netatalk running on Debian server

2012-05-09 Thread Paul E Condon

On 20120508_210017, Gregory Seidman wrote:
 On Sun, May 06, 2012 at 11:09:37PM -0600, Paul E Condon wrote:
 [...]
  Does anyone have netatalk 2.2.2-1 working under Wheezy?  Can you point
  me to some debugging instructions?  Or, can you lead me through some
  tests to discover what is going wrong?
 
 I have netatalk that I built from wheezy src to run on my squeeze system.
 It is serving as a Time Capsule (i.e. network Time Machine backup volume)
 for two laptops running the latest MacOS X (10.7.3 Lion).
 
 I added the following line to /etc/netatalk/afpd.conf:
 
 - -transall -uamlist uams_dhx2.so -nosavepassword
 
 I added the following lines to /etc/netatalk/AppleVolumes.default (after
 commenting out the existing Home Directory line; replace x and y
 with usernames):
 
 ==snip=
 ~/ $u allow:x,y cnidscheme:dbd options:usedots,upriv,noadouble
 
 /mnt/timemachine/tm1 TimeMachine1 allow:y cnidscheme:dbd 
 options:usedots,upriv,tm
 /mnt/timemachine/tm2 TimeMachine2 allow:x cnidscheme:dbd 
 options:usedots,upriv,tm
 ==snip=
 
 Note that /mnt/timemachine/tm[12] are mountpoints for LVM partitions. I
 also had to touch .com.apple.timemachine.supported in each of the Time
 Machine mountpoints.
 
 I don't remember if I had to modify /etc/default/netatalk, but I have these
 two lines which make sure the right servers start:
 
 CNID_METAD_RUN=yes
 AFPD_RUN=yes
 
 DHX2 seems to be the right choice for UAM. Users connect with their unix
 usernames and passwords. None of the choices are tremendously secure. See 
 the Authentication section of
 http://netatalk.sourceforge.net/2.2/htmldocs/configuration.html for
 details.
 
 Let me know if you have any further questions.
 
  Please help.
  Paul E Condon   
 --Greg

Thanks, Greg
Unfortunately for this project, it has been push down on my things-to-do
stack, by family problems. But this will surely help when I can get back
to working on this. 

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120509143105.ga3...@big.lan.gnu

Re: Questions about Netatalk running on Debian server

2012-05-09 Thread Paul E Condon

On 20120509_012529, Tom H wrote:
 On Tue, May 8, 2012 at 5:14 PM, Paul E Condon pecon...@mesanetworks.net 
 wrote:
  On 20120506_230937, Paul E Condon wrote:
 
  I have a long and troubled relation to Netatalk.  I live in a family
  where everyone else loves the Mac, and I have a need to communicate
  with them. I once had netatalk running on Debian back in 2004, I
  think, but lost that ability about the time my daughter bought her
  first MacBook in 2006. I'm revisiting the problem now using an i386
  box running Wheezy.
 
  I've installed netatalk from a Debian repository and started looking
  at /usr/share/doc/netatalk and the looking for a man page. The
  .../doc/netatalk files all date from 2010 or earlier, which is well
  before the version of netatalk in Wheezy was released. There is not
  'man netatalk', but there is a 'man netatalk.conf', and that page
  begins with:
 
   SYNOPSIS
         /etc/netatalk/netatalk.conf 
 
  But no such file was installed by the netatalk package, and I can find
  no mention of netatalk.conf at .../doc/netatalk/
 
  According to Aptitude, the version of netatalk that I installed
  is 2.2.2-1. From searching the web, I pick up statements that
  things do work in it that never worked before. But I can't see
  anything different in the documentation. I remember that, when I
  did have it working long ago, I didn't have to do anything in
  order to have it advertise its services and to have it actually
  serve files. My problems then were with serving a printer. Now I
  use CUPS for that. But I don't see my Macs picking up an advert.
  (They do pickup adverts from one of the Macs, so I know that they
  are listening.)
 
  So, my questions:
 
  Does anyone have netatalk 2.2.2-1 working under Wheezy?  Can you point
  me to some debugging instructions?  Or, can you lead me through some
  tests to discover what is going wrong?
  I posted this, below, a couple of days ago. I'm hoping to find someone
  who follows this list and who actually has netatalk v. 2.2.2-1
  installed from the Debian package in Wheezy. I would very much like to
  get it working, but ... I can't. All the documentation that I can find
  is two or more years old, and does not pertain to the packaged
  version.
 
  P.S. Thanks Tom, but I need more than the fact that
  /etc/netatalk/netatalk.conf once existed as part of an earlier version
  of the package. It may still be part of a properly configured
  netatalk, but it doesn't seem to be included in this package.
 
 Please bottom-post.
 
 You misunderstood. I said that I remember that the config files on
 Debian are /etc/default/netatalk and /etc/netatalk/afpd.conf.
 Perhaps I should've also said that I remember
 /etc/netatalk/netatalk.conf to be the Fedora equivalent of
 /etc/default/netatalk.

Thanks, Tom.

I certainly did misunderstand, and calling it to my attention is much
appreciated. I my defense, I note that the package does add to the man
pages a page for netatalk.conf, and that man page does say it is
located in /etc/netatalk/, which begs the question, What is a default?
In other places than Debian, default behavior of a program is the way
it behaves if there is not a configuration file. Live and learn.

Thanks.

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120509145312.gb3...@big.lan.gnu

Re: Re: MySQL 4.0 (sarge) -- MySQL 5.0 (etch) -- Please do REPAIR TABLE

2012-05-09 Thread Karl E. Jorgensen

Hi

On Wed, May 09, 2012 at 08:04:11AM +0100, Rajeev tyagi wrote:
 Dera Tech,
 
 
 i m not able to see innodb table on mysql database can you pls help me out

Difficult to help without more details

How are you attempting to see the table? (e.g. what SQL statement?)

Which error do you get?


-- 
Karl E. Jorgensen
IT Operations


-- 
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/20120509183547.GH8503@hawking

Re: emacs extensions

2012-05-08 Thread Cláudio E. Elicker

On Tue, 8 May 2012 17:45:35 -0300
Paulo Rodriguez rodriguez.sioux.s...@gmail.com wrote:

 Olá,
 Alguém tem alguma indicação de sites onde as pessoas publicam
 extensoes para o emacs?


Principalmente esse:
  http://www.emacswiki.org/

E depois:
  http://emacs-fu.blogspot.com.br/
  http://www.masteringemacs.org/
  http://planet.emacsen.org/
  http://emacsworld.blogspot.com.br/
  http://www.dotemacs.de/
  http://emacs.wordpress.com/
  http://emacsblog.org/
  http://xahlee.org/emacs/blog.html

-- 
EMACS is my operating system; Linux is my device driver.


--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120508185233.70cda036@yeh1.parsec

Re: Questions about Netatalk running on Debian server

2012-05-08 Thread Paul E Condon

I posted this, below, a couple of days ago. I'm hoping to find someone
who follows this list and who actually has netatalk v. 2.2.2-1
installed from the Debian package in Wheezy. I would very much like to
get it working, but ... I can't. All the documentation that I can find
is two or more years old, and does not pertain to the packaged
version.

Surely someone is using this package. Please speak up.

Paul

P.S. Thanks Tom, but I need more than the fact that
/etc/netatalk/netatalk.conf once existed as part of an earlier version
of the package. It may still be part of a properly configured
netatalk, but it doesn't seem to be included in this package.

On 20120506_230937, Paul E Condon wrote:
 I have a long and troubled relation to Netatalk.  I live in a family
 where everyone else loves the Mac, and I have a need to communicate
 with them. I once had netatalk running on Debian back in 2004, I
 think, but lost that ability about the time my daughter bought her
 first MacBook in 2006. I'm revisiting the problem now using an i386
 box running Wheezy.
 
 I've installed netatalk from a Debian repository and started looking
 at /usr/share/doc/netatalk and the looking for a man page. The
 .../doc/netatalk files all date from 2010 or earlier, which is well
 before the version of netatalk in Wheezy was released. There is not
 'man netatalk', but there is a 'man netatalk.conf', and that page
 begins with:
 
  SYNOPSIS
/etc/netatalk/netatalk.conf 
 
 But no such file was installed by the netatalk package, and I can find
 no mention of netatalk.conf at .../doc/netatalk/
 
 According to Aptitude, the version of netatalk that I installed
 is 2.2.2-1. From searching the web, I pick up statements that
 things do work in it that never worked before. But I can't see
 anything different in the documentation. I remember that, when I
 did have it working long ago, I didn't have to do anything in
 order to have it advertise its services and to have it actually
 serve files. My problems then were with serving a printer. Now I
 use CUPS for that. But I don't see my Macs picking up an advert.
 (They do pickup adverts from one of the Macs, so I know that they
 are listening.)
 
 So, my questions:
 
 Does anyone have netatalk 2.2.2-1 working under Wheezy?  Can you point
 me to some debugging instructions?  Or, can you lead me through some
 tests to discover what is going wrong?
 
 Please help.
 -- 
 Paul E Condon   
 pecon...@mesanetworks.net
 
 
 -- 
 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/20120507050937.gb29...@big.lan.gnu
 

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120508211434.ga31...@big.lan.gnu

Questions about Netatalk running on Debian server

2012-05-06 Thread Paul E Condon

I have a long and troubled relation to Netatalk.  I live in a family
where everyone else loves the Mac, and I have a need to communicate
with them. I once had netatalk running on Debian back in 2004, I
think, but lost that ability about the time my daughter bought her
first MacBook in 2006. I'm revisiting the problem now using an i386
box running Wheezy.

I've installed netatalk from a Debian repository and started looking
at /usr/share/doc/netatalk and the looking for a man page. The
.../doc/netatalk files all date from 2010 or earlier, which is well
before the version of netatalk in Wheezy was released. There is not
'man netatalk', but there is a 'man netatalk.conf', and that page
begins with:

 SYNOPSIS
   /etc/netatalk/netatalk.conf 

But no such file was installed by the netatalk package, and I can find
no mention of netatalk.conf at .../doc/netatalk/

According to Aptitude, the version of netatalk that I installed
is 2.2.2-1. From searching the web, I pick up statements that
things do work in it that never worked before. But I can't see
anything different in the documentation. I remember that, when I
did have it working long ago, I didn't have to do anything in
order to have it advertise its services and to have it actually
serve files. My problems then were with serving a printer. Now I
use CUPS for that. But I don't see my Macs picking up an advert.
(They do pickup adverts from one of the Macs, so I know that they
are listening.)

So, my questions:

Does anyone have netatalk 2.2.2-1 working under Wheezy?  Can you point
me to some debugging instructions?  Or, can you lead me through some
tests to discover what is going wrong?

Please help.
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120507050937.gb29...@big.lan.gnu

Re: unix tool as precise counter/timer for periodic print/exec

2012-05-02 Thread Karl E. Jorgensen

On Wed, May 02, 2012 at 09:20:11AM +0100, Johannes Schauer wrote:
 Hi,
 
 I'm looking for a unix tool that does nothing else than increment and
 print an integer with a fixed frequency. As a bonus it should be able to
 execute a command with a fixed frequency. The special requirement: it
 should precise in the interval.
 
 Thus, the following will not work:
 
   #!/bin/sh
   while true; do
   print_counter
   sleep 1
   done
 
 because each loop iteration will take one second plus how long
 print_counter takes to execute.

Perhaps the sleepenh package will help you?

Not a solution per se, but possibly a useful building block..


 What I need is something that on each step recalculates how long to
 sleep based on the current time so that the overall frequency remains
 stable.
 
 I do not need each print_counter to be executed exactly at a very
 precise moment but just that the overall frequency stays the same. After
 having it run 1000 times with a frequency of 1Hz I want 1000 seconds to
 have passed.
 
 Some libraries like glib provide functions like g_timout_add or
 g_timeout_add_seconds but that does not 'catch up' as I require above.
 Is there some library that does?
 
 There is the watch(1) tool which already partly does what I want using
 the --precise switch. But it runs in fullscreen and even when using
 --precise, it will not compensate for commands that take longer than the
 given interval length as it doesnt fork them. Also, watch(1) will not
 allow intervals smaller than 0.1 seconds.
 
 So basic requirement: print a counter (counting up or down) in a fixed
 frequency. Either a tool that does that or a library that I can use to
 code it.
 
 Bonus: execute a command with a fixed frequency and in contrast to
 watch(1) even when executing the command takes longer than the interval.
 
 So is there a utility that just implements a simple, precise counter?
 
 Is there a better version of watch(1) that is not fullscreen, allows
 faster than 0.1 second intervals and forks the application so that their
 runtime can exceed the interval time?



-- 
Karl E. Jorgensen
IT Operations


-- 
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/20120502135713.GM18412@hawking

Re: unix tool as precise counter/timer for periodic print/exec

2012-05-02 Thread Paul E Condon

On 20120502_102011, Johannes Schauer wrote:
 Hi,
 
 I'm looking for a unix tool that does nothing else than increment and
 print an integer with a fixed frequency. As a bonus it should be able to
 execute a command with a fixed frequency. The special requirement: it
 should precise in the interval.
 
 Thus, the following will not work:
 
   #!/bin/sh
   while true; do
   print_counter
   sleep 1
   done
 
 because each loop iteration will take one second plus how long
 print_counter takes to execute.
 
 Even the following will not work:
 
   #!/bin/sh
   while true; do
   print_counter 
   sleep 1
   done
 
 Because even the time it takes to fork print_counter will accumulate
 over time.
 
 Another inconvenience of the above is, that not all sleep(1)
 implementations do accept floating point arguments to run the above
 faster than every second.
 
 What I need is something that on each step recalculates how long to
 sleep based on the current time so that the overall frequency remains
 stable.
 
 I do not need each print_counter to be executed exactly at a very
 precise moment but just that the overall frequency stays the same. After
 having it run 1000 times with a frequency of 1Hz I want 1000 seconds to
 have passed.
 
 Some libraries like glib provide functions like g_timout_add or
 g_timeout_add_seconds but that does not 'catch up' as I require above.
 Is there some library that does?
 
 There is the watch(1) tool which already partly does what I want using
 the --precise switch. But it runs in fullscreen and even when using
 --precise, it will not compensate for commands that take longer than the
 given interval length as it doesnt fork them. Also, watch(1) will not
 allow intervals smaller than 0.1 seconds.
 
 So basic requirement: print a counter (counting up or down) in a fixed
 frequency. Either a tool that does that or a library that I can use to
 code it.
 
 Bonus: execute a command with a fixed frequency and in contrast to
 watch(1) even when executing the command takes longer than the interval.
 
 So is there a utility that just implements a simple, precise counter?
 
 Is there a better version of watch(1) that is not fullscreen, allows
 faster than 0.1 second intervals and forks the application so that their
 runtime can exceed the interval time?
 
 cheers, josch

Don't use sleep, or any of the loop structures that you discuss above.
Use crontab (see man crontab). This is not the /etc/crontab that drives
some system services, but the one that provides a crontab for each user
Typing

crontab -e return

in an xterm, will get you started, but perhaps you should read the man
page first. Your crontab file will be created automagically in /var
where the system expects it to be. 

I think you should be careful to not set the schedule to execute you
job too frequently. This system will launch a new job on schedule,
whether or not the previously launched job has completed. For some
jobs this can cause problems. If you want to do something that takes 1
or 2 sec., every 5 sec., crontab works without using locks on files,
or other safety mechanisms. Or look at the package liblockfile1.


-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120502143339.gb13...@big.lan.gnu

Re: How do I remove a bad file??

2012-05-02 Thread Paul E Condon

On 20120501_204601, John L. Cunningham wrote:
 
 On Tue, May 01, 2012 at 06:20:11PM -0500, Dennis Wicks wrote:
  Greetings;
  
  I have a file that looks like the following in an ls list;
  
  -? ? ?? ?? Inbox.msf
  
  I can't do anything with it. Can't mv, rm, cp, or anything else I
  have thought of to get rid of it or write over it.
  
  Any ideas how I can get this thing out of my life??
 
 If there is no GUI available, this trick using find and the file's inode 
 number will work:
 
 http://www.cyberciti.biz/tips/delete-remove-files-with-inode-number.html
 

To OP:

Use find to do the whole job:
1. cd into the directory in which the file with the bad name is lodged,
2. find . -maxdepth 1 -ls
3. look at output and add restrictions to the search criteria of find, 
4. repeat 2. until the bad file is the only one found. Then go to 5.
5. add -delete to the end of the find command that was developed by the 
   above, and run it.

You might want to skim the find man page to see what -maxdepth does.
I would add a test that the file name not have an initial letter that
is the same as the initial letter of any good file in the directory.

! -name '[a-zA-Z0-9]*' 

This should make pretty much everything but your bad file drop out of
the find output. If not tweak the find command some more, but don't
add the -delete until the bad file is the only one present in the trial
runs. Don't assume that you know the regular expression rules. Find has
its own regex rules. They are similar to other regex, but for cleanup
work like this, the game of not adding the delete until you are sure
the the whole of the command is right is a strategy that will save you
from a lot of grief.  

But if you don't have .history working in your xterm, all of this is
largely worthless. Don't try it with the find command and changes to
it are recorded with pencil on a note pad!!! 

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120502135208.ga13...@big.lan.gnu

Re: remote mysql is too slow

2012-04-13 Thread Karl E. Jorgensen

On Wed, Apr 11, 2012 at 09:23:09PM +0100, Bob Proulx wrote:
 Karl E. Jorgensen wrote:
  Bob Proulx wrote:
   But at some point the daemon is going to need to write a file to disk.
   That data will get cached at that time.  Or are you saying that mysql
   is using or should using O_DIRECT and avoid the cache explicitly?
  
  No - although that might help (marginally) too.  The point is that
  caching of data in MySQL will be more efficient than caching in the
  kernel disk cache; less layers and whatnot.
 
 The point I was trying to make (and apparently failing miserably) is
 that unless the mysql daemon is really trying hard to avoid it then as
 soon as it writes a file it will end up in the filesystem buffer
 cache.

ah. The miserable failing was at the receiving end - sorry :-)

 In any case, from the original 'free' output it isn't possible to know
 if the filesystem buffer cache is due to mysql or due to other
 activity across the filesystem.  Such as backup for example.  It could
 have come from any other activity.  There could be files being copied
 to or from the system.  Could be anything.

Agreed

 Normally filesystem buffer cache is a good healthy indication.
 Because if the operating system becomes starved for memory it will
 free filesystem buffer cache in order to obtain it.  If a system has
 no files cached and lots of truly free ram it may indicate that some
 process is frequently consuming a lot of memory, forcing all buffers
 to be flushed, and then exiting causing that memory to be free memory.
 Free memory as opposed to working-for-you memory in the buffer cache.
 Normally I would say memory used for filesystem buffer cache is good
 healthy use of the memory.  And when I say normally here I am not
 talking about a database daemon which will of course have special
 needs.

Definitely special needs.

-- 
Karl E. Jorgensen
IT Operations


-- 
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/20120413144316.GG11957@hawking

Re: remote mysql is too slow

2012-04-11 Thread Karl E. Jorgensen

On Wed, Apr 11, 2012 at 07:18:18AM +0100, Bob Proulx wrote:
 Karl E. Jorgensen wrote:
  Jumping back in (late) in this thread...
  Bob Proulx wrote:
# free -m
 total   used   free sharedbuffers 
cached
Mem:  7986   7913 73  0224   
6133
-/+ buffers/cache:   1554   6431
Swap: 3813  0   3813
   
   Shows 8G of ram.  Good.  Shows no swap used.  Also good.  (But not
   necessarily bad if some swap is used.  So if you see some swap being
   used that isn't necessarily a problem.)
  
  Mostly good. Yes. But 6133 Mb Cached is not what I would expect - this
  indicates that the linux kernel is doing the caching - rather than
  MySQL. And the MySQL cache for this stuff is (almost) always more
  efficient.
 
 But at some point the daemon is going to need to write a file to disk.
 That data will get cached at that time.  Or are you saying that mysql
 is using or should using O_DIRECT and avoid the cache explicitly?

No - although that might help (marginally) too.  The point is that
caching of data in MySQL will be more efficient than caching in the
kernel disk cache; less layers and whatnot.

-- 
Karl E. Jorgensen
IT Operations


-- 
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/20120411145523.GE30103@hawking

Re: remote mysql is too slow

2012-04-10 Thread Karl E. Jorgensen

Jumping back in (late) in this thread...

On Mon, 2012-04-09 at 19:51 +0100, Bob Proulx wrote:

 J. Bakshi wrote:
  Karl E. Jorgensen wrote:
   J. Bakshi wrote:
I have been provided a muscular linux server to use as a Mysql server
in our organization. The server is located just beside the web server
and within the same network. This dedicated server has 8GB RAM, i5 
processors
and running mysql as service. No apache, php . nothing. All 
resources are
dedicated to mysql only.
 
 That does sound big and muscular and should do a good job of providing
 database services.
 
The BIG hitch is; when we connect with this box the web sites become 
too slow.
 
 Unfortunately subjective descriptions such as too slow are not
 useful descriptions.  One person's very fast is another person's too
 slow.  Objective benchmark data is needed in order to make forward
 progress.  Also when you change something to improve the performance
 if you don't know how much you changed things you might actually make
 something worse without knowing it.
 
 The other suggestions that people gave you were good.  They were
 better than anything I could suggest about mysql specifically.  But
 for performance tuning in general I strongly recommend that you use or
 create a benchmark that illustrates the type of operation you are
 trying to optimize.  Benchmarks are best when they can be shared with
 other people so that they can recreate your environment.  It might be
 useful to create a benchmark using synthetic data (created fake data)
 so that others can share your environment and recreate it.
 
 Then collect data on that benchmark.  Then make performance tuning
 changes.  Then run the benchmarkmark again and determine if your
 change improved things and if so by how much.
 
The sql connection becomes little faster but still it is considerably
slow; specially with such a muscular dedicated linx box just for Mysql.
Is there anything else which I can add/configure to make the network 
latecy
small or any such mechanism to make the query fast ?
 
 Please show us data that tells us how slow is slow and how fast is
 fast.
 
 I am not a mysql performance expert.  I won't be able to help too
 much.  Sorry.  But I can tell you that if you don't have actual data
 on the existing performance then you also won't know if you have
 improved it or if you have made it worse or if you haven't changed
 anything.  Benchmarking when performance tuning is critically
 important.
 
  # free -m
   total   used   free sharedbuffers cached
  Mem:  7986   7913 73  0224   6133
  -/+ buffers/cache:   1554   6431
  Swap: 3813  0   3813
 
 Shows 8G of ram.  Good.  Shows no swap used.  Also good.  (But not
 necessarily bad if some swap is used.  So if you see some swap being
 used that isn't necessarily a problem.)


Mostly good. Yes. But 6133 Mb Cached is not what I would expect - this
indicates that the linux kernel is doing the caching - rather than
MySQL. And the MySQL cache for this stuff is (almost) always more
efficient.

If you use InnoDB tables, you can increase innodb_buffer_pool to e.g.
4Gb more.

If are using MyISAM tables, increase key_buffer_size (affects caching of
indexes) and probably others - I don't use MyISAM tables much...



 
  # vmstat 5 10
  procs ---memory-- ---swap-- -io -system-- 
  cpu
   r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id 
  wa
   0  0  0  56328 230440 629967600257466  0  0 98 
   2
   0  0  0  55700 230440 629974400 022  226  272  0  0 99 
   1
   0  0  0  55964 230440 629985600 0   314  348  388  0  0 94 
   5
   0  0  0  55452 230440 629995600 061  304  364  0  0 97 
   2
   0  1  0  55592 230440 630042400 0   271  199  257  0  0 96 
   4
   0  0  0  54584 230440 630090800 0   338  342  428  0  0 92 
   8
   0  0  0  54800 230440 630107200 077  119  133  0  0 98 
   2
   0  0  0  53964 230440 630153200 0   617  267  327  0  0 95 
   4
   0  0  0  54468 230440 630154400 0   296  119  116  0  0 99 
   0
   0  0  0  54212 230440 630164800 0   183  361  435  0  0 95 
   4
 
 The 'si' and 'so' fields show zero swap-in / swap-out rate.  That is
 good.  A very low rate of 1 or 2 also would not be a problem.  When
 machines start to swap excessively you will see rate numbers like 10
 or 20 in that field and that would be a bad indication.
 
 Bob

Re: [OT] Posting styles

2012-04-08 Thread Paul E Condon

On 20120407_143810, Robert Holtzman wrote:
 On Sat, Apr 07, 2012 at 09:21:44AM -0500, Indulekha wrote:
  In linux.debian.user, Richard rich...@g8jvm.com wrote:
   On Sat, 7 Apr 2012 14:02:12 +0300
   Mika Suomalainen mika.henrik.mai...@hotmail.com wrote:
  
   The other thing Mika, apart from that huge chunk of signature, why on
   earth ask for a return receipt.
  
  It does tend to announce to the recipient that the sender has 
  a wildly exaggerated sense of self-importance, which I suppose 
  could be construed as useful. :)
 
 Because I damned well want to is a perfectly valid reason for signing
 emails/posts. The level of judgementalism (yeah, I know it's not a word

I judge that 'judgementalism' is a perfectly fine English word. Prior
to yesterday, it maybe hadn't yet been invented. Now that it has been
invented, who can doubt what its meaning is?

This is the magic of a living natural language. People understand it
'intuitively'. 


-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120408225319.ga10...@big.lan.gnu

Re: Problems in fonts in console appear again (and rant on /etc/default) in re. the rant

2012-04-07 Thread Paul E Condon

On 20120407_111413, Brian wrote:
 On Fri 06 Apr 2012 at 21:45:00 -1000, Joel Roth wrote:
 
  On Sat, Apr 07, 2012 at 12:48:35AM +0100, Brian wrote:
   
   And run 'setupcon' after making the changes?
  
  This works for me. :-)  
  
  I never had thought about configuring the console before.
  
  My issue had been 80-character fonts for GRUB, then tiny
  fonts (132 columns?) after boot.  
  
  32x16 is a good size for me, however Terminus is squarish,
  uglier than the default font IMO.
 
 It's a matter of taste but I'm inclined to agree with you. However, you
 can get used to them if you use the console a lot, and I don't think
 there is anything else easily available if you want a decent sized font.
 
 Have a look at the use of a VARIANT for quickly changing font size on a
 particular terminal. The setupcon manual explains it well.
 
  OT RANT: Debian's use of /etc/default drives me nuts!
 
 Welcome to the land of a 1001 configuration files.

I like Debian's attempt to address default configuration in an
organized way, but ...

All defaults, including configuration defaults, have an implicit
domain of applicability. A default applies here (unstate assumed
domain of applicability), but not there (also unstated).

Some defaults are intended to hold only for a particular host.
Some hold for a particular LAN.
Some hold for an organization, like for instance, Debian, itself.
Some hold for the Debian package system as distinct from the Debian 
organization.

Not all defaults are configuration, but those that are configuration
must be fully disambiguated before a computer code can be
executed. All this stuff about default configuration is an extention
of the work that a linkage editor does. It must be done but it is too
detail oriented to be done without computer automation support. Real
programmers cannot code successfully in octal.
 
I repeat. I like defaults. I like Debian. But Debian is an unfinished
business, which will never be finished until after our civilization
has collapsed some time far in the future. There will always be a next
release under development and a better idea for how to do something
that some people think was absolutely decided long ago. The UNIX plan
has stood the test of time and survives, but the details of
implementation, not so much.

My suggestion for configuration stuff: 

Have the /usr/share/docs/something directory include a complete list
of the places where the something package puts stuff with a notation
for each item as to whether the maintainer believes it is
configuration, or not. This list file might even be generated by a
script and serve the maintainer as a useful check list. An exhaustive
list, even without maintainer notation could be a change that will
stand the test of time, IMHO.  With such lists, each Debian maintainer
can examine compare his/her usage pattern against the usage pattern of
all packages in Debian and perhaps maintain some sense of balance
about how and where, etc.

I like talking about the big picture. It is so much easier than
sweating the details of getting a program to work. Especially if I
can't find configuration files or don't even know that they
exist. ;-)

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120407140948.ge5...@big.lan.gnu

Re: remote mysql is too slow

2012-04-05 Thread Karl E. Jorgensen

Hi

On Thu, 2012-04-05 at 08:13 +0100, J. Bakshi wrote:

 Hello,
 
 I have been provided a muscular linux server to use as a Mysql server
 in our organization. The server is located just beside the web server
 and within the same network. This dedicated server has 8GB RAM, i5 processors
 and running mysql as service. No apache, php . nothing. All resources are
 dedicated to mysql only.
 
 Mysql version - mysql  Ver 14.14 Distrib 5.1.49, for debian-linux-gnu (x86_64)
 
 The BIG hitch is; when we connect with this box the web sites become too slow.
 I have added the following at my.cnf under [mysqld] section
 
 ` ` ` ` `
 skip_external_locking
 skip_name_resolve
 skip_host_cach
 
 ` ` ` ` ` `
 
 
 The sql connection becomes little faster but still it is considerably
 slow; specially with such a muscular dedicated linx box just for Mysql.
 Is there anything else which I can add/configure to make the network latecy
 small or any such mechanism to make the query fast ?


Although you say all resources are dedicated to mysql only, I guess
they're not.

First step: run mysqltuner - this will give some rough recommendations
which will usually point people in the right direction.  Beware that
mysqltuner will always recommend setting innodb_buffer_pool_size big
enough to keep all InnoDB tables in memory - which is usually overkill.

if vmstat reports that CPU usage is low, and disk IO is low, this
points towards locking contention - which is entirely application
dependent. Hope you haven't used MyISAM tables when you intended to use
InnoDB tables :-)

if vmstat reports high cpu usage, and low disk IO, then the database
is probably in memory, and you need to look at one or more of:

  * queries scanning lots of rows (e.g. missing indexes)
  * for InnoDB tables: if innodb_buffer_pool is too small, but the
server has lots of memory, the linux kernel will cache disk
blocks rather than MySQL doing it. Which translates to high CPU
load and lots of cache hits. But in this case it is more
efficient to let MySQL do the caching rather than the kernel.

 
 The server has very little load as observer from top and iostat
 even during peak hours.
 
 Thanks
 
 


attachment: face-smile.png

Re: how to increase space for tmpfs /tmp

2012-04-03 Thread Paul E Condon

On 20120402_234538, Stan Hoeppner wrote:
 On 4/2/2012 9:43 PM, Paul E Condon wrote:
 
  This is the du command and results:
  root@gq:/# du -k -s -c /[^pm]* /m[^e]*
 
  4   /home
 
 Is your /home empty?  Your du command seems to think so.  That's hard to

Yes. It was empty at the time at which the du command was run. The
normal contents of /home had been moved to /mpb2.  I say where the
/home stuff is in the post to which you replied. When I did the move,
I had no idea that I was going to find this puzzle, but I do recall
thinking that the move went very fast, too fast for there to be much
data in /home.

 believe.  It would mean you ever created any users.  A newly created
 empty dir has a size of 4KB.

At 4KB per extra user, it would take over 12000 extra users to account
for the missing extra space. I don't think I could have created that
many users and not remember. And I don't remember doing such a wild
thing. And the directories are not there. So I probably didn't do it.
And if they were there, du would have found them and counted them.

 
  0   /initrd.img
  0   /initrd.img.old
  0   /vmlinuz
  0   /vmlinuz.old
 
 How are these files occupying 0 KB of disk?

That is part of my problem. The disk seems to be corrupted.

 
  20  /mpa2
  20  /mpa3
  4   /mpb1
 
 Do these 3 dirs you created really only contain 44 KB total?
 
  Why the disagreement between df and du ? How is it possible?
 
 See the discrepancies above?  Your du isn't reflecting reality of what's

Yes, I see them. I made my post because I saw them and wanted help in
explaining them. But how can you conclude that it is du that is wrong?

 on disk.  And the issue isn't sparse files as that would cause du to
 show you're full but df would say you have tons of actual on disk free
 space.
 
 It seems clear that your ext3 / filesystem is actually full.  You are

All the numbers from du are consistent with my memory of what was on the
disks. A lot of empty space. Only the disk full indication from df is
surprising to me. It is an 80GB disk with Wheezy and no Xwindows or Gnome
on it, and only a skeleton /home. Clearly the info from df and du are
incompatible. Could you explain why you conclude it is du that is wrong?
It is a Wheezy root disk, which in my experience should contain no more
than 5 or 6 GB in my experience.

 actually using 54282104 blocks.  Go through your directories manually to
 find the files that are eating up that other 15/16ths of your partition.

Isn't that what du automates? Traversing a directory tree and tallying
the space used. Before this experience I would have trusted running du
far more than any manual operation that I performed. If 15 parts out 16
is stuff that shouldn't be there, I would expect a random peek would
have high probability of seeing the bad stuff immediately. But no,
I don't see anything but stuff that is on pretty much any Debian box.


  Given the space in question, I'd say you may likely have some
 downloaded ISOs, or other large files, probably in your /home/paul/
 directory. 

I am quite certain that I have never downloaded .ISOs onto this computer.
I have been using this computer for development and data processing. I burn my 
CDs
on a different computer. I know how I organize my /home on any computer.
On this computer, the place where I normally put large files is unpopulate,
or, perhaps hidden from view by some strange malfunction. But do you actually
see in what I presented, a reason for choosing to believe the df display and
not believe the du display. What reasoning did you go thru? I'm trying to 
learn. And I need help on this.

But just because I'm sure I haven't put large files on this disk,
don't conclude that I have refused to look for them. Because of your
comments, I have looked again. I see nothing that is amiss. Except, of
course, the two programs, df and du don't agree. I suppose I could just
wipe the disk and start over. But I don't want to do that. I'd like to
understand what went wrong so that maybe I can avoid it in future.

Thanks for your comments.
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120403080855.ga17...@big.lan.gnu

Re: how to increase space for tmpfs /tmp

2012-04-03 Thread Paul E Condon

On 20120403_101348, Roger Leigh wrote:
 On Tue, Apr 03, 2012 at 09:59:39AM +0100, Dom wrote:
  I'd try bringing the system up in recovery mode, unmount all ext3
  file systems (except /, obviously) and run the du command again. You
  might find data that was concealed under the mount points.
 
 It's even possible that it's under /tmp.

Some issues with some suggestions:

1) If the data is actually there, it is obviously on my rootfs (/) which
I obviously can't examine in recovery mode. Or can I examine it by some
trickery that someone will tell about?

2) I used mv to move the data, from past experience I judged the execution
time of mv to be consistent with the same about of data the showed up on
/mpb2 according to du.

3) Stan says that the disk is full and that du is just wrong. I say that
'obviously' the outputs of df and du disagree, and with the possibility
of there being some corruption of magnetic marks of disk, it is difficult
to say which report is closer to the truth. How does one decide? Beyond
choosing the one that better fits ones expectations and desires? (wishful
thinking)

4) I started making proparations to wipe and reinstall on the problem computer.
To do that I was working on an entirely different computer (the one on which I
read my mail). I wanted to clean up some partitioning there. This other computer
is running Squeeze. I installed kpartx, tried to use it, and got a real 
surprise:

root@big:~# kpartx -l /dev/sda
/proc/misc: No entry for device-mapper found
Is device-mapper driver missing from kernel?
Failure to communicate with kernel device-mapper driver.
sda1 : 0 39061504 /dev/sda 2048
sda2 : 0 39061504 /dev/sda 39063552
sda4 : 0 894738434 /dev/sda 82032638
sda5 : 0 894738432 /dev/dm-2 2
root@big:~# 

I have never thought about the question being ask in the error message.
I have no idea what the 'good' answer should be for a Debian built 
kernel. I do have backups of all my data and highish speed access to
the internet. Perhaps I should take a deep breath and reinstall all three
of my computers. This course of action will take a long time, and it will
keep me from asking (or answering) questions on this list for a long time.

Is device-mapper driver a standard part of all Debian kernels?  Is df
really more to be trusted than du when used on a disk that could have
become corrupted? The original problem computer continues to limp
along. It doesn't issue error messages. But that is hardly a reason
for believing it is all OK. As I understand du, it works by walking
the directory tree and tallying the space used by all the objects that
it finds. The -s option only affects how verbose it is in reporting
what it has found. In other words, if du doesn't find something on a
disk, why should one search manually and expect to find something that
it missed. Maybe I should look for something that absolutely should
not be there and is a clue about what made the disk 'go south'?


Advice?
Comment?
Thanks for reading this.
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120403181822.ga22...@big.lan.gnu

Re: how to increase space for tmpfs /tmp

On 20120402_043958, Tom H wrote:
 On Sun, Apr 1, 2012 at 2:52 PM, Paul E Condon pecon...@mesanetworks.net 
 wrote:
  On 20120401_130449, Andrei POPESCU wrote:
  On Sb, 31 mar 12, 11:08:39, Paul E Condon wrote:
 
  Having a tmpfs filesystem for /tmp doesn't mean that a dedicated
  partition is required for /tmp.
 
  What you say doesn't work for me, but something else does.
 
  Show us (what doesn't work) :)
 
  My statement was made in response to a statement by another person
  whose name you have snipped out. It is just as well that you did this
  snipping, because, now I regret writing precisely that in response to
  that remark.
 
  What *does* work for me is a separate partition for /tmp, which is
  something that I never had to have before. Having to set up such as
  part of a dist-upgrade, or full-upgrade, or re-install breaks the 'it
  just works' paradigm. I think it was not really working in squeeze as
  well, but until quite recently, I was unaware of the meaning of some
  error messages and unable to design and execute diagnostic to tests, or
  to formulate questions that would evoke helpful explanations. (You do
  realize by now that I do have communication problems, I hope.)
 
 I gave up on this thread when I saw the cryptic and useless What you
 say doesn't work for me, but something else does but now that you've
 explained what you think works, I have to add that you've made very
 little sense throughout this thread and that your problem cannot have
 been the migration of /tmp to tmpfs.
 
 If your server could run in the past with /tmp as a directory on
 /, it cannot be that setting RAMTMP=no in /etc/default/rcS
 wouldn't solve whatever (hopefully non-philosophical) problem you have
 with /tmp as a tmpfs mount. You must have a new or upgraded
 application that's using /tmp differently, or are using the system
 differently.

Regret.
Peace.
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120402134501.gl3...@big.lan.gnu

Re: how to increase space for tmpfs /tmp

On 20120402_143034, Roger Leigh wrote:
 On Fri, Mar 30, 2012 at 02:12:03PM -0600, Paul E Condon wrote:
  It is my understanding that the directory that one wishes to use in
  TMPDIR must be mentioned in a line in /etc/fstab for this to work, and
  a block special mountable device must be mentioned in that line.
 
 This understanding is incorrect.  TMPDIR is just an environment
 variable which may be set to any directory of your choice, which
 will then be used as the default place to put temporary files.
 It does not care about fstab or any other settings.
 
  And
  this is the way it does work on my system. Choise of TMPDIR did not
  have this restriction in the past. This change has implications for
  many packages.
 
 I sincerely doubt it does work this way on your system.  There has
 not, and will not be, any change to TMPDIR.  Not least of which it
 being an application-level feature typically used by functions
 opening/creating temporary files, none of which have been changed.
 What is or is not mounted on /tmp will not make one jot of
 difference.
 
  My point is that competent developers should check this
  out.
 
 I will be happy to investigate upon better understanding of what
 this actually is.  It will need some concrete information though,
 including exact details of how to reproduce any problems, and it
 should also show it's something that was working in stable, otherwise
 it's not a related issue.  I'll need to know what you did, what you
 observed and what you expected; currently you haven't provided any
 useful information.
 
 Just for the record, when these changes were introduced (nearly a
 year ago, BTW), I extensively tested with *all* combinations of
 RAMTMP and fstab entries.  I made sure they all worked, including
 every feature such as overriding the defaults.   In all this time, no
 one has complained that the logic was broken.  (That the defaults
 were suboptimal, sure, but not that it did not work.)
 
 
 There is *no* magic going on here.  Read the init scripts to confirm
 this for yourself.
 mountkernfs.sh:
 - if RAMTMP=yes, a tmpfs is mounted on /tmp.  The defaults are taken
   from /etc/default/tmpfs (or /etc/fstab in preference if an entry
   for tmpfs on /tmp exists).
 - if RAMTMP=no, we do nothing.  Nothing *at all*.
 mountall.sh:
 - if there's an entry for /tmp in /etc/fstab, it's mounted just like
   a regular filesystem.  So if RAMTMP was no, and no entry exists in
   fstab, nothing will be mounted.
 
 So, as I already mentioned to you in private email last week, which
 you appear to have either not read or misunderstood, according to the
 continuing discussion here, all you need to do is:
 1) Set RAMTMP=no
 2) Remove any entries for /tmp from /etc/fstab
 and /tmp will just be the same directory on the root filesystem you
 had previously.
 
 Other than defaulting to mounting a tmpfs on /tmp, there have been
 *no other changes*!!  I tend to suspect from this thread that the
 problems you are experiencing are entirely self-inflicted, because
 they make no logical sense--there's no requirement for a /tmp
 entry, and no suggestion of one, and the TMPDIR stuff does not
 square with reality.
 
 
 Regards,
 Roger

Roger,

The possibility that I am hallucinating has occurred to me.  I don't
know what I can do to clear my mind. I continue to see my vision. If
what I see is real, others will find it. If real, perhaps it is
hardware dependent. I don't know. I do know that I have nothing
further to give to this discussion. Please accept my inadequacy and
move on. I, of course, with have to learn to live with it, but I will
try very had to be quiet about it in public, and try to speak of it
only to my psychiatrist.

Peace.
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120402145025.gm3...@big.lan.gnu

Re: how to increase space for tmpfs /tmp

On 20120402_165955, Roger Leigh wrote:
 On Mon, Apr 02, 2012 at 08:50:25AM -0600, Paul E Condon wrote:
  On 20120402_143034, Roger Leigh wrote:
   Other than defaulting to mounting a tmpfs on /tmp, there have been
   *no other changes*!!  I tend to suspect from this thread that the
   problems you are experiencing are entirely self-inflicted, because
   they make no logical sense--there's no requirement for a /tmp
   entry, and no suggestion of one, and the TMPDIR stuff does not
   square with reality.
  
  The possibility that I am hallucinating has occurred to me.  I don't
  know what I can do to clear my mind. I continue to see my vision. If
  what I see is real, others will find it. If real, perhaps it is
  hardware dependent. I don't know. I do know that I have nothing
  further to give to this discussion. Please accept my inadequacy and
  move on. I, of course, with have to learn to live with it, but I will
  try very had to be quiet about it in public, and try to speak of it
  only to my psychiatrist.
 
 Er, what?!  There's no need to learn to live with any problems.
 And as for the comments about hallucinations and psychiatrists,
 they add zero value to this discussion.  Please just keep it to the
 facts.  If you want help, provide the information so that we can
 help you, otherwise it's entirely worthless--no one, not you, not me
 and not anyone on this list is gaining anything from it.
 
 If there are problems, clearly state what they are, and I will do
 my best to help.  But so far, you've provided no useful information
 whatsoever, making it impossible to help you.  The comments you
 have made do not make sense.  They are certainly not true for any
 of the systems I've seen unless you've manually changed the init
 scripts to behave the way you've described.
 
 
 Regards,
 Roger

I made my system work to my liking by *putting*/tmp*into*/etc/fstab*.
It had never been there before, and it was your private message that
prompted me to think of doing that. I wanted to see what malfunction
you were thinking about when the line was there in order to better
communicate about the problem, but it made the system work, not fail
in a different way. I cannot understand how or why this worked, but
the system once worked flawlessly without the line in /etc/fstab, and
now works flawlessly with the line. (In this context, fail means that
sort aborted with an error message saying that it had run out of
scratch space. When it does that, it also takes care to release
all the space that it might have accumulated during the failed run,
ie. it fails gracefully.)

During my tests, I noticed that there was always a line in df,
concerning /tmp in tmpfs. With RAMTMP=yes the line was labeled tmpfs,
but with RAMTMP=no, the line was labeled 'overflow', or something else
that I misremember as overflow. Now I surmise that tmpfs is being used
during boot whatever the setting of RAMTMP, and is not being shut down
correctly towards the end of the boot process after the loader is
capable of reading /etc/defaults/rcS.  Of course, it can't be as
simple as that, and of course, I can't really understand, but that's
the best I can come up with. There are reasons why I am not a DD.

I now understand that df just reads /proc and displays what it finds
in 'df' format. I could have looked at /proc, I suppose, but at the
time that I was testing I didn't really know where or how 'df' got the
information, and I definitely didn't know where to look in /proc, if I
had thought to verify the 'df' output by checking it against /proc.

If this phenomena cannot be replicated by anyone else then it surely
should not be investigated by anyone in the Debian establishment. The
box is about twelve years old. It was purchased as a grey box from
Frys in California back in the days when the grocery store was still a
active part of the business. I had always found it to be compatible
with Debian, before, but it certainly doesn't seem compatible with
peace in the Debian community, now.

Have I become confused by the not understanding the distinction between
'yes' and 'no'? What other explanation? It flat out doesn't happen the
way you describe.

Suggestions for me to gather information to help work the issue?  
I'll try.  
Would you believe my reports? I am well known as having
hallucinations. It's in the Debian archives.

-- 
Paul E Condon 
pecon...@mesanetworks.net


-- 
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/20120402175502.gn3...@big.lan.gnu

Re: upgrade to Wheezy fails with aptitude

On 20120402_083627, Pierre Frenkiel wrote:
 On Sun, 1 Apr 2012, Paul E Condon wrote:
 
  Note that apt-get now installs recommended packages as default and is,
  for its robustness, the preferred program for package management from
  console to perform system installation and major system upgrades to
  releases posterior to Lenny.
^
 
 The better English word to use here is 'prior', which means earlier in
 time rather than the backside of,
 
   As far as I know, Squeeze is posterior to Lenny, and the recommended
 ^

This is the wrong word in English to describe the relation between
Squeeze and Lenny. Maybe OK in some other European language, but not
in English. If Squeeze and Lenny were mules in a pack train, and mule
Lenny were the lead mule in the train, then mule Squeeze would be
posterior to Lenny. But this use is far too refined for the world of
mule drivers, and not OK because mule train drivers just don't use
high falutin words like that.

For named releases of software and to express a relationship in time,
posterior is the wrong word in English.

Since the thread seemed mainly about correct English usage, I thought
it would be helpful to point this out before the word got incorporated
into Debian documentation.

HTH
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120402220623.go3...@big.lan.gnu

Re: how to increase space for tmpfs /tmp

On 20120402_215620, Roger Leigh wrote:
 On Mon, Apr 02, 2012 at 11:55:02AM -0600, Paul E Condon wrote:
  During my tests, I noticed that there was always a line in df,
  concerning /tmp in tmpfs. With RAMTMP=yes the line was labeled tmpfs,
  but with RAMTMP=no, the line was labeled 'overflow', or something else
  that I misremember as overflow. Now I surmise that tmpfs is being used
  during boot whatever the setting of RAMTMP, and is not being shut down
  correctly towards the end of the boot process after the loader is
  capable of reading /etc/defaults/rcS.  Of course, it can't be as
  simple as that, and of course, I can't really understand, but that's
  the best I can come up with. There are reasons why I am not a DD.
 
 Have a look at /etc/init.d/mountoverflowtmp.
 
 Your root filesystem is full.  This triggers the mounting of a
 tmpfs on /tmp *irrespective* of the RAMTMP option, in order to
 allow you to log in.
 
 Solution: free up some space on your root filesystem, and all
 will return to normal.  Mounting a filesystem on /tmp would have
 solved this specific problem by making more than a megabyte of
 free space available, which would avoid triggering this condition.
 
 
 Regards,
 Roger

Roger,

Many thanks for being so patient with me. df does say the disk
is full, but please read further.

My root filesystem disk is a nominal 60GB partition on an 80GB HD.
Other partitions are 2ea ext3 partitions of 19GB and one swap 
partition for the rest of the 80GB. (All partitions (except swap)
are ext3 on all my disks.)

As I say, df says it is full. But du -k -s -c says there slightly
less than 3.74GB of data on the whole disk. Removing some data
from the root filesystem can be done but before I do that I would
like to understand what is occupying 15/16ths of the disk, and how to
remove that and how to keep it from coming back. I think it is
very very unlikely that tmpfs is to blame, but I ask your help because
you have gotten me this far, and you already know how difficult I can
be but nevertheless persist in helping me. What should I do?

This is the ls of the root file system:

root@gq:/# ls -l /
total 116
drwxr-xr-x   2 root root  4096 20120326_175618 bin
drwxr-xr-x   3 root root  4096 20120325_095914 boot
drwxr-xr-x  13 root root  3360 20120402_162358 dev
drwxr-xr-x 137 root root 12288 20120402_163817 etc
drwxr-xr-x   2 root root  4096 20120402_164014 home
lrwxrwxrwx   1 root root32 20120313_070235 initrd.img - 
/boot/initrd.img-3.2.0-2-686-pae
lrwxrwxrwx   1 root root32 20120216_114920 initrd.img.old - 
/boot/initrd.img-3.2.0-1-686-pae
drwxr-xr-x  17 root root 12288 20120326_175618 lib
drwx--   2 root root 16384 20110611_113359 lost+found
drwxr-xr-x  12 root root  4096 20120328_040453 media
drwxr-xr-x   2 root root  4096 20120328_034547 mnt
drwxr-xr-x   3 root root  4096 20110611_113408 mpa2
drwxr-xr-x   3 root root  4096 20110611_113416 mpa3
drwxr-xr-x   2 root root  4096 20110611_113426 mpb1
drwxr-xr-x   4 root root  4096 20120402_164008 mpb2
drwxr-xr-x   2 root root  4096 20110611_113530 opt
dr-xr-xr-x  90 root root 0 20120402_161618 proc
drwx--   9 root root  4096 20120402_163817 root
drwxr-xr-x  16 root root   780 20120402_161710 run
drwxr-xr-x   2 root root 12288 20120326_175619 sbin
drwxr-xr-x   2 root root  4096 20110504_055428 selinux
drwxr-xr-x   2 root root  4096 20110611_113530 srv
drwxr-xr-x  13 root root 0 20120402_161619 sys
drwxr-xr-x   3 root root  4096 20120402_171701 tmp
drwxr-xr-x  10 root root  4096 20110611_113530 usr
drwxr-xr-x  12 root root  4096 20120203_162430 var
lrwxrwxrwx   1 root root28 20120313_070235 vmlinuz - 
boot/vmlinuz-3.2.0-2-686-pae
lrwxrwxrwx   1 root root28 20120216_114920 vmlinuz.old - 
boot/vmlinuz-3.2.0-1-686-pae
root@gq:/# 

This is the du command and results:
root@gq:/# du -k -s -c /[^pm]* /m[^e]*
7172/bin
18420   /boot
0   /dev
8556/etc
4   /home
0   /initrd.img
0   /initrd.img.old
202628  /lib
16  /lost+found
4   /opt
1200/root
668 /run
7576/sbin
4   /selinux
4   /srv
0   /sys
20  /tmp
2873144 /usr
508676  /var
0   /vmlinuz
0   /vmlinuz.old
4   /mnt
20  /mpa2
20  /mpa3
4   /mpb1
111516  /mpb2
3739656 total
root@gq:/# 

The tricky file argument in the command keeps du from including /media
and /proc in the total file space count but picks up space from
everything else in /. At the time this was done I had already moved
the contents of /home into the directory /mpb2.  I could have moved it
back, but I wanted to compose this letter and send as a higher
priority task. /mpa2 and /mpa3 are the second and third partitions of
the HD that holds the root partition. Xwindows is not installed. I
access this computer via ssh from another, newer computer running Squeeze.

My experience is that under 4GB is about the right size for a Debian
installation when loaded with the packages that I like to have, but
maybe I have been doing something terribly

Re: how to increase space for tmpfs /tmp

2012-04-01 Thread Paul E Condon

On 20120401_130449, Andrei POPESCU wrote:
 On Sb, 31 mar 12, 11:08:39, Paul E Condon wrote:
   
   Having a tmpfs filesystem for /tmp doesn't mean that a dedicated
   partition is required for /tmp.
  
  What you say doesn't work for me, but something else does.
 
 Show us (what doesn't work) :)

My statement was made in response to a statement by another person
whose name you have snipped out. It is just as well that you did this
snipping, because, now I regret writing precisely that in response to
that remark.

What *does* work for me is a separate partition for /tmp, which is
something that I never had to have before. Having to set up such as
part of a dist-upgrade, or full-upgrade, or re-install breaks the 'it
just works' paradigm. I think it was not really working in squeeze as
well, but until quite recently, I was unaware of the meaning of some
error messages and unable to design and execute diagnostic to tests, or
to formulate questions that would evoke helpful explanations.  (You do
realize by now that I do have communication problems, I hope.)

Peace.
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120401185217.gi3...@big.lan.gnu

Re: upgrade to Wheezy fails with aptitude

2012-04-01 Thread Paul E Condon

On 20120401_204502, Pierre Frenkiel wrote:
 On Wed, 28 Mar 2012, Lisi wrote:
 
 Tenses are often very difficult for non-native speakers of English to
 understand.
 
 It's funny. Do you really think that the the meaning of the past
 tense is different in other languages!?
 IMO, your interpretation of the past tense is wrong: The fact that a
 statement was written in the past never implied, in any language,
 that
 it is no more valid. Example:
 
  Pasteur recommended to wash hands frequently
 
 If the old statement is no more valid, that needs to be  specified
 explicitly, preferably in the same sentence or the next one,
 as in the following (half-imaginary) example:
 
 : Pasteur recommended to boil water before drinking it, but this is no more
   needed in most modern countries
 
 So, to come back to Debian upgrade, in the following sentence
 
 The upgrade process for other releases recommended the use of aptitude
 for the upgrade.
 
 the past tense is obviously used because this recommendation was
 written in the past, but it is nowhere writen that it is no more
 valid, except for
 upgrades from Debian 5.0 to Debian 6.0. For example, reading that,
 I would still use aptitude to upgrade from Debian 4.0 to Debian 5.0
 If you want an other proof that I am right, look at section 4.2
 
Please follow the instructions in the Release Notes for Debian GNU/Linux
5.0 to upgrade to 5.0 first.
 
 Please note that follow is not at the past tense!
 
 On the contrary, reading:
 
apt-get is the preferred program for package management from
console to perform system installation and major system upgrades
 
 I would use apt-get to upgrade to 5.0 Please note the plural, and
 that there is not a single restriction
 for the concerned realeases
 
 So, I persist to say that the 2 sentences are contradictory. I'll
 propose a slight modification to remove this contradiction:
 
 1/  in 4.4.6, replace
 
   The upgrade process for other releases recommended the use of
   aptitude for the upgrade. This tool is not recommended for upgrades
   from lenny to squeeze.
 
 by
 
   The recommended tool for system upgrade from Lenny to Squeeze
   is apt-get. For upgrades to previous releases, it is aptitude
 
 2/ in the Debian faq, replace
 
  Note that apt-get now installs recommended packages as default and is
  the preferred program for package management from console to perform
  system installation and major system upgrades for its robustness.
 
  by
 
  Note that apt-get now installs recommended packages as default and is,
  for its robustness, the preferred program for package management from
  console to perform system installation and major system upgrades to
  releases posterior to Lenny.
^

The better English word to use here is 'prior', which means earlier in
time rather than the backside of, I think. American English is my
first language and the only natural language in which I have any
facility, but Debian is international with much of the documentation
available only in English. That documentation should be understandable
to persons who only understand English with the continual help of an
English to language X dictionary or with the help of a friend who speaks
English but has no understanding of computers.

Please do sweat the details of wording.
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120401234947.gk3...@big.lan.gnu

Re: how to increase space for tmpfs /tmp

2012-03-31 Thread Paul E Condon

On 20120331_114636, Andrei POPESCU wrote:
 On Vi, 30 mar 12, 16:40:18, Paul E Condon wrote:
  
  Perhaps you are thinking of an officially published requirement. What
  I mean 'requirement' is a condition which by trial is found to be
  necessary for it to work.  I tried cases that did not meet this
  condition and none of them worked, and conditions which did meet this
  condition did work. The test was simple.  I found a file of output
  from find on a large file structure and tried to sort in on inode
  number. I got an error message about insufficient file space without
  any attempt at a fix, then I tried several values for TMPDIR and
  several different entries in /etc/fstab. Some combinations
  successfully sorted the file. Some aborted with the same error message
  as the base trial.  The pattern was clear. There must be an entry in
  /etc/fstab and the entry must be usable to mount an existing partition
  on an existing disk in the plain-vanilla traditional way. Putting an
  entry in that would choke on mount -a, also did no good in letting
  sort run to completion.
 
 Please post the exact commands you have tried and the error messages. 
 From the paragraph above it is not very clear to me what you did, but I 
 assure you TMPDIR works fine without an entry in fstab. Just make sure 
 the directory exists and you have sufficient space on that partition.

The exact commands depended on the exact setup of my systems. (I have
3) I happen to have a setup with multiple partitions, some of them
unused or easily repurposed. I set up test cases. I try a few
commands. And I dismantle the setup if some of the resources need to
be returned to their normal use. The exact commands, without extensive
documentation would just lead to further fruitless discussion, IMHO.
My system is working now with /tmp on its own partition. When the
problem I encountered is fixed, I will return to the old way of doing
things. This experience has been difficult for me. I thought I had
found an issue that needs fixing for the common good.  I still think
that. But I have done what I can, and it is clearly not enough.

Peace.
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120331170257.gf3...@big.lan.gnu

Re: how to increase space for tmpfs /tmp

2012-03-31 Thread Paul E Condon

On 20120331_061146, Tom H wrote:
 On Fri, Mar 30, 2012 at 4:44 PM, Paul E Condon
 pecon...@mesanetworks.net wrote:
  On 20120329_095413, Andrei POPESCU wrote:
  On Mi, 28 mar 12, 16:58:03, Paul E Condon wrote:
 
 
You could have also considered uncompressing the tarball somewhere 
else,
like $HOME/tmp or $HOME/src, but it sure is a valid solution, 
especially
          ^    ^
   On my computer that is running wheezy neither of these suggestions work,
   because, I think, these are not mount points supporting access to 
   external
   physical disk hardware.
 
  You must be misunderstanding me, I meant some directory in your home,
  because on most systems /home has enough space.
 
  No. You misunderstand me. There is a new extra requirement on TMPDIR, a
  restriction on ones choise of its value. A directory entry on a disk
  file system is not enough. It must be a directory entry that has a line
  in /etc/fstab that enables its use as a mount point to real separate
  partition. At least that is the way it is now. If this restriction were
  removed by some change in the implementation that I know not how to do...
  then your suggestion would likely work and the old way of using /tmp
  would also work.
 
 There's no extra requirement!
 
 If you set up /tmp as a real separate partition, that's the /tmp
 that the system'll use (it looks like it'll be a bind-mount over a
 tmpfs /tmp if you don't set RAMTMP=no in /etc/default/rcS).
 
 Pre-tmp-as-tmpfs, if you don't set up /tmp as a real separate
 partition, /tmp is a directory on /.
 
 Post-tmp-as-tmpfs, if you don't set up /tmp as a real separate
 partition, /tmp is a mount-point for a tmpfs filesystem the default
 RAMTMP=yes set in /etc/default/rcS.
 
 By default, the size of this filesystem is 20% of RAM because there
 are other tmpfs filesystems set up by default (/run, /run/lock,
 /run/shm) and they've been sized, respectively, at 10% of RAM, 5MiB,
 20% of RAM so that the total of tmpfs filesystems adds up to
 50%+5MiB for systems that don't have any swap set up to be able to
 operate in the event that the tmpfs filesystems are used up fully.
 
 If you want a larger tmpfs /tmp, you can change TMP_SIZE in
 /etc/default/tmpfs (or, untested, edit /etc/fstab and add a tmpfs
 /tmp tmpfs size=xxx 0 0). I'd mentioned earlier someone else's
 suggestion that you can set the maximum size of to RAM+SWAP. It's
 probably safer to set it to 20%_of_RAM+SWAP.
 
 If you don't want to use tmpfs for /tmp, you simply set RAMTMP=no
 in /etc/default/rcS.
 
 
  I never had a dedicated partion for /tmp and now it is required. That,
  to me, is a change. I fixed it when I learned that it is now required,
  and I think it would be nice to go back to the old way because the old
  way did not require a separate partition. But I repeat myself. Enough.
 
 Having a tmpfs filesystem for /tmp doesn't mean that a dedicated
 partition is required for /tmp.

What you say doesn't work for me, but something else does.

Peace.
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120331170839.gg3...@big.lan.gnu

Re: how to increase space for tmpfs /tmp

On 20120330_030935, Tom H wrote:
 On Wed, Mar 28, 2012 at 6:58 PM, Paul E Condon
 pecon...@mesanetworks.net wrote:
  On 20120329_011019, Andrei POPESCU wrote:
  On Mi, 28 mar 12, 20:47:45, Camaleón wrote:
   On Wed, 28 Mar 2012 21:55:01 +0300, Andrei POPESCU wrote:
On Mi, 28 mar 12, 17:02:23, Camaleón wrote:
  
 but the short version would be You can't make an omelette without
 breaking eggs
   
Which explains little about your arguments (that's a general stanza)
:-)
   
Well, so is yours, unless we are talking past each other. I was
specifically addressing only that paragraph, out of context.
  
   I didn't know you were interested in my arguments... they can be read
   here:
  
   http://lists.debian.org/debian-user/2011/11/msg02155.html
   http://lists.debian.org/debian-user/2011/11/msg02207.html
   http://lists.debian.org/debian-user/2012/03/msg00280.html
 
  We are still talking past each other on this one. Let me try again[1]: I
  was only disagreeing with you on the rather general statement that
  defaults should not change when they create problems for users. Nothing
  more.
 
  [1] but I won't be posting anymore on this, it's OT already
 
It seems to me you are expecting specific arguments about the /tmp on
tmpfs issue. As far as I recall you did read through the debian-devel
discussion(s), what point is there for me to repeat it here (even if my
memory is faulty and you did not read it)?
  
   I read the thread it was mentioned when I first asked for feedback, which
   was this:
  
   http://lists.debian.org/debian-devel/2011/11/threads.html#00281
  
   But to be sincere, I don't remember all of the contents of the posts
   nor who posted there what... and now you tell, I can't see any post
   belonging to you in that thread. Maybe you made your comments afterwards?
 
  I most probably didn't contribute at all. What for? People more
  knowledgeable than me and with more real life experience were already
  debating the issue with interesting arguments for both sides.
 
You expected to be able to uncompress an archive of unspecified size to
/tmp on a testing system.
  
   Unspecified size?
 
  If you did mention a size I must have missed it, sorry for that.
 
   It was just the kernel source (75 MiB). Wow. How. Big. :-)
 
  Since this created problems for you I'm assuming either a small amount
  of RAM (less than 512 MB?[2]) which points to a lower spec machine that
  would need special care anyway, or that something else was already
  hogging /tmp (which kinda' proves Roger's point).
 
  [2] 20% of 512 MB is still aprox. 100MB. My laptop is up 2 days and I'am
  running iceweasel, xxxterm, libreoffice, aptitude, mutt, pidgin, but
  /tmp usage is still below 1MB (844 KB according to 'df -h').
 
1. you may have had similar issues uncompressing that on any other
filesystem (small partition, quota, etc.)
  
   I doubt it becasue I tend to put special care for that can't happen (my 
   netbook
   has a 250 GiB. hard disk with only 2 partitions: /swap (2 GiB) and / 
   (the
   remaining space). Since I returned /tmp to the root filesystem I've 
   had no
   more hiccups.
 
  You could have also considered uncompressing the tarball somewhere else,
  like $HOME/tmp or $HOME/src, but it sure is a valid solution, especially
        ^    ^
 
  On my computer that is running wheezy neither of these suggestions work,
  because, I think, these are not mount points supporting access to external
  physical disk hardware. I tested this suggestion this morning. I don't
  fully understand this, but I have been told that access to the original
  /tmp file requires an entry in /etc/fstab. Think about it. Who is supplying
  this extra hardware? Any specialized software that requires scratch files
  because the work is too large to fit in ram is dead in the water with this
  change, and changing the setting of RAMTMP does not fix the problem, or
  any of the work-arounds that have been suggested so far. I think this is
  a serious flaw in the current wheezy, a release critical flaw perhaps.
 
  My particular problem is a project in which I regularly need to sort
  files 2 to 3 GB in size on a computer with less than 1 GB of ram and
  370 GB of rotating disk. But I am sure there are other problems
  needing real, physical scratch space running very nicely on computers
  old enough to have once run woody. And now they are to be broken by
  something in wheezy software? Can this happen? Really?
 
 I understand Andrei's suggestion to be that you set TMPDIR to a
 directory in home when launching the particular job that needs a large
 TMPDIR.
 
 Someone pointed out, in this thread or another tmpfs one, that the
 limit for the tmpfs size of /tmp is RAM+SWAP so you could increase
 the size of your swap to accommodate your sort - or simply disable
 tmpfs for /tmp on this box.

It is my understanding that the directory that one wishes to use in
TMPDIR

Re: how to increase space for tmpfs /tmp

On 20120329_095413, Andrei POPESCU wrote:
 On Mi, 28 mar 12, 16:58:03, Paul E Condon wrote:
   
   You could have also considered uncompressing the tarball somewhere else, 
   like $HOME/tmp or $HOME/src, but it sure is a valid solution, especially 
 ^^
  
  On my computer that is running wheezy neither of these suggestions work,
  because, I think, these are not mount points supporting access to external
  physical disk hardware.
 
 You must be misunderstanding me, I meant some directory in your home, 
 because on most systems /home has enough space.

No. You misunderstand me. There is a new extra requirement on TMPDIR, a
restriction on ones choise of its value. A directory entry on a disk
file system is not enough. It must be a directory entry that has a line
in /etc/fstab that enables its use as a mount point to real separate
partition. At least that is the way it is now. If this restriction were
removed by some change in the implementation that I know not how to do...
then your suggestion would likely work and the old way of using /tmp
would also work. 
 
  I tested this suggestion this morning. I don't
  fully understand this, but I have been told that access to the original
  /tmp file requires an entry in /etc/fstab.

In UNIX all directories are files ... special files that serve a
special system defined function, but files in the sense that they are
not inodes, or sectors, or blocks, etc. Linux follows UNIX on this
innovation of long ago.

 Err... your original /tmp is a directory on / not a file[1] and if you 
 don't mount anything there your system will happily use the available 
 space on / (the root partition).
 
 [1] unless you had a dedicated partition, but AFAIK in such a case you 
 wouldn't get a tmpfs anyway

I don't know why I get a tmpfs. I didn't ask for it. I have supposed
it came with a new way of doing file handling in the system software,
part of a new implementation that was supposed to be a work-alike
replacement of the previous version.

I never had a dedicated partion for /tmp and now it is required. That,
to me, is a change. I fixed it when I learned that it is now required,
and I think it would be nice to go back to the old way because the old
way did not require a separate partition. But I repeat myself. Enough.
What happens will happen.

 
  Think about it. Who is supplying this extra hardware? Any specialized 
  software that requires scratch files because the work is too large to 
  fit in ram is dead in the water with this change, and changing the 
  setting of RAMTMP does not fix the problem, or any of the work-arounds 
  that have been suggested so far. I think this is a serious flaw in the 
  current wheezy, a release critical flaw perhaps. My particular problem 
  is a project in which I regularly need to sort files 2 to 3 GB in size 
  on a computer with less than 1 GB of ram and 370 GB of rotating disk.
 
  But I am sure there are other problems  needing real, physical scratch 
  space running very nicely on computers old enough to have once run 
  woody. And now they are to be broken by something in wheezy software? 
  Can this happen? Really?
 
 Why do you think such scratch space should be in /tmp (regardless of 
 whether /tmp is on tmpfs, a separate partition or just a directory on 
 /)?
 
 Kind regards,
 Andrei
 P.S. I accidentally did some re-wrapping, how long do you set your 
 lines?
The default in mutt, whatever that is. I like defaults. That is the
main thing that originally attracted me to Debian. It offered defaults
that worked. 



-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120330204437.gc3...@big.lan.gnu

Re: how to increase space for tmpfs /tmp

On 20120330_164907, Tom H wrote:
 On Fri, Mar 30, 2012 at 4:12 PM, Paul E Condon
 pecon...@mesanetworks.net wrote:
  On 20120330_030935, Tom H wrote:
  On Wed, Mar 28, 2012 at 6:58 PM, Paul E Condon
  pecon...@mesanetworks.net wrote:
   On 20120329_011019, Andrei POPESCU wrote:
   On Mi, 28 mar 12, 20:47:45, Camaleón wrote:
On Wed, 28 Mar 2012 21:55:01 +0300, Andrei POPESCU wrote:
 On Mi, 28 mar 12, 17:02:23, Camaleón wrote:
   
  but the short version would be You can't make an omelette 
  without
  breaking eggs

 Which explains little about your arguments (that's a general 
 stanza)
 :-)

 Well, so is yours, unless we are talking past each other. I was
 specifically addressing only that paragraph, out of context.
   
I didn't know you were interested in my arguments... they can be read
here:
   
http://lists.debian.org/debian-user/2011/11/msg02155.html
http://lists.debian.org/debian-user/2011/11/msg02207.html
http://lists.debian.org/debian-user/2012/03/msg00280.html
  
   We are still talking past each other on this one. Let me try again[1]: I
   was only disagreeing with you on the rather general statement that
   defaults should not change when they create problems for users. Nothing
   more.
  
   [1] but I won't be posting anymore on this, it's OT already
  
 It seems to me you are expecting specific arguments about the /tmp 
 on
 tmpfs issue. As far as I recall you did read through the 
 debian-devel
 discussion(s), what point is there for me to repeat it here (even 
 if my
 memory is faulty and you did not read it)?
   
I read the thread it was mentioned when I first asked for feedback, 
which
was this:
   
http://lists.debian.org/debian-devel/2011/11/threads.html#00281
   
But to be sincere, I don't remember all of the contents of the posts
nor who posted there what... and now you tell, I can't see any 
post
belonging to you in that thread. Maybe you made your comments 
afterwards?
  
   I most probably didn't contribute at all. What for? People more
   knowledgeable than me and with more real life experience were already
   debating the issue with interesting arguments for both sides.
  
 You expected to be able to uncompress an archive of unspecified 
 size to
 /tmp on a testing system.
   
Unspecified size?
  
   If you did mention a size I must have missed it, sorry for that.
  
It was just the kernel source (75 MiB). Wow. How. Big. :-)
  
   Since this created problems for you I'm assuming either a small amount
   of RAM (less than 512 MB?[2]) which points to a lower spec machine that
   would need special care anyway, or that something else was already
   hogging /tmp (which kinda' proves Roger's point).
  
   [2] 20% of 512 MB is still aprox. 100MB. My laptop is up 2 days and I'am
   running iceweasel, xxxterm, libreoffice, aptitude, mutt, pidgin, but
   /tmp usage is still below 1MB (844 KB according to 'df -h').
  
 1. you may have had similar issues uncompressing that on any other
 filesystem (small partition, quota, etc.)
   
I doubt it becasue I tend to put special care for that can't happen 
(my netbook
has a 250 GiB. hard disk with only 2 partitions: /swap (2 GiB) and 
/ (the
remaining space). Since I returned /tmp to the root filesystem I've 
had no
more hiccups.
  
   You could have also considered uncompressing the tarball somewhere else,
   like $HOME/tmp or $HOME/src, but it sure is a valid solution, especially
         ^    ^
  
   On my computer that is running wheezy neither of these suggestions work,
   because, I think, these are not mount points supporting access to 
   external
   physical disk hardware. I tested this suggestion this morning. I don't
   fully understand this, but I have been told that access to the original
   /tmp file requires an entry in /etc/fstab. Think about it. Who is 
   supplying
   this extra hardware? Any specialized software that requires scratch files
   because the work is too large to fit in ram is dead in the water with 
   this
   change, and changing the setting of RAMTMP does not fix the problem, or
   any of the work-arounds that have been suggested so far. I think this is
   a serious flaw in the current wheezy, a release critical flaw perhaps.
  
   My particular problem is a project in which I regularly need to sort
   files 2 to 3 GB in size on a computer with less than 1 GB of ram and
   370 GB of rotating disk. But I am sure there are other problems
   needing real, physical scratch space running very nicely on computers
   old enough to have once run woody. And now they are to be broken by
   something in wheezy software? Can this happen? Really?
 
  I understand Andrei's suggestion to be that you set TMPDIR to a
  directory in home when launching the particular job that needs a large
  TMPDIR.
 
  Someone pointed out

Re: how to increase space for tmpfs /tmp

On 20120331_00, Andrei POPESCU wrote:
 On Vi, 30 mar 12, 14:44:37, Paul E Condon wrote:
  
  No. You misunderstand me. There is a new extra requirement on TMPDIR, a
  restriction on ones choise of its value. A directory entry on a disk
  file system is not enough. It must be a directory entry that has a line
  in /etc/fstab that enables its use as a mount point to real separate
  partition. At least that is the way it is now. If this restriction were
  removed by some change in the implementation that I know not how to do...
  then your suggestion would likely work and the old way of using /tmp
  would also work. 
 
 I really have no idea what you are talking about, but there is no new
 requirement on TMPDIR.

Perhaps you are thinking of an officially published requirement. What
I mean 'requirement' is a condition which by trial is found to be
necessary for it to work.  I tried cases that did not meet this
condition and none of them worked, and conditions which did meet this
condition did work. The test was simple.  I found a file of output
from find on a large file structure and tried to sort in on inode
number. I got an error message about insufficient file space without
any attempt at a fix, then I tried several values for TMPDIR and
several different entries in /etc/fstab. Some combinations
successfully sorted the file. Some aborted with the same error message
as the base trial.  The pattern was clear. There must be an entry in
/etc/fstab and the entry must be usable to mount an existing partition
on an existing disk in the plain-vanilla traditional way. Putting an
entry in that would choke on mount -a, also did no good in letting
sort run to completion.

But Andrei, I don't think either of us is going to actually fix the
problem. And I do think that we have already generated enough noise
here to attract the attention of someone who can. That person, or
persons, has already probably tried to verify my claim, and has
already succeeded, or not. The process is underway. Let us stop this
fruitless back and forth and wait and see. I have recieved two
messages telling me that the problem is surely not in coreutils, which
I do not doubt. But no one yet has told me that they have tried to
repeat my test and have not found a problem. But maybe I have
misunderstood some messages. In which case it is still worthwhile
stopping this discussion, so let us do so.

Peace.
   
  In UNIX all directories are files ... special files that serve a
  special system defined function, but files in the sense that they are
  not inodes, or sectors, or blocks, etc. Linux follows UNIX on this
  innovation of long ago.
 
 From this point of view, sure, but this is not what I was talking about.
 
   Err... your original /tmp is a directory on / not a file[1] and if you 
   don't mount anything there your system will happily use the available 
   space on / (the root partition).
   
   [1] unless you had a dedicated partition, but AFAIK in such a case you 
   wouldn't get a tmpfs anyway
  
  I don't know why I get a tmpfs. I didn't ask for it. I have supposed
  it came with a new way of doing file handling in the system software,
  part of a new implementation that was supposed to be a work-alike
  replacement of the previous version.
  
 /tmp on tmpfs has been optional before, it's just that the initscript 
 maintainers decided to make it default.
 
  I never had a dedicated partion for /tmp and now it is required. That,
  to me, is a change. I fixed it when I learned that it is now required,
  and I think it would be nice to go back to the old way because the old
  way did not require a separate partition. But I repeat myself. Enough.
  What happens will happen.
 
 There is no *requirement* for /tmp to be a separate partition. I really 
 don't understand how you came to this conclusion.
  
   P.S. I accidentally did some re-wrapping, how long do you set your 
   lines?
  The default in mutt, whatever that is. I like defaults. That is the
  main thing that originally attracted me to Debian. It offered defaults
  that worked. 
 
 Mutt uses an external editor for writing e-mails
 
 ,[ man muttrc ]
 | editor
 | Type: path
 | Default: “”
 |
 | This variable specifies which editor is used by mutt. It defaults to 
 the 
 | value of the $VISUAL, or $EDITOR, environment  variable, or to the 
 | string “/usr/bin/editor” if neither of those are set.
 `
 
 Kind regards,
 Andrei
 -- 
 Offtopic discussions among Debian users and developers:
 http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic

OK. I don't know how to fix it, and am at a loss to find out how. Lines
do get longer as they are quoted. I use emacs to write mail.

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120330224018.ge3...@big.lan.gnu

Re: how to increase space for tmpfs /tmp

2012-03-29 Thread Paul E Condon

On 20120329_095413, Andrei POPESCU wrote:
 On Mi, 28 mar 12, 16:58:03, Paul E Condon wrote:
   
   You could have also considered uncompressing the tarball somewhere else, 
   like $HOME/tmp or $HOME/src, but it sure is a valid solution, especially 
 ^^
  
  On my computer that is running wheezy neither of these suggestions work,
  because, I think, these are not mount points supporting access to external
  physical disk hardware.
 
 You must be misunderstanding me, I meant some directory in your home, 
 because on most systems /home has enough space.
 
  I tested this suggestion this morning. I don't
  fully understand this, but I have been told that access to the original
  /tmp file requires an entry in /etc/fstab.
 
 Err... your original /tmp is a directory on / not a file[1] and if you 
 don't mount anything there your system will happily use the available 
 space on / (the root partition).
 
 [1] unless you had a dedicated partition, but AFAIK in such a case you 
 wouldn't get a tmpfs anyway
 
  Think about it. Who is supplying this extra hardware? Any specialized 
  software that requires scratch files because the work is too large to 
  fit in ram is dead in the water with this change, and changing the 
  setting of RAMTMP does not fix the problem, or any of the work-arounds 
  that have been suggested so far. I think this is a serious flaw in the 
  current wheezy, a release critical flaw perhaps. My particular problem 
  is a project in which I regularly need to sort files 2 to 3 GB in size 
  on a computer with less than 1 GB of ram and 370 GB of rotating disk.
 
  But I am sure there are other problems  needing real, physical scratch 
  space running very nicely on computers old enough to have once run 
  woody. And now they are to be broken by something in wheezy software? 
  Can this happen? Really?
 
 Why do you think such scratch space should be in /tmp (regardless of 
 whether /tmp is on tmpfs, a separate partition or just a directory on 
 /)?

Why? Because the last time I looked which was long ago, using /tmp for
scratch space was recommended practice in the FHS. I didn't decide to
use /tmp when I started using it. /tmp was used by Debian packages and
I used the packages. Then I read the FHS to try to understand how they
managed to just do something that I well knew required scratch space.
And there it was. Maybe not a requirement, but an indication that this
was a useful result of coding to the standard. I question whether any
debian package manager has ever released a package to testing without
first doing some tests to be sure it used /tmp in a reasonable
fashion.  Whenever a software item arrived for packaging, my
understanding is, that the bulk of the work of packaging is bringing
it into compliance with FHS. As a consequence, I have very little
patience with the argument that developers would sudden lose all self
control and good sense merely because they have this new feature called
tmpfs or ramfs. There is no record of them having been, as a group, so
foolish.

Also, today I am having an experience which seems to indicate that
approx, the debian repository cacher, also has used /tmp for scratch
files. In fact, after several hours of poking at it, I have abandoned
use of approx for the while until this whole thing is sorted out by
people who actually understand how Debian works, which is a small
group of experts to which I surely don't deserve to belong. 

Kind regards,
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120330040200.gb14...@big.lan.gnu

Re: how to increase space for tmpfs /tmp

On 20120329_011019, Andrei POPESCU wrote:
 On Mi, 28 mar 12, 20:47:45, Camaleón wrote:
  On Wed, 28 Mar 2012 21:55:01 +0300, Andrei POPESCU wrote:
  
   On Mi, 28 mar 12, 17:02:23, Camaleón wrote:
  
  (...)
  
but the short version would be You can't make an omelette without
breaking eggs
   
   Which explains little about your arguments (that's a general stanza)
   :-)
   
   Well, so is yours, unless we are talking past each other. I was
   specifically addressing only that paragraph, out of context.
  
  I didn't know you were interested in my arguments... they can be read 
  here:
  
  http://lists.debian.org/debian-user/2011/11/msg02155.html
  http://lists.debian.org/debian-user/2011/11/msg02207.html
  http://lists.debian.org/debian-user/2012/03/msg00280.html
 
 We are still talking past each other on this one. Let me try again[1]: I 
 was only disagreeing with you on the rather general statement that 
 defaults should not change when they create problems for users. Nothing 
 more.
 
 [1] but I won't be posting anymore on this, it's OT already
 
   It seems to me you are expecting specific arguments about the /tmp on
   tmpfs issue. As far as I recall you did read through the debian-devel
   discussion(s), what point is there for me to repeat it here (even if my
   memory is faulty and you did not read it)?
  
  I read the thread it was mentioned when I first asked for feedback, which 
  was this:
  
  http://lists.debian.org/debian-devel/2011/11/threads.html#00281
  
  But to be sincere, I don't remember all of the contents of the posts 
  nor who posted there what... and now you tell, I can't see any post 
  belonging to you in that thread. Maybe you made your comments afterwards?
 
 I most probably didn't contribute at all. What for? People more 
 knowledgeable than me and with more real life experience were already 
 debating the issue with interesting arguments for both sides.
  
   You expected to be able to uncompress an archive of unspecified size to
   /tmp on a testing system.
  
  Unspecified size?
 
 If you did mention a size I must have missed it, sorry for that.
  
  It was just the kernel source (75 MiB). Wow. How. Big. :-)
 
 Since this created problems for you I'm assuming either a small amount 
 of RAM (less than 512 MB?[2]) which points to a lower spec machine that 
 would need special care anyway, or that something else was already 
 hogging /tmp (which kinda' proves Roger's point).
 
 [2] 20% of 512 MB is still aprox. 100MB. My laptop is up 2 days and I'am 
 running iceweasel, xxxterm, libreoffice, aptitude, mutt, pidgin, but 
 /tmp usage is still below 1MB (844 KB according to 'df -h').
 
   1. you may have had similar issues uncompressing that on any other
   filesystem (small partition, quota, etc.) 
  
  I doubt it becasue I tend to put special care for that can't happen (my 
  netbook
  has a 250 GiB. hard disk with only 2 partitions: /swap (2 GiB) and / (the 
  remaining space). Since I returned /tmp to the root filesystem I've had 
  no 
  more hiccups.
 
 You could have also considered uncompressing the tarball somewhere else, 
 like $HOME/tmp or $HOME/src, but it sure is a valid solution, especially 
   ^^

On my computer that is running wheezy neither of these suggestions work,
because, I think, these are not mount points supporting access to external
physical disk hardware. I tested this suggestion this morning. I don't
fully understand this, but I have been told that access to the original
/tmp file requires an entry in /etc/fstab. Think about it. Who is supplying
this extra hardware? Any specialized software that requires scratch files
because the work is too large to fit in ram is dead in the water with this
change, and changing the setting of RAMTMP does not fix the problem, or
any of the work-arounds that have been suggested so far. I think this is
a serious flaw in the current wheezy, a release critical flaw perhaps. 

My particular problem is a project in which I regularly need to sort
files 2 to 3 GB in size on a computer with less than 1 GB of ram and
370 GB of rotating disk. But I am sure there are other problems
needing real, physical scratch space running very nicely on computers
old enough to have once run woody. And now they are to be broken by
something in wheezy software? Can this happen? Really?

I hope some work-around that actually survives testing is suggested soon.





-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120328225803.gb6...@big.lan.gnu

repository signing keys update HOW?

I have forgotten how to install the latest official signing keys for
the package repositories, and I can't even remember search terms that
take me to the information. I am getting reports from aptitude that
signitures are unverified on release and index files. I think it should
happen automatically, but apparently it did not. 

Please remind me where I can get this.

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120329011232.ga8...@big.lan.gnu

Re: repository signing keys update HOW?

On 20120329_123755, Scott Ferguson wrote:
 On 29/03/12 12:12, Paul E Condon wrote:
  I have forgotten how to install the latest official signing keys for
  the package repositories, and I can't even remember search terms that
  take me to the information. I am getting reports from aptitude that
  signitures are unverified on release and index files. I think it should
  happen automatically, but apparently it did not. 
  
  Please remind me where I can get this.
  
 The clue is keys :-)
 
 
 apt-cache search keyring and choose according to your needs
 (debian-keyring at a minimum)

I am getting error messages when attempting to update release and
index files for the repository itself. These are provided, I think, in
the package debian-keyring (so keys search did not work and I had used
other means to find this ;-) But on the affected computer debian-keyring
is shown by aptitude to be not installed. So proper updating must have
stopped when the keys used in the initial install expired. Now I need
to used some direct means, such as wget, or something which I can't
remember, against a special keyring server, whose URL I also can't
remember. I need help remembering. Once I find the page I need, I'm
sure I will have no trouble understanding, and doing what needs to
be done.

And thanks for mentioning (debian-keyring at a minimum) The
descriptive phrase confirmed my guess that this was the one I needed
the contents of. I need an alternative method of getting the contents
since aptitude is in need of new keys to start working again.

Please keep up the good help!
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120329020842.gb8...@big.lan.gnu

Re: Does find subdir -printf %A\n a bad example which is mentioned in the documentation?

On 20120328_191216, Regid Ichira wrote:
 $ zgrep -A3 '%A%p' /usr/share/info/find.info.gz
  newest=$(find subdir -newer timestamp -printf %A%p\n |
 sort -n |
 tail -1 |
 cut -d: -f2- )
 
 is taken from findutil's (4.4.2-4) documentation.  It doesn't work
 here:
 
 $ mkdir -v subdir
 mkdir: created directory `subdir'
 $ touch subdir/file
 $ find subdir -printf %A%p\n
 %p
 %p
 $ find subdir -printf %A\n
 %\n%\n$
 
 I think the documentation's example assumes %A\n is supposed to
 print time information as is.  While, in fact, there must be a
 modifier after the 'A'.  Does
 
 find subdir -printf %A\n
 
 print time information for you?  Am I right that the documentation's
 example assume it should work as is?  
   Does the example also bad with respect to %p?  If so, what is the
 correct formatting?

 find subdir -printf %Ap\n prints AM or PM depending on the file's 
access time in the local time zone of the computer. You string together
a bunch of %A each followed by a single letter from the list of letters
just below the %A under -printf in the man page to get a useful printing
of the file access time. i.e. there must be a 'k' and 'k' must be one
of the characters from that list ( including k can be @ even though @
is above the column heading of allowed k values ) I know this is confusing.
Try testing with 
find subdir -printf %A@ %Ap\n 
and see a somewhat useless but educational, I hope.
In place of the space in this trial, put a hyphen [-]
Try 
find subdir -printf %A@ %Ap %f\n
to include the base name of the file without the path from subdir.
Look at
find subdir -printf %i %b %M %n %U %G %s %TY%Tm%Td_%TH%TM%TS %p\n
This is one I use and find convenient for some work. Figure out how it
works, and then write, and contribute a better man page. I would have
appreciated it when I was learning, but now that I know the truth I
can't see a better way to say it than is already there.

Enjoy ?-)
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120329032600.gc8...@big.lan.gnu

Re: linhas redundantes no sources.list

2012-03-27 Thread Cláudio E. Elicker

On Tue, 27 Mar 2012 11:15:04 -0300
Fred Maranhão fred.maran...@gmail.com wrote:

 Gente,
 
 Estas duas linhas são redundantes?
 
 deb http://security.debian.org/debian-security squeeze/updates main
 contrib non-free
 deb http://linorg.usp.br/debian/ squeeze-updates main contrib non-free
 

http://lists.debian.org/debian-volatile-announce/2011/msg0.html

-- 
EMACS is my operating system; Linux is my device driver.


--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120327132631.2496b59f@yeh1.parsec

Re: Ext2 bit rot

2012-03-27 Thread Paul E Condon

On 20120327_065717, Dom wrote:
 On 27/03/12 03:15, Paul E Condon wrote:
 On 20120326_135131, Stan Hoeppner wrote:
 On 3/26/2012 12:29 PM, Paul E Condon wrote:
 
 So how do I turn off ramfs on a wheezy box where it was installed as
 part of the initial net-inst install, and seems to be involved it
 the proper functioning of the file system root ( / ) ???
 
 You don't turn off tmpfs as it's used by other system functions.  You
 simply want to mount /tmp on a different (real) filesystem.  As I
 mentioned above, try unmounting /tmp and then creating a /tmp with the
 permissions I mentioned above.  Then search for the answer to disabling
 the system level mount of /tmp on tmpfs.
 
 This has been mentioned here quite recently.
 
 Edit /etc/default/rcS.
 
 At the end of the file you will find this entry:
 
 # mount /tmp as a tmpfs
 RAMTMP=yes
 
 Change the yes to no.
 
 Reboot.
 
 This will only affect /tmp. There are other entries for the other
 ramfs filesystems, but they take very little memory and so can be as
 they are.
 
 -- 
 Dom

Thanks. It works. I feel much better now.

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120327155610.gb31...@big.lan.gnu

Re: Repositórios do Debian Lenny

2012-03-26 Thread Cláudio E. Elicker

On Mon, 26 Mar 2012 11:26:21 -0300
Samir Patrice samir.patr...@gmail.com wrote:

 Olá galera,
 Alguem tá tendo problemas pra fazer o apt-get update no debian lenny?
 To tentando aqui e tá ocorrendo um erro 404.
...
 Err http://security.debian.org lenny/updates/main Packages
   404 Not Found
...

Não vai ter mais atualizações de segurança para o Lenny:
http://www.debian.org/News/2012/20120209

 Alguem pode sugerir outro repositorio?

Aqui você deve achar a última atualização de segurança:
http://snapshot.debian.org/archive/debian-security/


-- 
EMACS is my operating system; Linux is my device driver.


--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120326121438.56793c65@yeh1.parsec

Re: Ext2 bit rot (was: how to increase space for tmpfs /tmp ... OT question)

2012-03-26 Thread Paul E Condon

On 20120326_074231, Henrique de Moraes Holschuh wrote:
 On Mon, 26 Mar 2012, Jochen Spieker wrote:
  Henrique de Moraes Holschuh:
   On Sun, 25 Mar 2012, Paul E Condon wrote:
   I'm sure some/many of you will gasp at that fact I still use EXT2.  If
   it ain't broke, don't fix it.  The /boot and root filesystems are on
   EXT2, with all data storage on XFS.  Never had problems with EXT2 in
   this setup, so it lives on, for now.
   
   You are, of course, aware of the term bit rot?
   
   ext2 is mostly unused nowadays, and it gets little attention and testing.
   It depends heavily on the VFS layer pagecache, and other areas of the 
   kernel
   to work well.  But THOSE areas are not staying put.  So, ext2 *will* bit
   rot.
  
  I was under the impression that at least ext3 (and maybe even ext4)
  shares a lot of code with ext2. Is this wrong?
 
 I am not sure, but it could actually make the bit rot more likely.
 
 People already try hard to not break anything when changing stuff in the
 kernel, and update code using old interfaces (otherwise ext2 wouldn't even
 build) but corner cases and subtle interactions can get past undetected, and
 that's where bit rot starts to set in.
 

Please address my OT question in my OT branch of this
increase-ramfs-howto discussion. 

How do I turn off ramfs on a wheezy installation on which it is
already there? Preferably without doing a reboot? I am sure ramfs is
doing me no good, but I want to avoid creating new problems by
removing it in a clumsy way.

IMHO, ext3 was introduced in order to correct some bit rot problems in
ext2, as well as to introduce journaling, as such it is not surprising
that it shares a lot of code with ext2. The intention was, I think, to
leave behind the parts of the code that rotted the bits, while
introducing a major new feature. I can imagine that in certain
restricted applications ext2 never executes the part of its code that
rots bits, and as a consequence Stan has never had problems with it.

But I have never had problems with ext3, and all my disks are
formatted in ext3, so I incline toward a path that is the least change
from my present situation. I labeled my post in a way that I hoped
would make it clear that I did not want to engage in the larger (more
interesting???) question of ramfs, in general, and particularly XFS,
which I view as a possible alternative to ext4, to which I have not
yet seen fit to migrate. 

So how do I turn off ramfs on a wheezy box where it was installed as
part of the initial net-inst install, and seems to be involved it
the proper functioning of the file system root ( / ) ???

Suggestions?

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120326172914.ga27...@big.lan.gnu

Re: Ext2 bit rot

2012-03-26 Thread Paul E Condon

On 20120326_135131, Stan Hoeppner wrote:
 On 3/26/2012 12:29 PM, Paul E Condon wrote:
 
  Please address my OT question in my OT branch of this
  increase-ramfs-howto discussion. 
  
  How do I turn off ramfs on a wheezy installation on which it is
  already there? Preferably without doing a reboot? I am sure ramfs is
  doing me no good, but I want to avoid creating new problems by
  removing it in a clumsy way.
 
 Start a new thread for this issue.  I dunno how to perma-disable tmpfs
 mounted on /tmp.  I don't have the time right now.  Figuring that out is
 the time consuming part.  Once you have that done, you simply create
 /tmp in your root filesystem with appropriate permissions.
 
 drwxrwxrwt   4 root root
 
  IMHO, ext3 was introduced in order to correct some bit rot problems in
  ext2, as well as to introduce journaling, as such it is not surprising
  that it shares a lot of code with ext2. The intention was, I think, to
  leave behind the parts of the code that rotted the bits, while
  introducing a major new feature. I can imagine that in certain
  restricted applications ext2 never executes the part of its code that
  rots bits, and as a consequence Stan has never had problems with it.
 
 Don't use slang jargon if you're not familiar with it. ;)  Read up on
 bit rot and software rot so you understand what the OP was referring
 to when he used the term bit rot.  He simply meant that programmers
 may no longer be taking proper care in making sure the EXT2 code is
 maintained to work properly in newer kernels.  I disagree with his
 assertion here, but I can foresee a day in the future where his
 sentiments of today may prove correct.
 
  But I have never had problems with ext3, and all my disks are
  formatted in ext3, so I incline toward a path that is the least change
  from my present situation. I labeled my post in a way that I hoped
  would make it clear that I did not want to engage in the larger (more
  interesting???) question of ramfs, in general, and particularly XFS,
  which I view as a possible alternative to ext4, to which I have not
  yet seen fit to migrate. 
 
 For you Paul, there is no compelling reason to switch from EXT3 to
 anything else.  Not at this time.
 
  So how do I turn off ramfs on a wheezy box where it was installed as
  part of the initial net-inst install, and seems to be involved it
  the proper functioning of the file system root ( / ) ???
 
 You don't turn off tmpfs as it's used by other system functions.  You
 simply want to mount /tmp on a different (real) filesystem.  As I
 mentioned above, try unmounting /tmp and then creating a /tmp with the
 permissions I mentioned above.  Then search for the answer to disabling
 the system level mount of /tmp on tmpfs.
 
 -- 
 Stan
 

Thanks, Stan.

I had tried to couch my request in the terms that were being used here
without any real understanding of the depths of their inadequacy. I
had already tried to simple mount a spare partition of adequate size
for /tmp, but I got, variously, a response that /tmp was not mounted,
or that it was already mounted. When I tried to umount it, the
response was that it was not mounted. Never that it was busy and
therefore the request should confirmed. Since my last email, a job
that had been running for several days ended, and with that my desire
to do this *without reboot* is gone. I have started trying to
understand what is happening with multiple reboots.

My /etc/fstab is (and always has been from well before I became concerned about 
ramfs) :

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# file system mount point   type  options   dump  pass
proc/proc   procdefaults0   0
# / was on /dev/sda1 during installation
LABEL=pla1  / ext3  
errors=remount-ro 0   1
# /mpa2 was on /dev/sda2 during installation
UUID=0fde9fde-fe8c-4119-8690-5809cab2fa7c /mpa2   ext3defaults  
  0   2
# /mpa3 was on /dev/sda3 during installation
UUID=e3e6afa5-53d8-44cc-b856-e137c56bd11f /mpa3   ext3defaults  
  0   2
# /mpb1 was on /dev/sdb1 during installation
UUID=9e1e016e-aea7-4500-bc96-c8d03229c918 /mpb1   ext3defaults  
  0   2
# swap was on /dev/sda4 during installation
UUID=c79a09f3-60af-4255-b54f-13a3c40441b7 noneswapsw
  0   0
/dev/scd0   /media/cdrom0   udf,iso9660 user,noauto 0   0
/dev/fd0/media/floppy0  autorw,user,noauto  0   0

Note that there is no mention of /tmp. This because I want it on the
'root' disk device where it can dynamically share space with /etc,
/boot, /root, etc.

But my 'df' shows:

root@gq:~# df
Filesystem 1K-blocks  Used

Re: how to increase space for tmpfs /tmp ... OT question

2012-03-25 Thread Paul E Condon

On 20120325_010923, Stan Hoeppner wrote:
 On 3/24/2012 4:02 PM, Javier Vasquez wrote:
  2012/3/24 shirish शिरीष shirisha...@gmail.com:
 
  # TMPFS_SIZE: maximum size for all tmpfs filesystems if no specific
  # size is provided.  If no value is provided here, the kernel default
  # will be used.
  TMPFS_SIZE=20%
  
  See, this is as you wish.  This particular setting is the maximum for
  ALL of the tmpfs space.  Kind of the default if nothing else is
  specified.  You might not touch this if you don't want.  So I would
  not be afraid of using 100% of RAM here.
 
 That's probably not a smart idea:
 
 http://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt
 ...
 tmpfs has three mount options for sizing:
 
 size:  The limit of allocated bytes for this tmpfs instance. The
default is half of your physical RAM without swap. If you
oversize your tmpfs instances the machine will deadlock
since the OOM handler will not be able to free that memory.
 ...
 
 The OP would likely be far better off simply mounting /tmp on his root
 filesystem as was always done in the past.  Application developers
 writing to /tmp aren't expecting memory speed transfers of such files
 because of the traditional placement of /tmp.  And he'll have more than
 enough space, many times his RAM quantity.
 
 FWIW, my Squeeze servers are all upgrades going back to Sarge, IIRC.
 Here's my /tmp setup:
 
 $ df /tmp
 FilesystemTypeSize  Used Avail Use% Mounted on
 /dev/sda2 ext2 33G  3.8G   28G  12% /
 
 I'm sure some/many of you will gasp at that fact I still use EXT2.  If
 it ain't broke, don't fix it.  The /boot and root filesystems are on
 EXT2, with all data storage on XFS.  Never had problems with EXT2 in
 this setup, so it lives on, for now.
 
 -- 
 Stan
 
 
 -- 
 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/4f6eb693.30...@hardwarefreak.com
 

OK, Stan,

I'm convinced by your argument, but I'm not ready to switch to XFS and
ext2. My root partition is ext3 and contains plenty of space (~50GB)
for /tmp. Also, I have been being bothered by running out of space for
intermediate files during 'sort' of largish files. So, ... how do I
shut down tmpfs? On my plain vanilla wheezy tmpfs seems also to be
involved in something called rootfs which is in use. Do I have to
reboot to get rid of the tmpfs mount of /tmp?  On this machine, I have
a 60GB partition that I have been using with the -T option in sort to
make it work again, but I can't make that partition BE mounted as /tmp
until I have umount-ed the tmpfs mount at /tmp. At least that is what
I think my problem is.

TIA
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120325230710.ga12...@big.lan.gnu

Re: debconf configuration question in one window

2012-03-13 Thread Karl E. Jorgensen

Hi

On Tue, 2012-03-13 at 07:05 +, Bilal mk wrote:

 Hello, 
 
 
 
 I am trying to build a debian package for my web application. It will
 ask two question. 
 
 
 But i want this question in single window. Currently it will prompt
 two separate window.
 
 
 Please help me how to do this on single window? 


Whether questions are displayed as a single or two windows is entirely
up to the debconf front-end - it is not under the control of maintainer
scripts.

For example, the Gnome front-end will ask multiple questions in one
window, whereas the dialog front-end will not.

In my experience: if you appear to need both questions asked at the
same time, the real problem is the templates: They should contain
enough information for the user to make a sensible response of any
single question - regardless of whether they are presented as one window
with 2 questions or two consecutive windows. 

Hope this helps

Re: Instalar programa não livre

2012-03-10 Thread Cláudio E. Elicker

On Sat, 10 Mar 2012 15:59:51 -0300
Sávio M. Ramos savio.deb...@gmail.com wrote:

 Em Fri, 9 Mar 2012 11:19:58 -0300
 Cláudio E. Elicker elic...@gmail.com escreveu:
 
  O mc (midnight commander) permite visualizar o conteúdo de um
  arquivo .deb muito facilmente.
 
 Mc? Quem se lembra disto? Tenho 49 anos você deve ser das antigas
 também..
 

O mc não é gráfico, não tem ícones bonitinhos, mas dá de 10 a 0 em
qualquer outro gerenciador de arquivos (e já usei quase todos) em
termos de praticidade. Claro, isso é apenas a minha opinião.

Eheh, sou mesmo das antigas, do tempo do cartão perfurado e do
teletipo :-)

  EMACS is my operating system; Linux is my device driver.
 
 Que assinatura bonita! Não abro mão do Emacs para trabalhar com Latex
 e Gnu R.
 

Emacs é realmente uma maravilha. Pia da cozinha incluida.

-- 
EMACS is my operating system; Linux is my device driver.


--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120310211058.135e8eec@yeh1.parsec

Re: Instalar programa não livre

2012-03-09 Thread Cláudio E. Elicker

On Fri, 9 Mar 2012 10:55:51 -0300
Gunther Furtado gunfurt...@gmail.com wrote:

 Além do dpkg, acho que o file-roller e o ark também abrem
 pacotes .deb.
 

O mc (midnight commander) permite visualizar o conteúdo de um
arquivo .deb muito facilmente.

[]'s

-- 
EMACS is my operating system; Linux is my device driver.


--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120309111958.0913c110@yeh1.parsec

Re: [on-topic] /etc/passwd

2012-03-08 Thread Karl E. Jorgensen

On Thu, 2012-03-08 at 14:11 +, lina wrote:

 Hi,
 
 Last time I added one user,
 Later I used deluser some_user_name
 
 but some information still keep it in the /etc/passwd and /etc/shadow.

What information is left? We would expect one line per user, but if the
line is still there, then the user has not been deleted...


 
 My question is that: is it safe do delete the entry regards the
 deleted user by hand?

Depends... See above

 
 
 Thanks,

Re: Persisting a one-off hostname change

2012-02-27 Thread Paul E Condon

On 20120227_131327, Jason Heeris wrote:
 I have an image of a Debian Squeeze system that I want to put onto
 multiple systems (flash-based disks for a single-board computer). I'd
 like each system to have a different hostname, but have that hostname
 persist across subsequent reboots.
 
 My first thought was that I could remove /etc/hostname from the
 image, and modify /etc/init.d/hostname.sh to something like:
 
     do_start () {
         if [ ! -f /etc/hostname ]; then
             RANDOM_MAGIC=$(cat /dev/urandom | tr -dc '0-9A-Z' | head -c 6)
             echo prefix-${RANDOM_MAGIC}  /etc/hostname
         fi
 
         HOSTNAME=$(cat /etc/hostname)
 
         [ $VERBOSE != no ]  log_action_begin_msg Setting hostname
 to '$HOSTNAME'
         hostname $HOSTNAME
         ES=$?
         [ $VERBOSE != no ]  log_action_end_msg $ES
         exit $ES
     }
 
 Then, upon the first boot AFTER imaging, this script would see that
 there's no /etc/hostname, generate one, write the new value to the
 file and I'd be done.
 
 The problem is that the root FS is not mounted writeable at this stage
 of the boot process! Is there another point in the rcS.d script
 sequence where I can persist the current hostname? After
 S10mountall.sh? Or is there a better way to achieve this that I'm
 missing?
 
 — Jason


I've been lurking, hoping to learn. Maybe I don't fully understand, but ---
Wouldn't you be better off using the MAC address of the interface chip in each 
computer
rather than a random number. The MAC address is supposed to be unique. I know 
it can be
changed in software, but the value stored in ROM should be adequate for your 
purpose.

If the above is acceptable, then the test for whether the boot image has been 
properly
editted or not should be whether or not the image agrees with the ifconfig eth0 
output
as to the value of the MAC address.

And keep in mind that you might want to do the change as a two step process. 
First do
edits that get the computer bootable with a strictly temporary hostname, then 
when
booting with that temporary name, edit and reboot with a more permanent and 
convenient
name for the follow-on use/processing of the individual computer.

But --- maybe I misunderstand totally the nature of your problem, in which case 
sorry
for the noise.


-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120227192839.ga2...@big.lan.gnu

Re: Persisting a one-off hostname change

2012-02-27 Thread Paul E Condon

On 20120227_131327, Jason Heeris wrote:
I have an image of a Debian Squeeze system that I want to put onto
multiple systems (flash-based disks for a single-board computer). I'd
like each system to have a different hostname, but have that hostname
persist across subsequent reboots.

My first thought was that I could remove /etc/hostname from the
image, and modify /etc/init.d/hostname.sh to something like:

do_start () {
if [ ! -f /etc/hostname ]; then
RANDOM_MAGIC=$(cat /dev/urandom | tr -dc '0-9A-Z' | head -c 6)
echo prefix-${RANDOM_MAGIC} /etc/hostname
fi

HOSTNAME=$(cat /etc/hostname)

[ $VERBOSE != no ] log_action_begin_msg Setting hostname
to '$HOSTNAME'
hostname $HOSTNAME
ES=$?
[ $VERBOSE != no ] log_action_end_msg $ES
exit $ES
}

Then, upon the first boot AFTER imaging, this script would see that
there's no /etc/hostname, generate one, write the new value to the
file and I'd be done.

The problem is that the root FS is not mounted writeable at this stage
of the boot process! Is there another point in the rcS.d script
sequence where I can persist the current hostname? After
S10mountall.sh? Or is there a better way to achieve this that I'm
missing?

— Jason

--
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/CA+Zd3FeXx7CRzXHM6ozpOMUdkQvxi2-=2zmhxxr5oht8nel...@mail.gmail.com

I've been lurking, hoping to learn. Maybe I don't fully understand, but ---
Wouldn't you be better off using the MAC address of the interface chip in each
computer
rather than a random number. The MAC address is supposed to be unique. I know
it can be
changed in software, but the value stored in ROM should be adequate for your
purpose.

If the above is acceptable, then the test for whether the boot image has been
properly
editted or not should be whether or not the image agrees with the ifconfig eth0
output
as to the value of the MAC address.

And keep in mind that you might want to do the change as a too step process.
First do
edits that get the computer bootable with a strictly temporary hostname, then
when
booting with that temporary name, edit and reboot with a more permanent and
convenient
name for the follow-on use/processing of the individual computer.

But --- maybe I misunderstand totally the nature of your problem, in which case
sorry
for the noise.

--
Paul E Condon
pecon...@mesanetworks.net

Re: Persisting a one-off hostname change

2012-02-27 Thread Paul E Condon

On 20120228_081002, Jason Heeris wrote:
 On 28 February 2012 03:28, Paul E Condon pecon...@mesanetworks.net wrote:
  I've been lurking, hoping to learn. Maybe I don't fully understand, but ---
  Wouldn't you be better off using the MAC address of the interface chip in 
  each computer
  rather than a random number. The MAC address is supposed to be unique. I 
  know it can be
  changed in software, but the value stored in ROM should be adequate for 
  your purpose.
 
 I like that idea! This means it would also be invariant over any
 subsequent re-images.
 
 I'd still want to have the prefix on the hostname, otherwise it'll
 make life difficult for production staff. But it's still a pattern
 that can be checked.

Well yes. A fixed pattern, prefix or a suffix that can be grepped to
identify these hosts as the special ones for which this special
treatment is being done. I'm not aware of a way to discover the
hardware MAC address, except by running ifconfig. That may not be
available until the boot has already gotten past the point at which an
IP address has been assigned by DHCP, or whatever. I'm suggesting an
idea, not a well worked out implementation.

For me, a big problem with random numbers is that they are all
different most of the time, but not always, and I don't see a way for
the system to fail gracefully when bad luck gives the same random
value on two different executions, just once in the whole time this
system is in operation.

 
  And keep in mind that you might want to do the change as a two step 
  process. First do
  edits that get the computer bootable with a strictly temporary hostname, 
  then when
  booting with that temporary name, edit and reboot with a more permanent and 
  convenient
  name for the follow-on use/processing of the individual computer.
 
 I don't think a two step process is necessary. If a script can check
 check whether the hostname is what it should be... well, why make it
 require manual intervention?

I didn't intend that the two steps be separated by some manual
process. I worry that when you start implementing the system you might
find that the total fix cannot actually be done at one point during
the boot process. If this is so, you can think about writing an
intermediate, bootable, file to disk, with an intermediate name or
some other flag that signals that the second part of the work still
needs to be done, and then reboot and part of the script. I'm worried
that this may have some gotchas that you don't yet know about.

 
 — Jason
 

Cheers,
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120228012159.gb2...@big.lan.gnu

Re: How do you approach the problem of MaxClients reached with apache?

2012-02-22 Thread Karl E. Jorgensen

On Wed, 2012-02-22 at 14:05 +, francis picabia wrote:

 Hello,
 
 One of the most frustrating problems which can happen in apache is to
 see the error:
 
 server reached MaxClients setting
 
 After it, the server slowly spirals down.  Sometimes it mysteriously recovers.
 This is difficult to diagnose after the problem appeared and went away.
 
 What have we for advice on :
 
 a) diagnosis of the cause when the problem is not live
 b) walling off the problem so one bad piece of code or data does not
 effect all sites hosted on same server


To diagnose it, enable server-status - this gives you a URL in apache
where you can see how many workers are busy, how many requests are being
served etc. You want to tie this into your monitoring system.

As for increasing capacity you need to read the docs for the MPM worker
you're using - for example:
http://httpd.apache.org/docs/2.2/mod/prefork.html for the pre-forking
server.


 
 Obviously a Virtual Machine could handle item b, but I am hoping for
 something interesting on the apache side.  Obviously there is
 increasing the limit, but this is typically not the solution - the real
 problem for apache is bad code or data outside of what the code
 can digest in a timely manner).
 
 One tip I've seen suggested is to reduce the apache timeout from 120
 seconds down to 60 seconds or so.

Re: Manual's Tutorial #2 fails to boot from menu

2012-02-22 Thread Ed E

Moving this to debian-l...@lists.debian.org


-- 
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/1329930081.74370.yahoomailclas...@web161704.mail.bf1.yahoo.com

Manual's Tutorial #2 fails to boot from menu

2012-02-19 Thread Ed E

I built Tutorial 2: A web browser utility from Section 16.3 the Debian Live 
Manual dated Mon 21 Nov 2011 01:14:20 PM EST. I build the image on 2/17/12. It 
fails to initialize from the boot sceen prompt of Live. It generates a beep, 
but nothing else. Both of the Other options work fine. The same problem 
exists when the ISO is written to a CDR and when written to a USB stick.

Hitting the TAB on Live shows
/live/vmlinuz initrd=/live/initrd.img boot=live config
Note that the ISO doesn't have a vmlinuz or initrd.img in the /live 
subdirectory. I has:
vmlininiz-3.2.0-1-486
initrd.img-3.2.0-1-486
and
vmlininiz-3.2.0-1-686-pae
initrd.img-3.2.0-1-686-pae
If links are required they weren't generated.

I used the following for the build:
live-build 3.0i~24ubuntu1
debootstrap 1.0.37
live-config not installed
live-boot not installed

Build system (uname -a):
Linux XXX 3.0.0-16-generic-pae #28-Ubuntu SMP Fri Jan 27 19:24:01 UTC 2012 i686 
athlon i386 GNU/Linux
Same processor used for testing.

Thanks for your 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/1329672427.12463.yahoomailclas...@web161704.mail.bf1.yahoo.com

Re: Need help dealing with the demise of qpopper

2012-02-16 Thread Paul E Condon

On 20120216_122003, Andrei POPESCU wrote:
 On Mi, 15 feb 12, 18:17:11, Paul E Condon wrote:
  
  Thanks but ...  What is dovecot? And which host is it to be installed?
 
 You asked for replacements to qpopper and this is what I suggested. See 
 'apt-cache show dovecot-pop3d' for more info.
 
 To make even more precise suggestions you need to provide more info 
 about the qpopper side. You mentioned that all you needed was to 
 install it, which probably means it automagically picked up some 
 existing mail storage on the same computer. Please provide more info 
 about it and how new messages arrive there.

Please accept my sincere apologies. I am old, and was tired and
cranky.  Over night another suggestion has arrived which I tested
before writing this response. It works to my liking.

The messages that arrive at the host that had been running qpopper
have been generated by system software, e.g. aptitude, when something
needs to be reported to the owner/administrator* of the host. It does
not recieve mail from any other source. And if it did, I would like to
know of that because any email arriving there from an external source
would be evidence of a security problem. But, for now, it is not
reasonable that you waste your time understanding better the strange
workings of my mind. The apology is the important thing.

Best wishes, and thanks,
Paul

*It seems strange to think of myself as system administrator, but that
is what I must be in this situation, no matter how incompetent I am at
doing the work.


-- 
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/20120216145448.ge6...@big.lan.gnu

Re: Need help dealing with the demise of qpopper [SOLVED]

2012-02-16 Thread Paul E Condon

On 20120216_113002, Chris Davies wrote:
 Paul E Condon pecon...@mesanetworks.net wrote:
  I have looked into qpopper replacement options. I'm sure setting up a
  replacement will be easy for many, but for me it presents a
  challenge.
 
 Happy to try and help you accept and overcome the challenge  :-)
 
 I'm not familiar with qpopper or the alternative I'm about to suggest,
 as I use dovecot/imap. However, popa3d seems to work here straight out
 of the box. Admittedly, I've really only tried a trivial scenario, but
 I was able to get email from /var/mail/* with local user authentication
 derived from /etc/passwd.
 
 Chris

The package, popa3d, allows me to pick up email from the host that had
been running qpopper using fetchmail and my pre-existing .fetchmailrc
. I could have been using popa3d long before this, but didn't know of
its existence.  Comparison of the documentation for the two indicates
that it is not an exact replacement for qpopper. Qualcomm popper,
qpopper, has extra features that make it 'better' than plain POP3.
But whatever the extra features are, I must not have been using them,
It works for me. Thanks.

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120216151902.gf6...@big.lan.gnu

Need help dealing with the demise of qpopper

2012-02-15 Thread Paul E Condon

I have been using qpopper on some hosts on my home LAN.  I use
fetchmail, procmail, and mutt in an arrangement that I learned about
when I first took up using Debian many years ago. qpopper allowed me
to integrate watching system error messages into my mail set up
without ever having to learn much about real email administration.  I
just installed it and these other computers became POP3 servers ready
to respond to polling by fetchmail.

I have looked into qpopper replacement options. I'm sure setting up a
replacement will be easy for many, but for me it presents a
challenge. Is there a HowTo about this?  Specifically replace qpopper
with something else in this very limited application where qpopper
worked out-of-the-box? I have one computer running Wheezy now, and
I notice that on that computer in aptitude, qpopper is listed as
obsolete or locally generated. So now I could be looking into the
replacement ahead of the release of Wheezy. But I need help.

My wish is that some kind soul will create a new package named
'qpopper' for which the description in aptitude will be something like

This is not qpopper. It is a substitute that works like the old
Qualcomm popper, but using more modern software. If you intend any
deviation from the basic Qualcomm popper install ... instead.


TIA
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120215211838.gb6...@big.lan.gnu

Re: Need help dealing with the demise of qpopper

2012-02-15 Thread Paul E Condon

On 20120216_015139, Andrei POPESCU wrote:
 On Mi, 15 feb 12, 14:18:38, Paul E Condon wrote:
 
 [snip]
 
 Don't know about POP3, but for IMAP I just installed dovecot-imapd and 
 it automatically picked up my ~/Maildir/
 I expect the same would happen with dovecot-pop3d (but I'm too lazy to 
 test).
 
 Could you give more details, like where the e-mails are stored, etc. ?
 
 Kind regards,
 Andrei
 -- 
 Offtopic discussions among Debian users and developers:
 http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic

Thanks but ...  What is dovecot? And which host is it to be installed?
Is it an MUA? An MTA? I want to pick up on my main computer the emails
that were sent to root on my other Debian computers. I used fetchmail
to do that on my mail computer and qpupper to make the other computer
responsive to fetchmail's requests. How can I continue in that mode?

When I started with Debian, emails were stored on one's home
computer. They were temporarily held in transit on a computer at one's
ISP. That is still the way I operate. I want to keep some of my
emails. I use bogofilter to help delete spam after every email is
received onto my home computer. It once was thought of as a very
common way of doing email. I had not realized that it is so old that
it is almost forgotten.

The thing that makes this 'on topic' is that it is a problem brought
on by a change in the offerings of the Debian repositories. What
can be done to maintain a system that has worked for several years?

Kind regards,
Paul
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120216011711.gd6...@big.lan.gnu

Question about ssh passwords and backup software

2012-02-13 Thread Paul E Condon

I am researching ways of setting up an automatic backup of
my several local hosts (read computers in ancient UNIX parlance).

My research has not been exhaustive, but it seems that the backup
packages that offer backup of one host by another host all involve
creating a special ssh password for the purpose that is not encripted
and therefore does not need to be decripted for use. Advice varies as
to how dangerous this is for security, but there is universal
consensus that caution should be exercised.

I have discovered an alternative to a passwordless private ssh key in
the Debian package repository. (Not a great feat for a normal Debian
user, but I am specially challenged.) The package in question is
'sshpass'. It allows one to write a script that feeds a password to
the system that needs on. And, of course, the password is hidden
somewhere on the using host in ways that can be questioned.

I want to hear expressions of opinion as to the relative merits of
having a password hidden somewhere vs. simply having no password on
the private ssh key. I know there is risk in both and both ways have
risks, but has anyone compared to two approaches and then decided to
go one way or the other based on something more than a gut feeling? If
so, what did you decide, and what were the risk factors that were
important to you?

If any of you feel that your position on this issue in not an opinion,
but a fact that is beyond argument, your response is also welcome.
 
TIA
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120213173652.ga26...@big.lan.gnu

Re: how are html pages printed?

2012-02-13 Thread Paul E Condon

On 20120213_191053, Camaleón wrote:
 El 2012-02-13 a las 11:46 -0600, Mark Copper escribió:
 
 (resending to the list)
 
  On Mon, Feb 13, 2012 at 10:18 AM, Camaleón noela...@gmail.com wrote:
   On Sun, 12 Feb 2012 16:32:49 -0600, Mark Copper wrote:
  
   I have a box where attempting to print an html page containing an image
   results in an error.
  
   (...)
  
   What kind of error, exactly? Printed output garbage, no image printed at
   all (blank data), on screen error...?
  
  A printer (HL-5250DN) generated error page with the following text:
  ERROR NAME; undefined, COMMND; Q, OPERAND STACK; null
  
  not particularly helpful --- the same error has appeared in different 
  contexts
 
 Mmm, that printer supports PCL6 and BR-Script3, a PostScript 
 implementantion from Brother. I'm not sure how PS compliant is that 
 language...
 
   Have you tried with different browsers?
  
  Yes.  Iceweasel and Epiphany.
  
   What's seen in the print preview? Are the images displayed?
  
  The page, including images, is displayed properly in the print preview.
  
  Yikes!  I have been too broad with my description of the problem.  I
  have been able to print some web pages with images properly.
 
 Ah, that's fine.
 
  It appears that the problem arises with pop-up windows.
  javascript:openWindow, and UPS label windows are specific examples
  where the printer generates an error page.
 
 I also use UPS web services and never had any problem when printing 
 their labels. I use a true PS printer which makes me think there can be
 a issue with your PPD file and the UPS on-the-fly generated code.
 
 I would try to add a new printer instance (keep the one you already 
 have, just add a new one) for the printer but using a PCL6 file instead 
 (pxlmono) and try to print the same page with it, just to compare both
 outputs.
 
 Greetings,
 
 -- 
 Camaleón 

I have a similar problem. For me, I can not print from a
Macbook. Under some conditions, which I cannot repeat, I have gotten
an error message saying that the printer has only a self signed
certificate. When I convert the pdf to a .ps format, which I think
cannot contain a certificate, I am able to print. I think my problem
relates to Apple/CUPS push toward World Dominance. YMMV

OTOH, it may be a bug in one or more packages that involve certificate
handling. But I am clueless about certificates. It was news to me that
CUPS cares about certificates. (or does it?, I don't know)

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120213193211.gb30...@big.lan.gnu

Re: Running 2 ssh instances

2012-02-13 Thread Paul E Condon

On 20120213_200321, Rob Owens wrote:
 On Tue, Feb 14, 2012 at 12:26:54AM +0100, Claudius Hubig wrote:
  Hello Sylvain,
  
  Sylvain sylvainterside...@gmail.com wrote:
  Right now I'm a bit confused by the way chroot seems to work with users. 
  I'd be grateful if someone had an idea on how to do have an ssh instance 
  running on a specific port and allowing only certain users.
  
  Check $(man sshd_config) and the AllowUser option. You should then be
  able to create a second SSHd configuration file listening on the
  appropriate port. I would then go on and maybe adapt
  either /etc/init.d/ssh slightly to also start the second server (with
  the appropriate configuration file) or create a second script doing
  the same thing.
  
 I agree with Claudius.  For your second instance of ssh, you don't need
 a chroot.  You do need:
 
 /etc/init.d/ssh.alt
 /etc/default/ssh.alt
 /etc/ssh/sshd_config.alt (and use the AllowUsers and Port options)
 /var/run/sshd.alt (although your init script may create this directory,
 if you copy the standard ssh init script)

I have been running dozens of instances of ssh simultaneously for
years without doing anything like the above. Either it is entirely
unnecessary or the Debian Maintainer has include all this in his
install script. Or maybe, like gnome-terminal, a single instance can
manage multiple indepentent windows. Either way, I have found the
number of windows to be effectively unbounded. Have you tried it?
I think you will find that it works.

HTH


-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120214050033.gc30...@big.lan.gnu

Re: A question about ssh-agent

On 20120206_121205, Vincent Lefevre wrote:
 On 2012-02-06 11:39:47 +0100, Erwan David wrote:
  On Mon, Feb 06, 2012 at 11:33:25AM CET, Vincent Lefevre 
  vinc...@vinc17.net said:
   On 2012-02-04 09:35:44 +0100, Sven Joachim wrote:
Nope, this is the script that starts the ssh *server*.  The agent is
started in /etc/X11/Xsession.d/90x11-common_ssh-agent, sourced from
/etc/X11/Xsession (see Xsession(5).
   
   But it shouldn't. It should be the user who decides whether he wants
   to start ssh-agent (since it is a user process), not the admin.
  
  Not necessarily : the user uses it or not through ssh-add.
 
 Yes, but ssh-agent is still started even if the user doesn't want it.
 On my machine, it was interfering with my own system to automatically
 start ssh-agent when needed (until I changed my config to kill this
 ssh-agent).

What config did you put you kill commands in? And what were those
commands? I'm trying to understand how this thing works.

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120206195303.ga11...@big.lan.gnu

Re: A question about ssh-agent

On 20120206_110312, Bob Proulx wrote:
 Vincent Lefevre wrote:
  Erwan David wrote:
   Vincent Lefevre said:
But it shouldn't. It should be the user who decides whether he wants
to start ssh-agent (since it is a user process), not the admin.
   
   Not necessarily : the user uses it or not through ssh-add.
  
  Yes, but ssh-agent is still started even if the user doesn't want it.
  On my machine, it was interfering with my own system to automatically
  start ssh-agent when needed (until I changed my config to kill this
  ssh-agent).
 
 This is a problem of opposing goals.  One group wants the system to be
 popular and easy to use for novices.  The other group wants it to have
 technical excellence.  It is exactly with issues such as this that
 they are opposing goals.
 
 Bob

I'm finding more puzzles than answers. When I try to ssh into big the
behavior is different from that for sshing into cmn. For big a debug
trace indicates that the had shaking and mutual indentification is
going well until there is a message

debug1: Roaming not allowed by server

Then the process switches over to asking for a password, which I
am trying to avoid. I can't find any information on Roaming. I
don't have any idea what the word might mean in this context. It
isn't mentioned in any documentation that I have searched. Any
ideas? Or leads?

If 'roaming' is not allowed, perhaps setting something some config
file will make it be allowed.

TIA
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20120206200820.gb11...@big.lan.gnu

Re: A question about ssh-agent

On 20120206_132412, Bob Proulx wrote:
 Paul E Condon wrote:
  debug1: Roaming not allowed by server
  
  Then the process switches over to asking for a password, which I
  am trying to avoid.
 
 On the server look in /var/log/auth.log and look at the messages
 logged there from the sshd.  Do you see something such as:
 
   Authentication refused: bad ownership or modes for file 
 /home/pecondon/.ssh/authorized_keys
 
 At the least hopefully there will be some useful message there.
 
 I often will start up a debugging sshd and connect to it so that all of
 the messages will be in the foreground.
 
 Bob

Here is the debug run up to where it is waiting for me to enter a password:

root@gq:~# ssh -v root@big
OpenSSH_5.9p1 Debian-2, OpenSSL 1.0.0g 18 Jan 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to big [192.168.1.11] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 
Debian-6+squeeze1
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server-client aes128-ctr hmac-md5 none
debug1: kex: client-server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 51:cf:52:87:6f:13:43:50:73:29:2c:b4:34:11:cd:5c
debug1: Host 'big' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Next authentication method: password
root@big's password: 

All the files in /etc/ssh and ~/.ssh have correct mode and ownership.
In particular .ssh/authorized_keys is readable only by owner.  Also
authorized keys does indeed contain copies of all public keys of all
machines, and it is identical to the authorized_keys file on host,
cmn, where it works and passwordless login happens correctly. I cannot
find a document that explains the meaning of the debug messages.

Previously, I had been suspicious of 'Roaming not allow ...' , but here
is the log of a successful public key login from gq into cmn:

root@gq:~# ssh -v root@cmn
OpenSSH_5.9p1 Debian-2, OpenSSL 1.0.0g 18 Jan 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to cmn [192.168.1.10] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 
Debian-6+squeeze1
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server-client aes128-ctr hmac-md5 none
debug1: kex: client-server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA d0:2e:a7:60:3e:3f:08:6c:6b:71:68:95:02:54:25:75
debug1: Host 'cmn' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1

Re: A question about ssh-agent [solved]