Re: Tool to crypt a password

[Greg Wooledge]

On Mon, Feb 06, 2017 at 05:28:39PM +0100, Nicolas George wrote:
> Does anybody know a packaged program that provides a simple but good
> interface to the libc's crypt() function?

I wrote this many years ago.  It's primitive, but may suit:

http://wooledge.org/~greg/crypt/

> [...] a packaged program [...]

Oh  Um.  No?  Or, you could package it yourself?  I guess that's not
what you actually meant though.  I guess you meant "something that can
be installed on someone else's computer without freaking them out".

Re: Best way to set maximum number of open descriptors for a process

[Greg Wooledge]

On Wed, Feb 08, 2017 at 09:26:14AM -0300, Daniel Bareiro wrote:
> The process starts as a service, so it does not require a shell:

> I had thought that I could add something to the script that starts the
> process, but I'm not sure if it's the best idea from the point of view
> of maintainability because a package update could eliminate that change.

I believe the correct approach is to add one of the limit= directives
to the systemd unit.  See systemd.exec(5) for details.  Searching for
the word "limit" gets you to the correct section.

Re: Debian/Stretch: how to boot in text mode

[Greg Wooledge]

On Wed, Feb 01, 2017 at 09:21:16PM +0100, Ennio-Sr wrote:
> After upgrading to Stretch I'm unable to find a way to boot with no GUI.
> I tried setting 'GRUB-GFXPAYLOAD_LINUX="text" in /etc/default/grub,
> moving to 'K01gdm3' all 'S??gdm3' instances in /etc/rc?.d, but nothing
> happens.
> Any help, please?

The easiest way is to remove whatever display manager is running by
default.  This works in every version of Debian and is super easy.

However, some people want to keep the display manager installed, but
prevent it from running at boot time.  This is much more difficult
and will involve understanding how your init system works.

In jessie and stretch, the default init system is called "systemd".
It doesn't use /etc/rc*.d/[KS]* symlinks to control services.  Instead,
you use commands to control it:

systemctl status gdm3
systemctl disable gdm3
systemctl stop gdm3

and so on, where "gdm3" is the name of the service that you want to
manage.  See "man systemctl" for some more details on that particular
command, or "man systemd" for a more general starting point.

There may even be some special magic required for display managers,
above and beyond the init system.  If systemctl disable doesn't work,
then report back and let us know which DM it is.  Maybe someone will
know the magic involved in disabling it.

... or you could just remove the package.  That will always work.

Re: hostname drops off between remote sessions

[Greg Wooledge]

On Sun, Jan 22, 2017 at 12:48:19PM -0500, Tony Baldwin wrote:
> I rent a VPS from Contabo, in Germany (as if the location were 
> relevant), which is still running wheezy.
> Lately, when I access it (generally via ssh) the hostname appears to be 
> changed to (none).

Edit (or create) the file /etc/hostname with the hostname that you want.
Then reboot, or use the command "hostname yourhostname" (as root) to set
the hostname.  (But really, you probably want to reboot, to make sure any
daemons that read the hostname at startup get a valid hostname.)

Re: An Embarrassing Progblem

[Greg Wooledge]

On Mon, Jan 23, 2017 at 02:43:12PM -0500, S. P. Molnar wrote:
> I added PS1="\u@\h >" to the end of .bashrc and sourced the file -  it 
> worked, in that terminal.  However, if I open a new terminal (I'm using 
> xfce4-terminal) the prompt is back to the corrupted one!

Normally when you open a terminal, it *should* run a non-login shell.
If your account's shell is bash, then the non-login shell will read
~/.bashrc.

However, some people configure their window managers to run a login
shell when they open a terminal.  In that case, if your account's
shell is bash, the login shell will read ~/.bash_profile which in
turn *should* be configured to read ~/.bashrc.

So, make sure ~/.bash_profile or ~/.profile sources or dots in
~/.bashrc.  Debian's default ~/.profile does so, but if you created
a ~/.bash_profile, that overrides ~/.profile, so you'd have to check
your own work.

> Rebooting the computer doesn't solve the problem.

Not a surprise.

> I have initiated a search of the entire file system for PS1= , although 
> I suspecct it take a while.

You said the new prompt has p4 in it, which makes me suspect that you
have installed something (like, say, p4) which modified your ~/.bashrc
to change the prompt.  Or it might have modified /etc/bash.bashrc which
Debian's bash also uses.  It's worth looking at it.

Re: Installing a package downloaded from snapshot - was [Re: Mate error message under Debian 8.6.0]

[Greg Wooledge]

On Fri, Jan 27, 2017 at 02:50:40PM -0600, Richard Owlett wrote:
> Abysmal failure.

I have had enough of this bullshit.  Richard, you are a toxic person.
You give the human race a bad name.  Every HONEST effort to help you has
been met with insults.  You suck the time and energy from those who had
only the best and truest motives, and repay them with misery.

Go away.  Don't come back.

I actually started investigating how to killfile YOU the other day,
but it turned out there was no clear, easy answer, so I put the notion
on the back burner.  You're making me want to revisit this project.

To the rest of you who have more patience than I do: I apologize for
wasting your time.  But he's been pushing me WAY past my limits for an
extremely long time now.

Re: Using source packages to bring some programs up to latest version

[Greg Wooledge]

On Mon, Feb 20, 2017 at 10:52:37PM +, Jonathan Dowland wrote:
> The best way to achieve this is to use backports, if one exists for the
> packages you are interested in.
> 
> Failing that, it's possible that the version of the package in testing or
> unstable can be installed on your stable system without pulling in any (or too
> many) dependencies from outside stable.

No, stop.  The second step if there is not already a backport is to try
to backport it yourself.  Maybe ask judd in IRC first, whether a backport
is believed to be *possible*.  Sometimes the bot is wrong, but it's a
starting point.  If judd thinks all the dependencies are satisfiable,
then you can try the backport.

If a backport isn't possible, I would actually prefer to build the package
normally from upstream source code (./configure; make; sudo make install)
than to install a binary from testing/unstable onto stable.

Re: Whats the alternative to .xinitrc

[Greg Wooledge]

On Mon, Feb 20, 2017 at 01:32:37PM +0100, Vincent Lefevre wrote:
> I don't see any contradiction to what I've said. Note that I haven't
> mentioned .xsessionrc at all, only .xinitrc, which is a different
> thing.

OK, short version: forget .xinitrc ever existed.  Use ~/.xsession unless
that doesn't work.  See https://wiki.debian.org/Xsession

Long version:

You can either log in on a text console and run startx to start X,
or you can login through a GUI display manager.  Of which there are
a whole bunch.

Either way, Debian reads ~/.xsessionrc first.  You should use that to set
variables like PATH in the X environment, since display manager logins
don't read your shell dot files.  Don't use .xsessionrc to start window
managers or desktop environments, though.

If you use startx, then AFTER .xsessionrc, Debian will read the
~/.xsession file.  Use that to start your X client programs and then
to exec your window manager.

If you use a display manager, then .xsession may or may not be used.
Who knows.  There are too many of them to keep track.  You can try it,
and if it works, great.  Otherwise, you'll have to figure out which file
to use for your specific DM or your specific desktop environment or your
specific window manager or who knows what.

The original X display manager, cleverly named xdm, reads .xsession.
But people weren't happy with just having one display manager, so they
made more.  Obviously each "desktop environment" needed its own display
manager.  Why?  Why not!  Everyone likes random change for the sake of
change, don't they?!

Anyway, this is why I use startx and fvwm.  It Just Works(tm).
Consistent operation for two decades.  No bizarre surprises.

Re: Whats the alternative to .xinitrc

[Greg Wooledge]

On Mon, Feb 20, 2017 at 04:02:50PM +0100, Vincent Lefevre wrote:
> More precisely, if I understand correctly,
> 
> 1. The DM can request some window manager (for instance, the user has
>the choice between several ones, and he may also choose the default
>session file, or whatever has been used last). If a choice has been
>done, then /etc/X11/Xsession.d/20x11-common_process-args will define
>$STARTUP based on this choice.
> 
> 2. If there wasn't a specific request, then when
>/etc/X11/Xsession.d/50x11-common_determine-startup is sourced,
>$STARTUP is still empty. In this case, $STARTUP is defined there
>in the following way.
> 
> 2a. If /etc/X11/Xsession.options contains allow-user-xsession (which
> isn't the default, AFAIK), then $STARTUP is set to the user
> session file, normally "$HOME/.xsession", as /etc/X11/Xsession
> contains: USERXSESSION=$HOME/.xsession
> The window manager should be started from this script.
> 
> 2b. Otherwise, the following executables are tried in succession:
>   /usr/bin/x-session-manager
>   /usr/bin/x-window-manager
>   /usr/bin/x-terminal-emulator

I believe this is what I documented on https://wiki.debian.org/Xsession
If the wiki doesn't reflect your understanding of the scripts, then it's
possible that one of misread them, and we can work on getting the wiki
into a more accurate (or more clear) state.

I also used the Debian reference manual, linked from that page, and
"man Xsession", while trying to figure out how this stuff works.  I did
not go through the extra steps of installing and removing various display
managers and desktop environments in order to reverse engineer them.
My dedication to this cause has limitations.

> Note: since window managers can also start X clients on start up,
> a .xsession file may not be useful for everyone.

It's a crazy mixed-up world.

Re: Whats the alternative to .xinitrc

[Greg Wooledge]

On Mon, Feb 20, 2017 at 01:13:09PM +, Rob Brewer wrote:
> Thank you for your explanations, I must admit that I didn't expect it to be 
> so involved. I seem to remember mapping out the X startup processes a number 
> of years ago but I was running RedHat then, so I suppose it has changed a 
> lot in the meantime.

Debian's Xsession is not the same as Red Hat's.

If you need a home directory that will work consistently across different
operating systems, then I *strongly* suggest you stick with startx and
make .xinitrc a symlink to .xsession for backwards compatibility.  Any
attempt to reverse engineer and consolidate different display manager +
Xsession combos across multiple operating systems is likely to lead to
mental breakdown.

Re: Last spam: Let me know Munich Mayor's email address, please..

[Greg Wooledge]

On Fri, Feb 17, 2017 at 10:25:41AM -0500, Gene Heskett wrote:
> That may be true, but I am driven to quote Benjamin Franklin here, 
> with "Democracy is a very bad form of government, but all the others are 
> so much worse."

You're thinking of Winston Churchill: "Indeed, it has been said that
democracy is the worst form of Government except all those other forms
that have been tried from time to time."

See also https://en.wikiquote.org/wiki/Benjamin_Franklin#Misattributed

Re: Stretch stable and jessie testing - repositories listed

[Greg Wooledge]

On Thu, Feb 09, 2017 at 08:46:14PM +, Brian wrote:
> Mind you, stable is Jessie and Jessie
> is stable. It's only testing/whatever you have to be careful about.

"jessie" and "stable" are synonymous for the moment, but that will not
continue indefinitely into the future.  When stretch releases, they
will stop being synonyms.  Just like "stretch" and "testing" will stop
being synonyms.

Re: An Odd File Name

[Greg Wooledge]

On Mon, Feb 13, 2017 at 11:06:24AM -0600, Martin McCormick wrote:
>   I downloaded a file from a site using lynx and the file
> name is "InstallingGRFromSource#Using-the-build-gnuradio-script.gz"
> Actually, the double quotes are here for clarity but the name is
> as it appears including the # sign.  Ls sees it and rm -i would
> remove it if I let it but if I do:
> 
> gunzip InstallingGRFromSource#Using-the-build-gnuradio-script.gz
> 
> or
> 
> ls InstallingGRFromSource#Using-the-build-gnuradio-script.gz
> 
> bash can't find/see the file.

The # character is only a comment indicator in bash when it appears
at the start of a word, not in the middle.  That's why ls and rm have
no problem with it.  Therefore bash has no problem with it, because
clearly bash is passing the filename intact to ls and rm.

If gunzip has a problem with it, then I would suggest you simply rename
the file.

Re: Stretch stable and jessie testing - repositories listed

[Greg Wooledge]

On Thu, Feb 09, 2017 at 12:29:00PM +, GiaThnYgeia wrote:
> It may seem silly to most of you but not very clear.  If in the synaptic
> repository list one has used testing in Jessie

What?!

> by now the system has
> converted fully (99.99%) to Debian 9 Stretch.  Right?

If you want to run stretch, then you should put "stretch" in your
sources.list.  Currently this is the same as testing, but when stretch
is released, you will be running Debian 9, and you will stay there until
you choose something else.

If you want to run PERPETUAL testing, never stabilizing, always
half-broken, then you should put "testing" in your sources.list.

If you put EITHER of these things in your sources.list, EVER, then you are
NOT running jessie.  It is completely nonsensical to write a phrase like
"testing in jessie".  You are running testing, or you are running jessie,
or you are running neither.

Re: HELP! Re: How to fix I/O errors?

[Greg Wooledge]

On Wed, Feb 08, 2017 at 06:06:34PM -0500, Ric Moore wrote:
> Careful there, I would not copy any of the /home/username/dot-files or 
> dot directories over, except like .mozilla and .thunderbird, so you 
> don't carry over some old and crufty setting that might have been 
> problematic.

I have the exact opposite philosophy.  My home directory has survived
across many, many different operating systems and computers.  If a
new version of some app breaks compatibility with a dot file, which
is rare, then I'll handle that on a case by case basis.  Otherwise,
I get to keep all of my comfortable settings.

Re: Stretch stable and jessie testing - repositories listed (new pkgs under freeze)

[Greg Wooledge]

On Fri, Feb 10, 2017 at 10:43:00AM +, GiaThnYgeia wrote:
> If I understand the freeze process well (I think I
> don't) why would updated packages appear today on the list?

The freeze means that only bug fixes go in.  No new upstream versions,
unless it's a very special case.

Re: Stretch stable and jessie testing - repositories listed

[Greg Wooledge]

You forgot to reply to the list.

You forgot to stop top-quoting.  This is a real mailing list, not your
workplace where you have to do everything upside-down.

On Thu, Feb 09, 2017 at 02:20:00PM +, GiaThnYgeia wrote:
> So the location of the ***debian.org/ does not ever change, it remains
> the same.

Here is a jessie source:

deb http://ftp.us.debian.org/debian/ jessie main non-free contrib

Here is a stretch source:

deb http://ftp.us.debian.org/debian/ stretch main contrib non-free

> If on the original installation of Jessie you switch from
> main to testing you are running stretch, right?

You DO NOT touch the word "main".  You change the word "jessie".

If you change from "jessie" to "stretch" and then run apt-get update
and then run apt-get dist-upgrade, then you are running stretch.

> If you substitute
> testing with the word stretch you would be remaining on stretch stable
> once it is released.

Yes.

> I am just trying to verify I will be doing the
> right thing and not mess up and end up in sid and have no way back.

Then don't use "sid" or "unstable".

> That is why I said be specific and you are jumping on me (What? EVER
> EITHER, PERPETUAL...) What is perpetual anyway?  Is that a name of
> another system?

Perpetual is an English word.  It means "never-ending" or "eternal".

If you use "testing" instead of "stretch", then you are perpetually
stuck in testing, never to stabilize, always half-broken.

> You can put anything you like in the repository list but unless you
> reload the database and update what can be updated/replaced nothing will
> ever change, correct?

I don't speak GUI.

If you edit the /etc/apt/sources.list file, nothing changes until the
next time you run one of the apt commands.  That doesn't mean you should
go around altering files just for grins.  You should act as though
your changes to sources.list are going to take effect moments after
you make them, because that's usually how people do things: edit file,
run commands.

I can't even guess what happens if you edit the file while you are already
running synaptic, which is one of the apt commands.

I don't know or care what happens if you alter the file from within
synaptic.  I didn't even know that was POSSIBLE.

I can't imagine why someone would attempt to do system administration
with a GUI.  Even if you somehow manage to jump through the hoops
required to get a GUI process running as root to communicate with your X
server in a session run by yourself, you're still doing sysadmin work
while in X, which is not likely to end well.

Don't the release notes strongly advise that you do release upgrades
OUTSIDE of X?  I thought they did.  It's been a while since I read them.

> At least that is how I understand it works, if
> not please DO correct me.
> 
> Katrin

I just can't see why it matters.  If you don't intend to perform the
upgrade, don't change the file.

Re: HELP! Re: How to fix I/O errors?

[Greg Wooledge]

On Thu, Feb 09, 2017 at 12:03:18PM -0500, Ric Moore wrote:
> How so?? Don't "many other operating systems" have different 
> configuration files in many other locations?? I wouldn't expect BSD 
> config files to migrate to Linux, or Windows to do anything useful.

When I shared my $HOME between OpenBSD and Debian for a time, I didn't
have many problems at all.  There are some shell functions that I only
created when $(uname -s) was Linux, but that's about it.

Most of the command-line tools that use dot-files in $HOME are the same.
Just stick with the older-common-denominator syntax in things like
~/.muttrc and and ~/.ssh/config and you should be fine.  (Hint: when
mixing Debian with other non-legacy Unixes, usually it'll be Debian that
has the older version of the tool.)

You shared your philosophy ("tear it all down and rebuild it from scratch
every two years") and I shared mine ("keep everything unchanged until
you are forced to change it").  Neither one is right, and neither one
is wrong.  I just wanted both viewpoints to be equally represented.

Re: how to compute predictable network interface names?

[Greg Wooledge]

On Thu, Feb 16, 2017 at 12:47:25PM +0100, Christian Seiler wrote:
> On a system with predictable names running? Or on a system
> pre-upgrade?
> 
> Because if you have a system that's being upgraded at the
> moment, the following command _might_ work _after_ you've
> upgraded udev and _before_ you've rebooted the system.
> 
> udevadm info /sys/class/net/eth4
> 
> Look at ID_NET_NAME there.
> 
> Can't really test that though, since I don't have a setup
> with the old scheme that I still need to upgrade, so this
> might not work at all.

I'm a bit confused here.  On a system that's upgraded from jessie to
stretch, why would the interface names change at all?  The old eth0
style names are recorded in /etc/udev/rules.d/70-persistent-net.rules
and the interfaces continue to come up as eth0, etc.

Are you talking about a scenario where you upgrade to stretch and then
add a new NIC?  But even then it still wouldn't make sense, because
you wouldn't have had a previous "eth4" name that you want to map to a
new name.  You'd just get the new name.

Or are you talking about a hypothetical scenario where you upgrade to
stretch and then remove the contents of
/etc/udev/rules.d/70-persistent-net.rules, but before you do that, you
want to see what the interfaces will become?  That seems... quite odd
to me.  Why not just leave the interfaces alone?

Re: User-oriented backup tools

[Greg Wooledge]

On Wed, Feb 15, 2017 at 11:37:40PM +0100, Francesco Porro wrote:
> At this time I feel comfortable with rsync, which I use to sync my home
> to an external Usb drive. No automation, no scheduling for now. I just
> launch rsync from the command line and let it backup all the stuff when
> I need it.

This is what I do, too.  Except I also rsync changes from my VPS, and
also make a second copy of parts of the data and burn that to a DVD+RW.

> Now I'd like to move to more powerful utility.

Why?  What do you want to do that your existing solution doesn't do?
Just swapping out a working solution for something more complex without
some compelling reason is not a good idea.

Re: hostname drops off between remote sessions

[Greg Wooledge]

On Mon, Jan 23, 2017 at 12:33:55PM -0500, Tony Baldwin wrote:
> Perhaps it is these Daemons that are not doing their job(?), because 
> I'll set the hostname (as root with "hostname $myhostname", or editing 
> /etc/hostname, I've done both), and on reboot, it returns to (none).

Anything you set with the hostname command is transient.  The /etc/hostname
file is permanent.

If the contents of /etc/hostname are not being used as the hostname
at boot, then there is something wrong with your start-up scripts.
This is where we get to the advice about verifying the integrity of
/etc/init.d/hostname.sh as you had stumbled upon earlier.

On my own wheezy VPS:

greg@remote:~$ ls -ld /etc/init.d/hostname.sh 
-rwxr-xr-x 1 root root 1423 Mar 27  2012 /etc/init.d/hostname.sh

greg@remote:~$ ls -ld /etc/rc*/*hostname*
lrwxrwxrwx 1 root root 21 Nov 28  2012 /etc/rcS.d/S06hostname.sh -> 
../init.d/hostname.sh

Of course, wheezy may not be using sysvinit (there was an option to
use a "technology preview" of systemd, and I think there's another
option as well whose name I can't remember).  If you're not using
sysvinit on wheezy, then things might become extremely interesting
for you, as you try to track down the problem.

Re: What in /var/logs shows system reboot?

[Greg Wooledge]

On Mon, Jan 23, 2017 at 02:12:04PM -0400, francis picabia wrote:
> I'm running Debian 8.6, and looking at old logs.  I'd like to confirm when
> the system was rebooted to invoke the newer kernel which fixed
> the Dirty COW bug.

last | grep boot

or, apparently (according to the man page):

last reboot

> If I have a complete
> copy of my /var/log from last October,

Urghhh.  So it's not on a live system?  It's on a chrooted disk image?
Then I think you need to use:

last -f /some/path/wtmp reboot

where /some/path/wtmp is the location of your chrooted disk image's
wtmp file.

Re: An Embarrassing Progblem

[Greg Wooledge]

On Mon, Jan 23, 2017 at 01:27:05PM -0500, S. P. Molnar wrote:
> I have found plenty of Google results about correcting thei promled, 
> and, indeed export PS1='\u@\h > ' restores the prompt - that is, until I 
> close that terminal.  The next time I open a terminal the prompt is back 
> to (p4env).

Put the PS1=... command that you want into your ~/.bashrc file, removing
any other PS1 assignments that you don't want.

Some people prefer to export PS1 in ~/.bash_profile instead of simply
assigning it in ~/.bashrc -- either way is acceptable, if it works
for you.

Re: What in /var/logs shows system reboot?

[Greg Wooledge]

On Mon, Jan 23, 2017 at 08:28:08PM -0400, francis picabia wrote:
> Here is the exercise anyone reading can try:
> 
> Prove to yourself exactly when you rebooted your Debian system(s)

arc3:~$ uptime
 08:44:40 up 8 days, 31 min,  1 user,  load average: 0.02, 0.02, 0.00

Everything's easy on a live, running system.

> to ensure you were safe against dirty cow.

Oh, *that*?  In that case, you don't give a flying leap how long ago you
rebooted.  What you care about is the *exact running kernel version*.

arc3:~$ uname -v
#1 SMP Debian 3.16.39-1 (2016-12-30)

Then you compare 3.16.39-1 against the changelog.Debian.gz to see if it's
got the bug fixes you want.

http://mywiki.wooledge.org/XyProblem

Re: How to find out the current display manager?

[Greg Wooledge]

On Mon, Jan 16, 2017 at 11:42:17AM -0500, kamaraju kusumanchi wrote:
> Background on why I need this:
> I am developing a script[1] that gathers relevant system information
> depending on what issue a debian-user is facing.

That's pretty ambitious.  Good luck.

> Thanks. It looks like all I need is to find the parent process of
> Xorg. In my case, that would be lightdm.

There may not even be an "Xorg" process, if the user is doing something
unusual, like running a really old version of Debian (XFree86), or a
proprietary X server, or a really new version of Debian with Wayland(??),
or if the user is not currently able to get X to run at all.

Obviously, if X can't start up at all, you're going to have a very hard
time detecting a running display manager process.  So we'll get back
to that

For the absolutely normal course, where the user is logged into X through
a display manager and is running your script inside that X session,
what you should probably do is recurse up through the process tree
(following ps -o ppid,cmd "$pid" step by step) until you run into a
process that you recognize as being a display manager, or until you
hit PID 1.

If you don't find a display manager that way, then your second try can
be "look for a running X server, and then look for its parent, and see
if it looks like a display manager".  That will catch the cases where
a display manager is running, but the user isn't logged in through it
for whatever reason.  Or where the user isn't running your script inside
an X session.

Third try can be looking for *any* running process that appears to be a
display manager.  Maybe that'll catch something like "display manager
is running a Wayland session, but user is not logged into it" more often
than it generates false positives.  Who knows.

Fourth try can be parsing dpkg -l (or similar) output to look for any
installed package that looks like a display manager.  Of course in
that case you'll also have to parse the status flags ("hi" or "rc"
or whatever).  This may catch the cases where X can't run due to drivers
being wrong, or no mouse plugged in, or whatever.

Re: NFS msg: Unable to find suitable address

[Greg Wooledge]

On Thu, Jan 19, 2017 at 11:29:37AM -0600, Dennis Wicks wrote:
>   > PING robin.netgear.com (192.168.254.62) 56(84) bytes of data.
>   > 64 bytes from robin.netgear.com (192.168.254.62): 
> icmp_seq=1 ttl=64 time=0.472 ms
>   > sudo mount //192.168.254.62/znfs/edrv -o user=,password= 
> /mnt
>   > Unable to find suitable address.

You're still using Windows syntax.  Use NFS syntax instead.

mount -o user=,password= robin.netgear.com:/znfs/edrv /mnt

//robin/ = Windows
robin:   = NFS

Re: Frequent Hash Sum mismatch on jessie-backports with apt-get update

[Greg Wooledge]

On Thu, Aug 18, 2016 at 12:33:27PM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 18 Aug 2016, Greg Wooledge wrote:
> > Now, starting last week, the problem is that when I try to apt-get update,
> > the files coming from security.debian.org HANG at 100% complete.  It
> > looks something like this:
> 
> While it really might be something else completely, the anti-virus
> function of an "UTM" box (firewall+av+ips+ids+content filter+kitchen
> sink) box is your first suspect.
> 
> You could try using https. It might help, or it might make matters much
> worse.

Around 10:30 this morning, it started working again all on its own.  I'm
guessing one of the networking people restarted something.

There is a phenomenon in one of the online communities that I engage with.
A sort of wink-nudge superstition, if you will: "If you want something
to happen, complain in chat about it not happening."  Posting in IRC
didn't work in this case, but apparently posting to debian-user worked.

Re: The same environment variables everywhere

[Greg Wooledge]

On Sun, Feb 26, 2017 at 02:26:08PM +0200, Teemu Likonen wrote:
> I would like to hear some ideas on how to set various environment
> variables (PATH, MANPATH, EDITOR etc.) in one place that would make them
> effective everywhere. My "everywhere" means:
> 
>   - X session started through lightdm and ~/.xsession script
>   - Linux console login (bash)
>   - user's systemd services

The last one is simply not going to happen the way you seem to expect.
You should change the jobs launched by systemd to dot in the appropriate
file, instead of expecting systemd to load some interactive shell config
automatically.

As for the first two... well.  You know WHY there is a separation, right?
People put crap in .profile that would not work properly in an X config
file, because there is no terminal.  For example, /usr/games/fortune,
or something that probes the terminal settings.  The complete absence of
an underlying terminal, not to mention a TERM variable, would make many
.profile files fail, which is why .profile is not read by X startups.

However, if *you* have personally vetted your .profile and believe that
it will run safely in an X startup environment with no terminal, then
you can simply dot it in from ~/.xsessionrc and voila.

(Do not confuse ~/.xsessionrc and ~/.xsession; they are very different.)

Re: good LDAP resources

[Greg Wooledge]

On Sat, Feb 25, 2017 at 02:16:27PM -0800, bri...@aracnet.com wrote:
> I need to set-up some sort of password server for a small network so that i 
> don't have to set-up accounts on every machine.
> 
> It looks like LDAP is the best way to do that.
> 
> Is it ?

For a small network where security isn't an enormous concern, NIS is a
whole lot easier.

Re: Jessie (8.0) slow to boot

[Greg Wooledge]

On Wed, Aug 31, 2016 at 09:16:00AM -0500, Richard Owlett wrote:
> What's going on?
> Are the messages that scroll past preserved anywhere?

When booting with systemd, the boot messages are stored in RAM
automatically, and can be viewed by running "journalctl" as root.
I'd definitely start there.

Re: Jessie (8.0) slow to boot

[Greg Wooledge]

On Wed, Aug 31, 2016 at 09:58:39AM -0500, Richard Owlett wrote:
> Aug 31 09:13:32 deb8-2ndtry systemd[1]: Job 
> dev-disk-by\x2duuid-0a344714\x2dae06\x2d43ed\x2daf89\x2d33ba51934630.de
> Aug 31 09:13:32 deb8-2ndtry systemd[1]: Timed out waiting for 
> device dev-disk-by\x2duuid-0a344714\x2dae06\x2d43ed\x
> Aug 31 09:13:32 deb8-2ndtry systemd[1]: Dependency failed for 
> /dev/disk/by-uuid/0a344714-ae06-43ed-af89-33ba5193463
> Aug 31 09:13:32 deb8-2ndtry systemd[1]: Dependency failed for Swap.

Look for swap partitions defined in /etc/fstab and see if one of them
is on a device that no longer exists (or exists only intermittently,
such as a removable USB drive).  Chances are you'll find one with
UUID=0a344714-something on it.  Try commenting it out.

Re: Security Updates

[Greg Wooledge]

On Wed, Aug 31, 2016 at 08:16:45AM -0700, Larry Dighera wrote:
> Have you even looked at the information here:
> ?  After reading
> that announcement, how can you continue to insist that I am not running Debian
> Jessie?  

1) It's not on a Debian web site.  It's on someone else's web site.
   Imagine if I posted a link from www.microsoft.com that said
   "Debian is on the decline; switch to Windows 10".  Would you
   consider that an authoritative statement about Debian?

2) It says "The Raspbian operating system is based on Debian Linux,
   and the different versions of Debian are named after characters
   from the Toy Story films. Recent versions of Raspbian have
   been based on Debian Wheezy (the penguin who's lost his squeaker
   in Toy Story 2), but Raspbian has now been updated to the new
   stable version of Debian, which is called Jessie."

Note that it says "based on Debian".  It isn't Debian.  It's a derivative.

Attempting to use security packages from Debian on a derivative system
(which is *not* Debian) may not work properly.  To get the correct
security packages for your system, you need to talk to the Raspbian folks,
not the Debian folks.

Re: Jessie (8.0) slow to boot

[Greg Wooledge]

On Wed, Aug 31, 2016 at 11:00:27AM -0500, Richard Owlett wrote:
> On 8/31/2016 10:06 AM, Greg Wooledge wrote:
> >Look for swap partitions defined in /etc/fstab and see if one of them
> >is on a device that no longer exists (or exists only intermittently,
> >such as a removable USB drive).  Chances are you'll find one with
> >UUID=0a344714-something on it.  Try commenting it out.
> 
> Commented out relevant line on both machines.
> They both boot promptly now ;/

OK, good.  Now the final step is to review your fstab vs. your actual
disk partitions and add whatever you may be missing (e.g. a swap
partition whose UUID got changed, as someone else speculated).

Re: Jessie & Fixed IP Address

[Greg Wooledge]

On Thu, Sep 08, 2016 at 06:08:04PM +0100, David wrote:
> I am working with a Raspberry PI running Jessie and I'm not happy about
> the solutions I found to change it from DHCP to a fixed IP address.
> 
> Can I go back to the old method of editing /etc/network/interfaces

If it's Debian Jessie, then yes, you can edit /etc/network/interfaces.
Change the line that says something like "iface eth0 inet dhcp" to
"iface eth0 inet static", and add indented lines below that for the
address, netmask and gateway.  Then configure your /etc/resolv.conf
file to point to some valid nameservers.

If it's Raspbian Jessie, which is not the same as Debian Jessie, then
all bets are off.

Re: How to diagnose an "apt-get instal"l problem

[Greg Wooledge]

On Fri, Sep 09, 2016 at 10:18:22AM -0500, Richard Owlett wrote:
> As root I attempted to do
>   apt-get install mate-desktop-environment-core
> It began normally but terminated with a file not found message 
> before coming to the confirm installation step.

And the error message said...?

> To narrow down the problem source(s) I attempted to install a 
> different program.

Instead of reading the error.  *sigh*

> How can I diagnose what went wrong when I attempted "apt-get 
> install"?

By reading the error.

There is not enough information here to tell whether it was trying to
install a package that isn't physically included on your DVD, or
installing a package that exists but has an error in it, etc.

Re: Systemd and Init was Problems communicating with and between servers after upgrade - correction

[Greg Wooledge]

On Mon, Sep 12, 2016 at 07:32:52PM +0100, Clive Menzies wrote:
> However, studying documentation on systemd v init, I'm a bit confused. I 
> assumed the reinstall would implement systemd for all services and init 
> wouldn't be visible although symlinks will use init where necessary. 
> systemd-sysv is installed as per the Debian wiki.

Most of the common server-oriented packages in jessie have systemd
units written for them.  E.g. openssh-server:

~$ dpkg -L openssh-server | grep systemd
/lib/systemd
/lib/systemd/system
/lib/systemd/system/ssh.service
/lib/systemd/system/ssh.socket
/lib/systemd/system/ssh@.service

However, there are still several packages that were not updated to use
systemd facilities in time for jessie.  These packages still ship with
sysvinit scripts.

When a given service has sysvinit script and does *not* have systemd
unit files, it falls back to the sysvinit scripts.

> Looking at other setups on the net, a ps aux should assign the first 
> process (1) to systemd but on server_M it is /sbin/init
> 
> Is this right?

The kernel still runs /sbin/init because the systemd changes are not
intrusive all the way up inside the kernel.  Thus, the kernel does not
know or care which init system you're using.

On a jessie-systemd (default) installation, /sbin/init is a symlink:

~$ ls -ld /sbin/init
lrwxrwxrwx 1 root root 20 Mar 12  2016 /sbin/init -> /lib/systemd/systemd

Re: xaralx package

[Greg Wooledge]

On Thu, Sep 15, 2016 at 05:03:23PM +0100, Michael Fothergill wrote:
> ???http://www.xaraxtreme.org/download.html???

  "The binaries we distribute require libstdc++ version 5, which is not
  installed as standard on some modern distributions (for example Ubuntu
  5.10)."

https://en.wikipedia.org/wiki/Ubuntu_version_history#Ubuntu_5.10_.28Breezy_Badger.29

  "Ubuntu 5.10 (Breezy Badger), released on 12 October 2005"

"Modern", they say.  Heh.

If you can *get* it to compile at all, that seems like the best path.
APIs may have changed, especially with C++.

Re: xaralx package

[Greg Wooledge]

On Thu, Sep 15, 2016 at 04:51:28PM +0200, Dominique Dumont wrote:
> $ ldd xaralx

ldd actually needs a path to the executable.  It doesn't search $PATH.

$ ldd "$(which xaralx)"

would be one way to do it.

Re: xaralx package

[Greg Wooledge]

On Thu, Sep 15, 2016 at 04:13:27PM +0100, Michael Fothergill wrote:
> mikef@rhinoceros:~/Documents/xaralx/bin$ ldd "$(which xaralx)"
> ldd: ./: not regular file

Sorry.  I didn't realize you were cd'ing into the directory where
the file was, and that this directory was not in your $PATH at all.

Based on your other response, it looks like you might be trying to run
an i386 (32-bit) program on an amd64 (64-bit) installation.  If that's
the case, you need to set up multiarch support:

https://wiki.debian.org/Multiarch/HOWTO

Re: SMTP relay issue with emails to specific domain

[Greg Wooledge]

On Fri, Sep 09, 2016 at 08:58:15PM +0100, Joe wrote:
> An email client connects to its SMTP smarthost using SMTP, so there's no
> way a given SMTP server can tell whether it's a client (MUA) or another
> SMTP server (MTA) trying to connect to it.

That's outdated information.

SMTP is used to exchange messages between mail servers (MTAs), but
a client submitting a new message to its designated relay may use
the "Submission" protocol on port 587 instead.  (Really old clients
may still use SMTP.)

Relay control is a pretty important, nontrivial field.  Some servers
rely on an "SMTP AUTH" protocol that involves a username and password
to authenticate the client.  A few may still use the old "POP before SMTP"
hack, in which a client that performs an authenticated POP3 retrieval
opens up permission to use SMTP for some time period.  I don't know
how widespread this practice still is; it's quite antiquated.

And of course some servers may simply whitelist their clients by IP
address.  This works extremely well in internal corporate settings,
but very poorly if you have people working from home, on the road, etc.
(I've seen the phrase "road warriors" used to refer to these clients.)

Internet service providers probably use some variant of this, magically
knowing who their customers are by IP address.  This is outside of my
experience.

DJB proposed authenticating client emails by having them be PGP-signed,
with the server holding the public keys necessary to validate the
clients' signatures.  I've never seen this actually implemented, though.

So, long story short, you have to get permission to use a given host
as your mail submission/relay.  And how you do that is up to the owner
of that host.

Re: Failed to execute child process (no such file or directory), but the script DOES exist in $HOME/bin, openbox users, especially take a look, please.

[Greg Wooledge]

On Mon, Sep 26, 2016 at 10:19:27PM +0100, Brian wrote:
> But now we have
> 
>  > User configuration may be done in a few different ways. The simplest
>  > way is to create a ~/.xsessionrc file,.
> 
> The pedantic side of me asks - why is it the simplest way? And in what
> cirumstances?

Because it's *additive*.  It's just some stuff that happens in addition
to the system launching your default WM/DE, and whatever else the
system does by default (setting up an ssh-agent?  I don't even know).
You don't have to do all of those things yourself.

Just counting lines of code in the most ridiculously oversimplified
cse, it should be obvious that

PATH=~/bin:$PATH

is simpler than

PATH=~/bin:$PATH
exec x-session-manager

Two is more than one.

>  > Finally, note that the ~/.xsession file is only read if you
>  > are using a Debian X session. If you login with gdm3 and
>  > choose a GNOME session, the ~/.xsession file will be ignored
>  > completely. (But you may still use ~/.xsessionrc.)
> 
> Not observed in testing. /etc/gdm3/Xsession also has a stanza beginning
> "SESSIONFILES=$(run_parts $(SYSSESSIONDIR)" which also appears to
> contradict this statement. SYSSESSIONDIR is /etc/X11/Xsession.d.

If I've made factual errors, please correct them.  I'm trying my best to
piece together how gdm3 works based on the existing documentation (written
by Overfiend over a decade ago), and other, older wiki pages which may
themselves be incorrect, and my extremely limited past knowledge of gdm.
Note that I do not *use* gdm3 myself, nor lightdm, nor xdm, or any other
display manager, but I did briefly experiment with gdm many years back.

I leave you with this (perhaps) amusing excerpt from a ~/.xsession file,
a remnant of those experimental days.  Make of this what you will.

=
# If we're running under gdm, then we do *not* want gnome-session to be
# spawned when this script exits.  I learned this hack by reading the
# /etc/gdm/Sessions/Gnome file (IIRC).
DEBUG_GNOME_SESSION='Let me the hell out!'
=

Back then, under gdm, if you had an .xsession file, it would be read, but
then after you exited from your chosen window manager, you'd get GNOME!
Or at least that's how I remember it.  And setting this shell variable
caused that not to happen.  And it was all completely undocumented,
because why would a user with gdm installed ever want anything *other*
than GNOME?

Re: Substring search in dash [ _NOT_ bash ] shell

[Greg Wooledge]

On Mon, Sep 26, 2016 at 10:39:59AM -0500, Richard Owlett wrote:
> #  string if [ "`hostname`" = bob ]; then echo bob.cfg; fi
> 
> I need for the case when evaluates to marybobsam .
> I can find examples in bash shell, but I need dash.

Are you asking how to check for the substring "bob" in your input,
in POSIX sh?  Use case, and a glob:

case $input in
  *bob*) echo "Bob found." ;;
esac

case $(hostname) in
  *bob*) echo "I must be a Bob." ;;
esac

Re: How to get an older emacs on Jessie

[Greg Wooledge]

On Thu, Sep 29, 2016 at 01:28:59PM -0400, Marc Auslander wrote:
> I'm running Jessie with the standard repositories and emacs from 21 on
> are available.  Have you looked?

I see emacs24 and xemacs21 in jessie.  Nothing in between.  I don't
fully understand the differences between emacs and xemacs; I am not
an emacs user, but I seem to recall that xemacs is a forked project,
and may or may not be suitable for the OP's goals.

Whenever I don't find the pacakge I want in Debian's repository, I
typically grab the upstream source code and build it myself.  This
is usually much simpler than trying to work out how to deceive the
package manager in the least damaging way.

Re: Canon printer minor quibble

[Greg Wooledge]

On Fri, Sep 30, 2016 at 02:20:43PM +0100, Lisi Reisz wrote:
> > On Fri, Sep 30, 2016 at 01:31:03PM +0100, Brian wrote:
> > > The "U" in CUPS officially doesn't stand for anything. The same applies
> > > to the "C", "P" and "S".

> It also says most of it, definitely that U stands for Unix, on the home page 
> of the CUPS web interface.:
> "CUPS 1.7.5
> CUPS is the standards-based, open source printing system developed by Apple 
> Inc. for OS® X and other UNIX®-like operating systems."  followed by a large 
> capital C containing the words "Unix Printing System".

Wikipedia  has conflicting
information.  At the top of the page, it claims CUPS stands for "Common
Unix Printing System", but without a reference.  At the bottom of the
page, it claims:

  CUPS was initially called "The Common UNIX Printing System". This
  name was shortened to just "CUPS" beginning with CUPS 1.4 due to legal
  concerns with the UNIX trademark.[citation needed]

This seems like one of those situations where Everyone Knows what the
truth is ("Common Unix Printing System"), but corporations and lawyers
require the Official Story to be a thin facade of lies.  But that's just
my take.

Re: Cannot apt-add repository

[Greg Wooledge]

On Thu, Oct 06, 2016 at 05:27:49PM +, Rasku, Stephen (GE Digital) wrote:
> So, what is the best practice to get the latest (or at least newer) version
> of git?  Compile from source?  I want to use some of the `git bisect`
> features that were introduced in 2.7.

I don't know about git specifically, but in the general case:

1) See if the software is already packaged in your release of Debian.

2) If your release is stable and it doesn't have the version you want,
   see if there is already a backport available in your release's
   -backports repository.

3) If there isn't a backport already available, try to make one.  (Or
   ask the Universal Debian Database whether it's known to be impossible
   to do so.)

4) If a backport can't be made because of build-dependencies, just build
   from the upstream source tarball.

git has some pretty wicked build dependencies (including subversion --
really?), and no current jessie-backports version, so you might be
looking at an upstream tarball.  I haven't tried it myself.

What is NOT on the list is "use some other operating system's package
repositories".  Never do that!

Re: Strange Gnome-terminal behaviour

[Greg Wooledge]

On Fri, Oct 07, 2016 at 09:47:37PM +0900, Mark Fletcher wrote:
> Also I have no .Xresources file, is that normal?

wooledg@wooledg:~$ ls -a /etc/skel
.  ..  .bash_logout  .bashrc  .profile

Yup.  Normal.  But the good news is, it looks like you *can* make one
and expect it to be used by the Debian X session:

wooledg@wooledg:~$ grep -r Xresources /etc/X11
/etc/X11/Xsession:SYSRESOURCES=/etc/X11/Xresources
/etc/X11/Xsession:USRRESOURCES=$HOME/.Xresources

At least, that's how it seems at first glance.  You'd have to tear apart
the shell scripts to be absolutely sure.  Or, y'know, make one and login
and see what happens.

Re: Cannot apt-add repository

[Greg Wooledge]

On Fri, Oct 07, 2016 at 10:46:08AM +0300, Reco wrote:
> On Fri, Oct 07, 2016 at 12:26:46AM -0400, Bob Bernstein wrote:
> > On Thu, 6 Oct 2016, Greg Wooledge wrote:
> > >ask the Universal Debian Database whether it's known to be impossible to
> > >do so.
> > 
> > Ok, I'll bite. What is "the Universal Debian Database?"
> 
> I find it hard to beleive myself, but here it is:
> 
> http://udd.debian.org

Oh, sorry.  "Ultimate" not "Universal".

In addition to the web page, and the PostgreSQL interface described on
https://wiki.debian.org/UltimateDebianDatabase , there is an IRC chat
bot ("judd") who can query it for you, at least on the Freenode network
(I don't know about OFTC).

-> /msg judd checkbackport git
<- Backporting package git in sid->jessie/amd64: all build-dependencies 
satisfied using jessie, virtual.

Sometimes judd's "checkbackport" reports "all satisfied" and it
still doesn't work because of undeclared dependencies (like needing
a post-stable "dpkg" package during the build), but it's the best
test I know of besides actually trying to backport it.

Re: My bash script is missing something - what?

[Greg Wooledge]

On Mon, Oct 10, 2016 at 08:10:33AM -0500, Richard Owlett wrote:
> On 10/10/2016 8:00 AM, Robert Parker wrote:
> >you need to do:
> >./test.sh
> >instead.
> >
> 
> That just fails differently by responding:
> 
> : No such file or directory

Carriage return.  Did you edit this script with a Microsoft Windows
program, perhaps?  The shebang line (#!/bin/bash) probably ends with
a carriage return + line feed, instead of just a line feed.

Re: My bash script is missing something - what?

[Greg Wooledge]

On Mon, Oct 10, 2016 at 04:10:22PM +0200, Nicolas George wrote:
> Le nonidi 19 vendémiaire, an CCXXV, Greg Wooledge a écrit :
> > > That just fails differently by responding:
> > > 
> > > : No such file or directory
> > 
> > Carriage return.  Did you edit this script with a Microsoft Windows
> > program, perhaps?  The shebang line (#!/bin/bash) probably ends with
> > a carriage return + line feed, instead of just a line feed.
> 
> I had the same diagnosis. Note that modern shells print a more useful
> diagnosis:
> 
> execve("/tmp/foo.sh", ["/tmp/foo.sh"], [/* 45 vars */]) = -1 ENOENT (No such 
> file or directory)
> open("/tmp/foo.sh", O_RDONLY|O_NOCTTY)  = 3
> read(3, "#!/bin/sh\r\n", 64)= 11
> close(3)= 0
> ioctl(2, TCGETS, {B38400 opost isig icanon echo ...}) = 0
> write(2, "zsh:1: /tmp/foo.sh: bad interpreter: /bin/sh^M: no such file or 
> directory\n", 74) = 74
> exit_group(127) = ?

Actually, I'm going to change my diagnosis slightly.  The shebang is fine,
but the "cat /etc/debian_version" line has a carriage return at the end.
The error message is coming from cat.

If the shebang is wrong, bash (as interactive shell) prints:

bash: ./foo: /bin/bash^M: bad interpreter: No such file or directory

which is very close to your zsh message.  But putting the carriage return
on the cat command gives:

wooledg@wooledg:~$ ./foo
: No such file or directory

which is really:

wooledg@wooledg:~$ ./foo 2>&1 | less
cat: /etc/debian_version^M: No such file or directory

How the original poster ended up with a script with an extra carriage
return on just *one* line, rather than every line, is a mystery to me.

Re: cant get to desktop anymore

[Greg Wooledge]

On Sun, Sep 18, 2016 at 08:33:23PM -0400, Neal P. Murphy wrote:
>  will reach the X11 session. If it started. If not, it could 
> be that a default xdm session (KDE, Gnome, XFCE, etc.) wasn't selected or a 
> desktop 'task' wasn't installed.
> 
> Console #7 is the standard console used for X11. Console #1 is the default 
> console when there is no default X11 session.

That was true in wheezy.  It's not true in jessie.

In jessie, running with systemd by default, the display manager takes
over the *first* virtual console (Ctrl-Alt-F1).  The first console with
a getty is therefore Ctrl-Alt-F2.

Of course, if there is no display manager installed at all, then Ctrl-Alt-F1
should have a getty running on it once the system boots.  But as soon as
you run startx, X takes over the *first* console (not the seventh)
and you're right back to the same situation as if you had used a display
manager.

(I use startx on jessie, so I speak from direct personal experience,
tested right now.)

Re: Need a tutorial

[Greg Wooledge]

On Wed, Sep 21, 2016 at 10:18:55AM -0400, Gene Heskett wrote:
> Where can I get a tut on doing the ssh keyfile login, and where can I 
> find a tutorial that is essentialy what Dr. Klepp had me do about a year  
> back that made these 3 commands in my rc.local file Just Work:
> 
> su gene -c "sshfs gene@shop:/ /sshnet/shop"
> su gene -c "sshfs gene@lathe:/ /sshnet/lathe"
> su gene -c "sshfs gene@GO704:/ /sshnet/GO704"

You need to set up key authentication between your local account (as
client) and the remote server.  Usually this is done by having an ssh
keypair (generating one if you don't already have one), then sending
the public key (NOT the private key) to the remote machine, and appending
it to the ~/.ssh/authorized_keys file of the target account.

man ssh-keygen
http://mywiki.wooledge.org/SshKeys

Re: Jessie (8.0) - Unexpected behavior of "MATE Terminal" after reboot

[Greg Wooledge]

On Wed, Sep 21, 2016 at 08:18:36AM -0500, John Hasler wrote:
> To find out what shell you are running type
> 
> echo $0

imadev:~$ csh
% echo "$0"
No file for $0.

The world's a much bigger place than just the Bourne family of shells,
unfortunately.

ps -p $$   # works in csh too

Re: Jessie (8.0) - Unexpected behavior of "MATE Terminal" after reboot

[Greg Wooledge]

On Wed, Sep 21, 2016 at 07:30:50AM -0500, Richard Owlett wrote:
>   1. the immediate one being whatever shell MATE terminal uses.

Unless it's completely diverging from Unix standards, it should launch
your user account's shell as defined either by the $SHELL environment
variable, or by your entry in the passwd database.

>  Sub-question: When in an arbitrary terminal of an arbitrary 
> Desktop Environment,
> how would I determine which shell is in use?

In my experience, the simplest way to see what shell you are in is to
run this command:

ps -p $$

This command "works" (for varying definitions) in Bourne-family shells,
csh-family shells, BSD systems, and System V systems.

But you'd also be well-served to check out the $SHELL variable, and
your own entry in /etc/passwd or whichever passwd database you happen
to be using, and to understand what it means.

Re: Failed to execute child process (no such file or directory), but the script DOES exist in $HOME/bin, openbox users, especially take a look, please.

[Greg Wooledge]

On Wed, Sep 21, 2016 at 09:43:15AM -0400, Tony Baldwin wrote:
> I have various scripts in $HOME/bin, many of which I have put in my 
> .config/openbox/rc.xml so I can fire them off with a keybinding combo, like

How do you login?  With a display manager?  Which one?

> when I press W-b, and some others I get this:
> Failed to execute child process (no such file or directory)

And you believe it's because of a PATH mismatch.  OK.  I don't have
experience with whichever desktop or window manager this is.

> But the script IS in  ~/bin/
> $ which bid
> /home/tony/bin/bid
> and that dir IS in my $PATH:
> $ echo $PATH
> /home/tony/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Now here's the real issue: this is the PATH variable of some interactive
shell.  But your window manager (or whatever is reacting to your key
events) may have a *different* PATH.

For example, it is possible that your wm has some PATH determined by
the files that are read upon login, and then you launch a terminal
from your wm, and the terminal launches a shell, and the shell reads
~/.bashrc or whatever, and ~/.bashrc changes the PATH of the shell
so that your commands work.

But the poor wm is still stuck with the PATH that it got when you logged
in, which presumably does not read ~/.bashrc or any other shell dot files.

That's why you have to understand whichever login method you use, and
how to configure it.

I have a dream that one day, Debian developers will wake the hell up
and document these things.  (I've been too lazy so far to dedicate a
few hours/days to installing and removing display managers and desktop
environments in order to reverse engineer each combination and try to
figure out what dot files they use.  But the thought has crossed my
mind.  That's how blightedly BAD the situation is.)

Re: Failed to execute child process (no such file or directory) ...

[Greg Wooledge]

On Wed, Sep 21, 2016 at 05:20:31PM +0200, Thomas Schmitt wrote:
> You could put a script into /usr/bin (where it will be found, i hope),
> let it print the PATH to a file, bind it to a key combination, and
> look what it writes into the file:
>   #!/bin/sh
>   echo "$PATH" >/tmp/my_openbox_test_for_PATH

Or you can use  ps eww -p "$(pgrep openbox)"  (or directly substitute
the PID you want in case that command substitution is wrong; it works
for me with fvwm).  The PATH should be visible in the process's
environment as displayed by ps.  There may be a lot of noise to filter
out, of course.

Re: Failed to execute child process (no such file or directory), but the script DOES exist in $HOME/bin, openbox users, especially take a look, please.

[Greg Wooledge]

On Wed, Sep 21, 2016 at 10:49:13AM -0400, Tony Baldwin wrote:
> it seems that I am using lightdm.

I know of absolutely no documentation for configuring lightdm as a
user.  I suspect that the software *has* no user configuration at all,
because every search I've ever done has come up with nothing.

(For example, https://wiki.debian.org/LightDM has zero instances of
"home" or "~" or "dot".)

So then we enter the murky waters of "what happens after lightdm".
Here I can only find hints and conjectures and anecdotes.

https://lists.debian.org/debian-user/2014/10/msg02242.html
https://lists.debian.org/debian-user/2013/12/msg00775.html
https://faq.i3wm.org/question/2483/howto-debian-wheezy-lightdm-i3.1.html
...

Re: Rebuilding Debian package from source

[Greg Wooledge]

On Mon, Sep 19, 2016 at 11:57:13AM -0400, The Wanderer wrote:
> Based on the error, it looks as if the build process is attempting to
> run a command that uses the full path of the build directory, but does
> not quote that path; as a result, the space gets treated as a token
> separator.

Makefiles in general have no real way to handle filenames and directory
names with spaces in them.  The notion of a Makefile variable holding
a space-delimited list of filenames is embedded in the design at the
most fundamental levels.  Passing these "lists" from Makefile to /bin/sh
script fragments doesn't make things any simpler, either.

> The net result is that it attempts to cp the absolute path
> '/home/jschaeffer/Build' into the relative path
> 'Test/nginx-1.6.2-5+deb8u2/auto', which does not exist. (The former path
> may well not exist either, but I'd double-check that if I were you.)
> 
> To fix this, either modify the build process to quote things
> appropriately, or build from under a path which does not contain a
> space. (The latter can be accomplished using symlinks, if preferred.)

I doubt it's possible to make build paths containing spaces work correctly
in the general case, even if the original poster does manage to hack
it up this one time.  My advice would be to stop attempting to use a
directory with a space in its name as part of a build setup.  It's doomed.

Re: /etc/fstab and systemd

[Greg Wooledge]

On Mon, Sep 19, 2016 at 03:15:26PM +0200, Pol Hallen wrote:
> I migrated my pc to systemd (!), in /etc/fstab I've
> 
> /dev/sdb1 /test   ext4x-systemd.automount 0   0
> (I use UUID but to semplify I wrote /dev/sdb1)

Changing the content of your files is not "simplifying".  It's mangling.

> what is the correct way to mount a disk automatically at start up of system?

This is what jessie does by default:

UUID=1a20ffb7-897c-4373-84c1-14089a6deab8 /   ext4
errors=remount-ro 0   1
# swap was on /dev/sda3 during installation
UUID=b8d67062-8262-476d-9370-8166f7572fd3 noneswapsw
  0   0
/dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0

Or, on a system with a separate /home:

UUID=404cbcbe-cc34-44e6-b8cf-845c3ceb56e7 /home   ext4defaults  
  0   2

In short, there's no special magic used by fstab on a jessie/systemd
system.  It's just like an fstab from wheezy.  Let systemd handle the
mounting in its regular way.

Re: sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial

[Greg Wooledge]

On Fri, Sep 23, 2016 at 12:31:00PM +, Stephan Beck wrote:
> I have created a new user account with
> adduser --disabled-password
> What do I want to do?
> I'd like to login to this account "test" from my normal user account by
> ssh via pubkey authentication. My (normal) user account has its keys
> generated and properly deposited on localhost. I logged into the account
> "test" via su - test, creating a keypair. Fine.

Typically, you want to create the keypair as the user on the machine which
will be the client.  This way the private key never has to be touched,
moved, looked at, etc.

So, you want to ssh
FROM user "stephan" on this machine
TO   user "test"on this (same) machine

The private key needs to reside in ~stephan/.ssh/ where the client will
see it.

The public key needs to be concatenated into ~test/.ssh/authorized_keys
where the server will see it.

> How do I get this public key onto localhost?

Trick question.  You are already on the correct machine.  You just need
to have everything in the correct places (files/directories) with the
correct ownerships.

> I mean, I can create an authorized_keys file manually, copying the
> public key into this authorized_keys file, but it's still in the user's
> directory where it has been generated, it needs to be sent (or get
> somehow) to localhost.

As user stephan:

stephan@hostname:~$ ssh-keygen

As user root:

stephan@hostname:~$ sudo mkdir -p ~test/.ssh
stephan@hostname:~$ sudo sh -c 'cat ~stephan/.ssh/id_rsa.pub >> 
~test/.ssh/authorized_keys'
stephan@hostname:~$ sudo chown test ~test/.ssh ~test/.ssh/authorized_keys
stephan@hostname:~$ sudo chmod 700 ~test/.ssh
stephan@hostname:~$ sudo chmod 600 ~test/.ssh/authorized_keys

(Of course, if you prefer you could just obtain a root shell and then run
all of the commands without sudo.)

As user stephan, to test that it works:

stephan@hostname:~$ ssh test@localhost id

If your username isn't actually "stephan", substitute accordingly.

Re: Need a tutorial

[Greg Wooledge]

On Thu, Sep 22, 2016 at 08:18:30PM +0200, Dominique Dumont wrote:
> On Thursday, 22 September 2016 12:30:10 CEST Gene Heskett wrote:
> > If you're not sure of the syntax of ssh config file, you can use
> > 
> > > 'cme edit ssh' to perform this task.
> > 
> > cme=command not found.
> 
> You need to install cme package:
> $ sudo apt install cme

wooledg@wooledg:~$ apt-cache show cme
N: Unable to locate package cme
E: No packages found

Re: SOLVED Re: mysql broken after jessie upgrade

[Greg Wooledge]

On Thu, Sep 22, 2016 at 04:02:37PM +0200, Tony van der Hoff wrote:
>  Running Jessie here. Performed apt-get upgrade yesterday, which included
>  a new version of mysql.

> It turns out that the recent upgrade took mysql from 5.5 to 5.6. It
> uninstalled mysql-server-5.5, but failed to install mysql-server-5.6,
> due to an unmet dependency on mysql-server-core-5.6.

Sounds like you're getting mysql-server from jessie-backports instead
of jessie.  On a pure jessie system, it is still 5.5.

Re: Need a tutorial

[Greg Wooledge]

On Thu, Sep 22, 2016 at 03:35:00PM +, Stephan Beck wrote:
> Sorry, Tomas, it's not Gene, it's me who has a special question
> concerning ssh.
> If you create a new user account ("test"), doing as root
> adduser --disabled-password test
> 
> How can you access this new account to generate an ssh key pair there?

Install sudo if you haven't already.  Then:

sudo -u test bash

Or if you don't want a whole shell:

sudo -u test ssh-keygen [options]

The su program is not as useful for this kind of task, because it
insists on launching the target user's shell, which in some cases is
not a useful interactive command shell (e.g. /bin/false).  sudo does
not have this restriction.

Re: Resolved: Failed to execute child process (no such file or directory), but the script DOES exist in $HOME/bin, openbox users, especially take a look, please.

[Greg Wooledge]

On Thu, Sep 22, 2016 at 09:00:11AM -0700, Seeker wrote:
> A little late, but personally I would have tried using '~/.xprofile'
> first.
> 
> I believe the information about this from the Arch Wiki applies equally
> to Debian.
> 
> https://wiki.archlinux.org/index.php/xprofile

wooledg@wooledg:~$ grep -r xprofile /etc/X11
wooledg@wooledg:~$ 

Apparently Debian's "X session" is heavily customized, as described in
https://www.debian.org/doc/manuals/debian-reference/ch07.en.html#_starting_the_x_window_system

Arch's customizations are different and don't appear to be the same
as Debian's.

What I was missing was a simple pointer from lightdm's joke of a man page
to either Xsession(5), with some indication that lightdm *runs* a Debian
X session, or directly to the debian-reference web page.

At some point I may take a stab at fixing up the wiki page(s) now that
we have some actual, useful information.  (I should also point out that
my Google searches for "debian man lightdm" etc. tended to favor the
Debian wiki page, which at this precise moment is just about as useless
as the lightdm man page is.)

Re: Need a tutorial

[Greg Wooledge]

On Thu, Sep 22, 2016 at 06:11:18PM +0200, Thomas Schmitt wrote:
> Greg Wooledge wrote:
> > sudo -u test bash
> 
> Does not work for me (at least not out of the box):
> 
>   $ sudo -u test_user bash
>   [sudo] password for thomas: 
>   Sorry, user thomas is not allowed to execute '/bin/bash' as test_user on 
> [...]
>   $

Well, that's not a fair test.  The previous poster was running adduser,
so he already had superuser privileges, either through sudo or su or
direct root console/ssh login.  From whichever shell he was using to
run adduser, he should also be able to run sudo -u test bash.

Re: Failed to execute child process (no such file or directory), but the script DOES exist in $HOME/bin, openbox users, especially take a look, please.

[Greg Wooledge]

On Thu, Sep 22, 2016 at 03:15:40PM +0100, Tixy wrote:
> I edit ~/.xsessionrc to have a single line:
> 
> . /home/tixy/.profile

Which program reads ~/.xsessionrc and how did you learn about it?
Which man page describes it?  Does its existence merely "add on" to some
system-wide default script, or does it fully replace a system-wide script?

> Which makes X sessions include the same profile as standard login
> shells.

Bash's initialization is a bit more complex than that.  It will look
for three different files (.bash_profile or .bash_login or .profile),
in that order, and uses the first one it finds.  I'd imagine zsh does
something similar, though I don't use zsh.  For pure POSIX sh or ksh,
you would be correct.

Re: Failed to execute child process (no such file or directory), but the script DOES exist in $HOME/bin, openbox users, especially take a look, please.

[Greg Wooledge]

I've edited https://wiki.debian.org/LightDM and written
https://wiki.debian.org/Xsession from scratch.  I hope this helps other
people who were as lost and confused as I was.

If you're still wondering what kind of documentation I was looking for,
you may use https://wiki.debian.org/Xsession as the answer.  That's
what I wanted to see.  I will be able to point users to this page in
the future.

Thanks to all who provided information.

Re: permanently add dir to $PATH

[Greg Wooledge]

On Fri, Sep 16, 2016 at 10:01:39AM -0400, Tony Baldwin wrote:
> The other problem is trying to permanently add $HOME/bin to the $PATH.
> 
> I have in .bash_profile
> PATH=$PATH:$HOME/bin
> export PATH
> 
> But every time I boot I have to manually add it again.

This is probably because you are logging in with a display manager
instead of ssh or a Linux console.  The display managers do not launch
a login shell, so your login shell configuration files are never read.

(This is why I never use a display manager.  Well, one of the reasons.)

You need to identify which display manager you're using, and then try
to figure out how to configure it as a user.  Good luck.  I've found
that most of them have absolutely ZERO documentation about this.

Re: update-alternatives, list alternatives?

[Greg Wooledge]

On Fri, Sep 16, 2016 at 10:10:44AM -0400, Tony Baldwin wrote:
> I can't seem to find or figure out how to list all the alternatives I 
> can manage with update-alternatives.
> I mean, I can get a list for a particular item, like x-www-browser or 
> editor, but I want a list of all those possible things to update 
> (x-www-browser, editor, etc.)
> Is there such a list somewhere?

ls /etc/alternatives

I don't know if even that is complete.  However, it should be a good
start.

Re: update-alternatives, list alternatives?

[Greg Wooledge]

On Fri, Sep 16, 2016 at 10:56:44AM -0400, Tony Baldwin wrote:
> Indeed:
> # update-alternatives --get-selections | grep mail
> mailx  auto /usr/bin/bsd-mailx
> 
> but also:
> # update-alternatives --config mailx
> There is only one alternative in link group mailx (providing 
> /usr/bin/mailx): /usr/bin/bsd-mailx
> Nothing to configure.
> 
> 
> it seems it won't let me set a mail client

The other alternative for mailx is heirloom-mailx and I would strongly
recommend that one over bsd-mailx.  heirloom-mailx has lots more
features, including the ability to specify MIME attachment files from
the command line.

In general, if you're wondering how to find out what the alternatives
are for a given virtual package:

$ apt-cache showpkg mailx
...
Reverse Provides: 
mailutils 1:2.99.98-2
heirloom-mailx 12.5-4
bsd-mailx 8.1.2-0.20141216cvs-2

So, three choices.  I only knew about the latter two.

Re: Need a tutorial

[Greg Wooledge]

On Thu, Sep 22, 2016 at 12:30:10PM -0400, Gene Heskett wrote:
> On Thursday 22 September 2016 11:16:45 Dominique Dumont wrote:
> > Others have explained how to generate keys. Then you can simplify the
> > process by setting up your ~/.ssh/config file with something like:
> >
> Interesting, I don't have that file, its all in /etc/ssh.

Create it if it doesn't exist.  Create the ~/.ssh/ directory first, if
that doesn't exist either.

> > Host shop lathe GO704
> >  user gene
> >  # private key file
> >  IdentityFile ~/.ssh/my_key_for_sshfs
> >
> > If you want to use different keys for the several hosts, you will have
> > to duplicate the config snippet shown above.

More generally, ~/.ssh/config (which does not exist by default but which
can be created) is the user-level configuration for the ssh client
program.  The system-level defaults are in /etc/ssh/ssh_config.

Also, as long as you're messing with ~/.ssh/config you might want to
set up a keepalive in case you ever communicate through a NAT router.

ServerAliveInterval 300

will send a packet every 300 seconds, which (hopefully) prevents a NAT
router from timing out your idle sessions.

(Yeah, I know, it says "Server" but it's a client-side config option.
I didn't choose the name.)

> > If you're not sure of the syntax of ssh config file, you can use
> > 'cme edit ssh' to perform this task.
> 
> cme=command not found.

I know nothing about this "cme" either.

Re: Failed to execute child process (no such file or directory), but the script DOES exist in $HOME/bin, openbox users, especially take a look, please.

[Greg Wooledge]

On Wed, Sep 21, 2016 at 09:19:11PM -0500, David Wright wrote:
> But I don't understand the concept of "user configuration" for a DM.
> Wouldn't that be like a user configuring /etc/issue, the login prompt
> or /etc/motd ?

By user configuration, I mean "which files can the user edit, without
superuser privileges, to alter the behavior of the program".

> Are you perhaps talking about which file,
> like .xsession, .xsessionrc, .Xsession, .xinitrc, etc gets executed
> when you login through the DM?

Yes, precisely this question.  What can an end user, who uses one of
the various display managers and desktop environments in Debian, do
to configure their own environment?  Hell, just start with the $PATH
variable.  That's what 90% of the people asking this question want to
modify -- well, that or some other environment variable with the word
PATH or HOME in it, like JAVA_HOME.

Why is it *so impossible* to find out how to set an environment variable?

Everything is so much simpler when you don't use a display manager.
You login on the console (getty + login), which sets some variables,
all of them well documented in man pages, and then executes your shell as
defined in passwd(5) with a leading '-' to mean "this is a login shell".
Then, the behavior of the shell when argv[0] begins with '-' is well
documented in the shell's man page.  Everyone knows how it works, and
everyone knows how to change its behavior.  I can describe *every single
process* in the chain, and I know what *every one* of them does and which
files it reads; or if I don't have every configuration file memorized,
then at least I know which document I can read to find the list of them.

With lightdm (for example), nobody knows how to change its behavior,
or even how to *understand* its behavior.  There's no starting point in
any piece of documentation that tells you what's happening, or how and
where you can intervene in the chain of events.

What's worse is none of the experts who are typically able to answer
questions about this kind of thing knows how to answer.  We don't *use*
these things!  And where we would normally be able to crack open a
man page to find the answer, there are no answers!  When we do Google
searches, there are *still* no answers!  This creates a gap between the
expert users and the novice users, and it's getting worse every year.

At this point, when a user running *dm and *DE asks some question about
their login environment, they might as well be running Microsoft Windows
for all the help I can give them.  All I can do is sit there and watch,
hoping that some day, *someone else* will come along with a magic starting
point from which answers can be determined.  It hasn't happened yet.

> I'm not a DE or DM user, so I'm know very little about them.

Yes, THIS is the problem!  You, and I, and everyone else on the guru side
are just completely stumped.

When the answer to "how do I run a thing at login" changes from "put
foobar& in your .xsession shell script before the exec wm" to "somewhere in
your home directory is a whole new kind of file with a .desktop extension
which isn't a shell script but a totally new thing that you have to
learn from scratch..." the immediate response is "to hell with that,
I'm going back to startx + fvwm".  So we stick with the old, simple
things that work and are understandable and don't take up 700 MB of
disk space, and nobody with a *brain* learns the new stuff.

When the answer to "how do I set an environment variable at login" changes
from "put export FOO=bar in your .bash_profile" to "uh... well... there's
nothing in man lightdm, so let's check google... oh, no, I... just don't
see how to do it" then something is completely *broken*.

Don't believe me?  I know none of us has lightdm installed, so here is
a man page, allegedly from Debian wheezy:

http://www.unix.com/man-page/debian/1/lightdm/

It takes several tries for me even to find *that*, probably because the
manual is so ashamed of itself that it runs and hides when the Google
crawler approaches.  Behold this glorious tome of wisdom:

NAME
   lightdm - a display manager

SYNOPSIS
   lightdm [ OPTION ]

DESCRIPTION
   lightdm is a display manager.

That's it!  That is the *entire documentation*, apart from a list of
options (none of which can be modified by an end user, of course),
and then a list of three configuration files:

FILES
   /etc/lightdm/lightdm.conf
  Configuration

   /etc/lightdm/users.conf
  User list configuration (if not using Accounts Service)

   /etc/lightdm/keys.conf
  XDMCP keys

This is what we're dealing with.  "lightdm is a display manager."
What does that MEAN?  What does it DO?  People type their passwords into
this thing, and *this* is its official user manual?  Is this a *joke*?
What happens AFTER you type your username and password?  What files does
it read AFTER the password, not before!  Who CARES what it does before!
What PROCESSES does it 

Re: Failed to execute child process (no such file or directory), but the script DOES exist in $HOME/bin, openbox users, especially take a look, please.

[Greg Wooledge]

On Thu, Sep 22, 2016 at 02:50:30PM +0100, Brian wrote:
> To read the manual
> 
>   apt-get download lightdm
> 
> works every time.

Hmm, well.

$ cd /tmp
$ apt-get download lightdm
$ ls, man dpkg, ...
$ dpkg -x lightdm_1.10.3-3_amd64.deb ldm
$ gzip -dc ldm/usr/share/man/man1/lightdm.1.gz | nroff -man | less

Turns out there is a whole new section in the man page since wheezy!

SEE ALSO
   dm-tool(1)

That is the only addition.

$ man dm-tool
No manual entry for dm-tool

Yes, I could do a bunch of crap to try to figure out which package
contains that manual page, extract it, etc.  But it doesn't seem like
a useful investment of time, as I would not expect it to describe how
a DM works, or what happens after it has accepted and verified a password.

Re: Frequent Hash Sum mismatch on jessie-backports with apt-get update

[Greg Wooledge]

On Thu, Aug 18, 2016 at 04:47:55AM -0700, poiuytrez wrote:
> I have frequent errors when I do apt-get update: 
> W: Failed to fetch 
> http://http.debian.net/debian/dists/jessie-backports/main/source/Sources  
> Hash Sum mismatch

For you, I would suggest trying a different mirror.

$ host http.debian.net
http.debian.net is an alias for httpredir.debian.org.

This redirection service works very well for some people, and very poorly
for other people.  You appear to be in the latter group.

You can either select a single mirror directly from:
https://www.debian.org/mirror/list

(the single mirrors are listed at the bottom of the page)

or you can use one of the country-code round robin services, such as:
http://ftp.us.debian.org/debian/
http://ftp.ca.debian.org/debian/

(the round robins are listed at the top of the page).

Obviously you would want to choose a country that's close to you,
network-wise.

> Sometimes it works, sometimes it doesn't. The problem appeared on all my
> servers running Debian 8 (hosted on Google Cloud Platform) the last couple of
> days. 

I have also experienced a MASSIVE problem with apt-get in the last week
or so.  I don't know if it's the same problem you're having, or totally
unrelated, but I am going to piggyback on your thread.

I have my problem at WORK only.  At work, I am trapped inside a firewalled
network.  I have no control over the firewall.  The entities who control
it are mysterious dark wizards who do not reveal themselves or their
secrets to mere mortals like me.

One of the past features of this firewall was a "transparent" (worst term
ever) HTTP proxy with forced authentication (user name and password).
I was able to plead to get an exception in place.  HTTP connections coming
from my desktop workstation's IP address weren't required to perform a
Windows Active Directory login to the HTTP proxy.  So I put a Squid proxy
on my workstation and told all of the Debian servers to use that for apt.

This worked well enough for years.

Now, starting last week, the problem is that when I try to apt-get update,
the files coming from security.debian.org HANG at 100% complete.  It
looks something like this:

root@ebase-fla:~# apt-get update
Hit http://ftp.us.debian.org wheezy Release.gpg
Hit http://ftp.us.debian.org wheezy-updates Release.gpg
Hit http://ftp.us.debian.org wheezy Release
Hit http://ftp.us.debian.org wheezy-updates Release
Hit http://ftp.us.debian.org wheezy/main Sources 
Hit http://ftp.us.debian.org wheezy/contrib Sources
Hit http://ftp.us.debian.org wheezy/non-free Sources   
Hit http://ftp.us.debian.org wheezy/main amd64 Packages
Hit http://ftp.us.debian.org wheezy/contrib amd64 Packages 
Hit http://ftp.us.debian.org wheezy/non-free amd64 Packages
Hit http://ftp.us.debian.org wheezy/contrib Translation-en 
Hit http://ftp.us.debian.org wheezy/main Translation-en
Hit http://ftp.us.debian.org wheezy/non-free Translation-en
Hit http://ftp.us.debian.org wheezy-updates/main Sources   
Hit http://ftp.us.debian.org wheezy-updates/contrib Sources
Hit http://ftp.us.debian.org wheezy-updates/non-free Sources   
Hit http://ftp.us.debian.org wheezy-updates/main amd64 Packages/DiffIndex
Hit http://ftp.us.debian.org wheezy-updates/contrib amd64 Packages 
Hit http://ftp.us.debian.org wheezy-updates/non-free amd64 Packages/DiffIndex  
Hit http://ftp.us.debian.org wheezy-updates/contrib Translation-en 
Hit http://ftp.us.debian.org wheezy-updates/main Translation-en/DiffIndex  
Hit http://ftp.us.debian.org wheezy-updates/non-free Translation-en/DiffIndex  
Hit http://security.debian.org wheezy/updates Release.gpg  
Hit http://security.debian.org wheezy/updates Release
Hit http://security.debian.org wheezy/updates/contrib Sources
Hit http://security.debian.org wheezy/updates/non-free Sources
Get:1 http://security.debian.org wheezy/updates/main amd64 Packages [426 kB]
Hit http://security.debian.org wheezy/updates/contrib amd64 Packages   
Hit http://security.debian.org wheezy/updates/non-free amd64 Packages
Hit http://security.debian.org wheezy/updates/contrib Translation-en
Hit http://security.debian.org wheezy/updates/non-free Translation-en  
Get:2 http://security.debian.org wheezy/updates/main Sources [276 kB]
Get:3 http://security.debian.org wheezy/updates/main amd64 Packages [426 kB]   
Ign http://security.debian.org wheezy/updates/main Translation-en  
Get:4 http://security.debian.org wheezy/updates/main Sources [276 kB]
Err http://security.debian.org wheezy/updates/main amd64 Packages
  404  Not Found [IP: 128.101.240.215 80]
Fetched 69.9 kB in 22min 8s (52 B/s)
W: 

Re: Recent flex security announcement

[Greg Wooledge]

On Fri, Aug 26, 2016 at 12:11:30AM +, Mark Fletcher wrote:
> However I also have Linux machines that don't use a package management
> system, and there I also have a version of flex with the vulnerability, so
> I wanted to get the source tarball of the fixed version (v2.6.1) so I could
> build it for there too.

Debian security fixes in stable (or oldstable/LTS) releases aren't done
by switching to a new upstream version.  They're done by backporting the
smallest possible fix to the same version that stable (or oldstable/LTS)
is already using.

The current Debian version of flex in stable is 2.5.39-8+deb8u1.
This means it's based on upstream version 2.5.39, with a bunch of
Debian-specific changes/patches applied to it.

If you want to obtain the Debian-patched source and then build it on
another system, then you have two options.  The first is to use the
"apt-get source" command on a Debian system.  This will retrieve the
three files that constitute a Debian source package, extract the upstream
tarball, and apply the Debian patches to it.  You will be left with
an extracted & patched directory, ready to build, assuming your target
system has all of the tools needed to build it.

The second is to mimic that process yourself.  Go to the package's page
(e.g. https://packages.debian.org/jessie/flex) and look on the right hand
side, where it says "Download Source Package".  Under that, you will see
the three files (.dsc and .orig.tar.gz and .debian.tar.xz).  Download all
three of those (or you can skip the .dsc file, but not the other two).
Extract the .orig.tar.gz file, and then cd into the directory it creates.
>From there, extract the .debian.tar.xz file.  This will create a debian/
subdirectory with patches in it.  Apply those patches manually.  Now you
should, in theory, have the same patched-and-ready-to-build directory
that you would have got from apt-get source.

Re: Recent flex security announcement

[Greg Wooledge]

On Fri, Aug 26, 2016 at 12:41:54PM +, Mark Fletcher wrote:
> Stretch and sid are quoting version 2.6.1 and I can't see where they got
> that from, as upstream (sourceforge) latest version seems to be 2.6.0. And
> 2.6.1 claims to be the version with the fix.

*sigh* ... it just figures, as soon as you ask this, I cannot reach
http://ftp.gnu.org/ or https://ftp.gnu.org/ to look at the actual
versions.

Nor can I reach http://www.gnu.org/.  Nor can I ping either site.
Looks like they're just totally down.

However, https://packages.debian.org/stretch/flex does have a
flex_2.6.1.orig.tar.gz on it.  That's what Debian is using as their
upstream tarball, wherever it came from.  And in theory, the copyright
file should say where they got it from.

Re: Speedup cp command?

[Greg Wooledge]

On Tue, Aug 23, 2016 at 04:16:42PM -0500, Richard Owlett wrote:
> Thanks. I'll try it as soon as copy of DVD#2 ends.
> What's special about a loop mount in this circumstance? As I read 
> the rsync man page it was pretty similar to cp and it had 
> accepted a plain automount [I'm on Jessie with Mate DE]]

rsync vs. cp won't make any difference if the destination directory
is empty.  In either case, you have to read every byte of input and
write every byte of output.

rsync is tremendously useful when you've already got a partial copy
of the input.  It uses heuristics to figure out what it actually needs
to copy, and skips the parts you already have.

Re: Substring search in dash [ _NOT_ bash ] shell

[Greg Wooledge]

On Tue, Sep 27, 2016 at 10:07:14AM +0200, Thomas Schmitt wrote:
> if you cannot find a dash tutorial then get a tutorial for bash or sh and 
> test in dash whether the proposals apply properly.

This is potentially bad advice, for several reasons.

First, there are more bad tutorials out there in the wild than good
tutorials, by at least one order of magnitude.  The chances of randomly
stumbling upon one of the good ones are low.

Second, trying to work backwards from a bash tutorial to a POSIX sh/dash
programming style is going to be maddening.  If you're writing for sh,
definitely read documents aimed at sh, rather than some other shell.

Third, even dash has a few extensions to the POSIX shell syntax.
Which, if you're writing specifically for *dash* instead of POSIX sh
in general, is OK... but then you're tying yourself to one specific
shell which isn't in widespread use outside of Debian/Ubuntu.

> Bash and dash both stem from S.R.Bourne's sh. The shell chapters of
> his book "The Unix System" from 1983 still apply.

I have not read this book, but I have a copy of Kernighan & Pike's "The
Unix Programming Environment".  While it's a pretty good book for learning
the concepts, the shell script examples in it are atrociously BAD.
Adopting them as a style guide would be a horrible idea.  They're full
of all of the old shell scripting bugs and assumptions that make programs
fail in a real-life environment, where filenames can contain spaces, etc.

Essentially, every shell script or tutorial written before the year 2000
(and >= 95% of the ones written *after* that) is pure rubbish.

Want to know how bad it is?  Install the Debian package "manpages-posix"
and then read "man 1p sh" -- the SH(P) manual page for the POSIX shell,
written by the *people who made POSIX* (an older version) in 2003.

Search for the word EXAMPLE (all caps) and then scroll up to the example
right before it.  Here is it, reproduced as plain text:

  #
  # Installation time script to install correct POSIX shell pathname
  #
  # Get list of paths to check
  #
  Sifs=$IFS
  IFS=:
  set $(getconf PATH)
  IFS=$Sifs
  #
  # Check each path for 'sh'
  #
  for i in $@
  do
  if [ -f ${i}/sh ];
  then
  Pshell=${i}/sh
  fi
  done
  #
  # This is the list of scripts to update. They should be of the
  # form '${name}.source' and will be transformed to '${name}'.
  # Each script should begin:
  #
  # !INSTALLSHELLPATH -p
  #
  scripts="a b c"
  #
  # Transform each script
  #
  for i in ${scripts}
  do
  sed -e "s|INSTALLSHELLPATH|${Pshell}|" < ${i}.source > ${i}
  done

It is terrifying!  It's every single BAD shell practice all thrown together
into a single example!

1) Attempting to save IFS in a variable and restore it.  This fails if IFS
   is originally unset.

2) Unquoted $(command) substitution, relying on IFS word splitting but
   forgetting to disable globbing.

3) for i in $@
   instead of: for i in "$@"
   or simply: for i

   There is NO excuse for this sloppiness.  None.  Let alone from people
   writing an official POSIX manual!

4) Unquoted ${i} expansions all over the place.  Putting in useless curly
   braces is NOT a substitute for quoting.

5) Inconsistent use of useless curly braces.  If you're going to use them
   around i and Pshell, why omit them around IFS, Sifs and @?  (Of course,
   I would just omit *all* of them.)

6) Storing a space-delimited list in a string variable (scripts="...")
   and then using it as a pseudo-array, again without disabling globbing.
   What makes this one *especially* bad is that the example already used
   the @ pseudo-array earlier.  The author *knows* how to use @ instead
   of a string variable, but didn't do it!

THIS is what we're fighting against.  40 years of this.

So, in short, avoid the older books, manuals, tutorials and examples.
And be cautious even of the newer ones.

> ---

> The "test" expression used is "A = B". There are operators like "-o" for
> logical "or". "A -o B" is true if a is true, or if be is true, or both are
> true.

Do not use -o and -a in a test command.  It's not portable.  Instead,
use two separate test commands with || or && between them:

if [ A ] || [ B ]; then
 ...
fi

See http://mywiki.wooledge.org/BashPitfalls#pf6

> For substring search you would have to employ a program like "grep".
> It returns 0 if something was found, else it returns 1.
> 
>   if hostname | grep 'bob' >/dev/null ; then echo bob.cfg ; fi

grep -q 'bob' is slightly more efficient than grep 'bob' 

Re: Failed to execute child process (no such file or directory), but the script DOES exist in $HOME/bin, openbox users, especially take a look, please.

[Greg Wooledge]

On Tue, Sep 27, 2016 at 03:15:54PM +0100, Brian wrote:
> Ok, let's go along with ~/.xsessionrc being the simplest way for a user
> to configure his X session. I'll follow the advice on the wiki and have
> 
>   PATH=~/bin:$PATH
>   xterm &
>   iceweasel &
>   exec fvwm

No, this is not what I advised.  You don't start a window manager from
this file.

> Putting 'exec fvwm' in ~/.xsession is the solution, of course; it's your
> best friend, so may as well put everything else there. What price this
> upstart ~/.xsessionrc? Does it ever get anything right? The only thing
> it is good for is getting round restrictions set by the administrator.

You are not a beginner.  You're advanced.

A beginner would just install *one* window manager, and this
would be executed automatically by the Debian X session (via the
/usr/bin/x-window-manager symlink ultimately).  (S)he would use
a ~/.xsessionrc file only to set the PATH variable, or JAVA_HOME, or
whatever the original question is.

You don't need a ~/.xsession file until you get to the point where
you want to install multiple WMs at the same time and choose among
them.  And even then, at that point, many beginners will still prefer
update-alternatives (as root) over editing a ~/.xsession file in their
own home directory.  This may shock you, since you have a strong
Linux or Unix background, but I see it all the time.  These are the
same people who think putting a colored PS1 prompt in /etc/bash.bashrc
is a Really Awesome Idea.

Re: Failed to execute child process (no such file or directory), but the script DOES exist in $HOME/bin, openbox users, especially take a look, please.

[Greg Wooledge]

On Mon, Sep 26, 2016 at 05:58:59PM -0400, Neal P. Murphy wrote:
> A semantic observation (probably unrelated to the aforementioned editing):
> "... dot in ..." might be more clearly stated as "... source ( or '.') in
> ..." because the action is to source the script into the current shell (thus
> retaining the defined vars), as opposed to executing the script in another
> shell or in a subshell (thus the var definitions are lost when the shell or
> subshell exits).

I explicitly avoided the word "source" because it is a bash extension,
and thus will not work in the POSIX sh that reads these files.

If you could go back in time to ~1978 and put the "source" command into
the Bourne shell, so that it would be a recognized command in all of
the Bourne family shells today, then we wouldn't have this confusion.

Re: Failed to execute child process (no such file or directory), but the script DOES exist in $HOME/bin, openbox users, especially take a look, please.

[Greg Wooledge]

On Mon, Sep 26, 2016 at 10:46:07PM -0700, Seeker wrote:
> It's possible that something changed with gdm3 after I stopped using it, 
> or that it's been long enough I just don't remember, but I don't 
> remember any of these in recent years using the .xsession file if you 
> use a session other than the default session.

OK, good.  That matches what the debian-reference documentation says,
and what I wrote on the wiki.

I also have this file, from back in my experimenting-with-gdm days:

titan:~$ ls -l .gnomerc
-rw-r--r-- 1 greg greg 36 Jun 28  2002 .gnomerc
titan:~$ cat .gnomerc
[ -f ~/.xsession ] && . ~/.xsession

So that might be why my ~/.xsession was being read -- because it was
dotted in from ~/.gnomerc, which was read by either gdm or whatever
gdm executed.

It was 14 years ago, so I don't remember every detail.

Re: Substring search in dash [ _NOT_ bash ] shell

[Greg Wooledge]

On Tue, Sep 27, 2016 at 05:05:08PM +0200, Thomas Schmitt wrote:
> Greg Wooledge wrote:
> > Do not use -o and -a in a test command.
> > http://mywiki.wooledge.org/BashPitfalls#pf6
> 
> As if anybody would dare to touch the old "test" command. :))
> 
> Rather i avoid "[" brackets, not to allow any implementor an excuse.
> But in plaintext mode i wanted to stay near to the given original example.
> It worked when i tested in dash and bash.

The test and [ commands have the same features and limitations.  The only
difference is the final argument of [ has to be ].

People do run into the problem occasionally in real life:

https://lists.gnu.org/archive/html/bug-bash/2015-07/msg00125.html

But, I will admit it's rare.  (And hard to Google, though this is mostly
due to Google's extremely inconvenient refusal to let you use punctuation
in searches.)

Re: Failed to execute child process (no such file or directory), but the script DOES exist in $HOME/bin, openbox users, especially take a look, please.

[Greg Wooledge]

On Tue, Sep 27, 2016 at 04:52:34PM +0100, Brian wrote:
> You need a ~/.xsession file when you need a ~/.xsession file. Isn't it
> one purpose of the wiki to explain how it fits into the traditional X
> configuration and why one might be useful. Instead, we appear to have
> ~/.xsessionrc promoted as the One True Way; how did you come to that
> conclusion?

Because it is the only thing that *actually works* no matter which
display manager and which session type the user is running.  If the
user is running gdm3 and using a GNOME session and wants to add a
directory to PATH, ~/.xsessionrc can do that.  If the user is running
startx, ~/.xsessionrc still works.  If the user is running lightdm
with a Debian X session, ~/.xsessionrc still works.

In fact, that's why Debian *created* it.  They wanted something that
would Just Work.  There was no existing tool that could fill that role.

If you prefer ~/.xsession because you've already learned never to run
gdm3, great.  Go ahead and use that.  I use ~/.xsession myself.  I
didn't even know about ~/.xsessionrc until I started down this path
and someone linked to the debian-reference web page.  That's where I
learned about it.  Its purpose was immediately clear to me.

Now I have an answer for the end-user questions that have been stumping
me for years... at least in #debian.  #bash is another story.

Re: Canon printer minor quibble

[Greg Wooledge]

On Fri, Sep 30, 2016 at 03:49:23PM -0500, David Wright wrote:
> "CUPS is the standards-based, open source printing system developed by
> Apple Inc. for macOS® and other UNIX®-like operating systems."
> 
> which is stretching the truth IMHO, given the normal meaning of "for",
> "and", and "other", written in that order. Calling it "Common UNIX
> Printing System" would blow that out of the water.

Their use of "developed by" is rather jaw-dropping as well.  Perhaps
they mean it in the sense of "maintained by", but I think most people
would read it as "created by" which is blatantly untrue.

Re: Canon printer minor quibble

[Greg Wooledge]

On Fri, Sep 30, 2016 at 03:37:55PM +0100, Brian wrote:
> On Fri 30 Sep 2016 at 16:20:03 +0200, Frank wrote:
> > It is. Check (most of) the entries in the blog at
> > https://www.cups.org/blog.html from 10 Jul 2000 to 15 Dec 2008.
> 
> I thought it was obvious we were talking about now, not the past. ESP
> was sold to Apple in 2007. The change in naming would not have been
> carried out immediately. There appears to have been a year's delay, for
> whatever reason.

We are talking about right now.  The name CUPS is clearly an acronym
that stands for Common Unix Printing System (or "UNIX" if you prefer).
Everyone who uses CUPS knows this.  It's the dirty little secret that
Apple can no longer admit, because lawyers.

You are doublethinking.  In your world, CUPS isn't an acronym, and you
have always been at war with Eastasia.

Or, you are a lawyer.  In which case, you have my pity.

Re: Canon printer minor quibble

[Greg Wooledge]

On Fri, Sep 30, 2016 at 03:51:27PM +0100, Brian wrote:
> The People
> can continue to say what they want but it does not change the fact that
> the official name of the software is CUPS.

Yes, that is the new Official Name.

Nobody(*) gives a flying leap what the Official Name is.  The question was
what CUPS stands for.  It stands for Common Unix (or UNIX) Printing System.

(*) Except lawyers, and you.

Re: PROGRESS - was [Re: My bash script is missing something - what?]

[Greg Wooledge]

On Mon, Oct 10, 2016 at 05:19:34PM +0100, Peter Hillier-Brook wrote:
> Ignoring your youth, you need to precede your script with a valid path
> such as './' :-)

He did.

Re: dependencies problem to install lightworks on jessie

[Greg Wooledge]

On Fri, Oct 28, 2016 at 07:19:47PM +0100, Brian wrote:
> 4. There is a way to get your error mesaages in English but I have
>forgotten how. Someone will be along in a while to explain how it
>is done.

If you're working from a command shell, you can do:

export LC_ALL=C

and then the rest of your commands should all produce output in the
"C" locale (traditional US English, ASCII characters only).

If you're working with a GUI, then all bets are off.  You might be able
to restart the GUI application with the locale variables set differently,
but if it's something like a display manager invoked directly from
/sbin/init then it could become difficult.  Or, the GUI application may
have its own internal language selection.

Re: Permissions for an entire PARTITION

[Greg Wooledge]

On Fri, Oct 28, 2016 at 10:28:54AM -0500, Richard Owlett wrote:
> I'll attempt to refine my problem definition.
> My primary use case is a laptop:
>   1. purchased explicitly for use as a test bed.
>   2. whose HD has been erased multiple times in ONE day.
>   3. is isolated from ANY network.
>   4. has multiple installs of Debian, primarily classed as:
>  a. a full GUI install - what one would get choosing all 
> installer defaults.
>  b. a GUI install limited to the tools I use routinely.
>  c. an install oriented to whatever my current experiment needs.
>   5. has 2 classes of "DATA Partitions":
>  a. those which UID 1000 may mount without entering any 
> password.
>  b. those which *ANY* user may mount only by using root 
> password.
> The second use case is an existing machine with WinXP which is 
> why I do not wish these "DATA Partitions" to be Windows readable.

Simply creating a Linux file system (ext3 or whatever) on the partition
should be enough to prevent Windows from mounting it (or "mapping" it,
or whatever Windows calls the act of opening up a file system for
use by applications).

> My original question had (apparently incorrectly assume that 
> partitions handled user/group/world permissions in the same 
> manner as file systems.

If you want to write files on this partition, it has to be formatted
with some kind of file system, and then mounted.  If the file system
is a unix-like one, then it will have unix file metadata like ownership,
group ownership and permissions.

> I gather that I can approximately solve the problem with 
> appropriate entries in /etc/fstab (pointer to good tutorial 
> please). That approach has short comings:

man fstab

Consider using file system labels so that you don't have to put cryptic
UUIDs into the fstab, or potentially volatile device names.

man e2label

>1. requires custom editing of /etc/fstab for each install.
>2. requires custom editing of /etc/fstab for each install
>   whenever a partition is added.

There is absolutely no way you're going to be able to mount a file system
as an ordinary user (UID 1000 or whatever) without putting a line in the
/etc/fstab file.  So then the goal becomes to make this process as easy
and foolproof as possible for yourself, or for whoever's doing these
hourly wipes and reinstalls.  I'd recommend e2label for this.

I don't know why you need users to be able to mount the file system via
commands, instead of just having them automatically mounted at boot time.
/etc/fstab would also be used for the latter.  That's how most file systems
work (/, /usr, /var, /home, etc.).

Re: Strange Problem with 'alias'

[Greg Wooledge]

On Tue, Nov 08, 2016 at 02:37:34PM -0500, Henning wrote:
> Put your aliases into .bash_ptofile

No, don't do that.  Make your login shell profile source or dot in
~/.bashrc instead.

Re: debian 6.0.4 apt sources.list

[Greg Wooledge]

On Wed, Nov 09, 2016 at 09:41:52AM +0100, basti wrote:
> Hello,
> debian 6 is End-of-Life since 31. Mai 2014 (29. Februar 2016 for LTS), I
> recommend am upgrade.
> If it is not possible try "deb http://archive.debian.org/debian/ squeeze
> contrib main non-free" in sources.list,
> see https://www.debian.org/distrib/archive for more Infos.

Also see https://wiki.debian.org/DebianSqueeze which suggests using
these two lines:

deb http://archive.debian.org/debian squeeze main
deb http://archive.debian.org/debian squeeze-lts main

There is also a note about adding an option in /etc/apt/apt.conf to work
around an expired key.

Re: [Proposal] Update debian installion guide. Part 4.3.3.2.

[Greg Wooledge]

On Wed, Nov 09, 2016 at 10:04:56PM +0700, billwill onggo wrote:
> @maintainers, you might want make some changes in your 'installation guide',
> 
> @all, if there is no maintainers here, how can i reach them?

I would try the debian-boot list first.
https://lists.debian.org/debian-boot/

Re: apt-get changelog is unsuccessful, but changelog exists

[Greg Wooledge]

On Sat, Nov 05, 2016 at 08:25:02PM +, david...@freevolt.org wrote:
> On Sat, 5 Nov 2016, Brian wrote:
> >Wheezy is an unsupported distribution, just like hamm, etch, potato etc.
> >Irrespective of whether it was thought to be wonderful in its day it is
> >now moribund apart from LTS.
> 
> We seem to have different understandings of what LTS stands for.
> 
> Interesting.

At least remember what the "S" stands for (Brian).

There are plenty of people still running wheezy, and there will be for
many years to come (long after wheezy LTS is discontinued).  If you don't
wish to support it, that's fine -- you can simply not reply.

Re: parted is ALMOST suitable

[Greg Wooledge]

On Mon, Nov 07, 2016 at 03:27:12PM +0100, to...@tuxteam.de wrote:
> Two things:
>  - check that your disk devices are actually readable (and probably
>writable, I botched that, cf. David's mail) by group disk
>  - your being added to disk is effective *after* logging in after
>you'd made the change; if you want to bypass it, there is the
>command 'newgrp'; you can check which groups you are "in" by
>issuing the command 'groups': 'disk' should be in there.

I started writing that in my previous message, but then I actually
tested it on my own system.  Good thing I did, because I got the
same result as Richard: being in group disk, which has read/write
access on /dev/sda*, does NOT give you output in the FSTYPE and other
fields of lsblk -f.  It certainly surprised me.

$ sudo adduser wooledg disk
Adding user `wooledg' to group `disk' ...
Adding user wooledg to group disk
Done.

$ su - wooledg -c 'LANG=C; id; lsblk -f'
Password: 
uid=563(wooledg) gid=563(wooledg) 
groups=563(wooledg),6(disk),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev)
NAME   FSTYPE LABEL UUID MOUNTPOINT
sda  
|-sda1   
|-sda2   /
`-sda3   [SWAP]
sr0  

Whatever lsblk wants in order to read the FSTYPE, I don't know, but
group disk membership is not sufficient.  (On jessie.)

I still suggest just sucking it up and using sudo like a normal person.

Re: parted is ALMOST suitable

[Greg Wooledge]

On Mon, Nov 07, 2016 at 08:18:28AM -0600, Richard Owlett wrote:
> Evidently not a solution. Added myself to both "disk" and "root" 
> groups.
> Had no effect when attempting to run either lsblk or parted.

Is there a reason you can't use sudo?

Sample output on my system at work:

$ lsblk -f
NAME   FSTYPE LABEL UUID MOUNTPOINT
sda  
|-sda1   
|-sda2   /
`-sda3   [SWAP]
sr0  

$ sudo lsblk -f
[sudo] password for wooledg: 
NAME   FSTYPE LABEL   UUID MOUNTPOINT
sda
|-sda1 ntfs   Windows FE0EDCF30EDCA5C5 
|-sda2 ext4   1a20ffb7-897c-4373-84c1-14089a6deab8 /
`-sda3 swap   b8d67062-8262-476d-9370-8166f7572fd3 [SWAP]
sr0

You can even configure sudo not to prompt you for a password.
Certain operations on a Linux system simply require root privileges,
and your insistence on "not having to be root" is not rational.

Re: looking for a piece of software that will take an url (say to a blog post) and email me the contents

[Greg Wooledge]

On Sat, Nov 05, 2016 at 03:01:14PM -0700, Dan Hitt wrote:
> Does anybody know of a piece of software that you can give an URL to,
> and it will then fetch the url and email the contents to you?

#!/bin/sh
# Usage: scriptname URL recipient [...]
url=$1
shift
lynx -dump "$url" | mail -s "Web page: $url" "$@"


Of course, much depends on what you mean by "contents".  I'm assuming
you want a plain text rendering, which is what lynx -dump does.  Then
again, I'm old-fashioned, and I consider HTML email one of the signs of
the apocalypse.  If you actually *want* HTML email, then maybe you
would prefer some different solution.

You could also get fancy and have the script use the EMAIL environment
variable as the recipient, etc.  It's up to you.

Re: Trivial script will NOT execute

[Greg Wooledge]

On Sat, Nov 05, 2016 at 10:42:46AM -0500, David Wright wrote:
> The current working directory is included here three times???at the
> beginning, middle and end.
> 
> :/usr/bin::/bin:.

Including the current directory in one's PATH (either by using "."
explicitly, or by using an empty string) is considered a bad practice.
It opens you up to certain exploits by malicious users.

The classic example is that a malicious user puts a program named "sl"
in the /tmp directory, and waits for someone (preferably root) to
change directory to /tmp and then mistype "ls" as "sl".  This runs the
malicious user's program with the other user's privileges.

Thus, it's strongly recommended that you do *not* put the current
working directory into PATH.  If you need to execute a program in
the current directory, you can invoke it with a leading ./

./myscript

This bypasses the PATH lookup (because the command name contains a
slash character).  The leading "." is simply a directory name, not
anything magic to the shell.

> One other point. I see you use spaces in your filenames. Regardless of
> this, you should quote your strings in such as FILENAME=$F$N$E

In a simple assignment like that, you don't need to quote.  Word
splitting and pathname expansion are not performed, for legacy
reasons.  However, quoting doesn't hurt.

http://mywiki.wooledge.org/Quotes

Re: parted is ALMOST suitable

[Greg Wooledge]

On Mon, Nov 07, 2016 at 09:57:14AM -0600, Richard Owlett wrote:
> In any case, off-list someone suggested using
>/sbin/blkid /dev/sda*
> That works. *BUT* I wonder about unknown implications of "/sbin" 
> being required if not explicitly running as root.

It's simply because /sbin is not in your default PATH as a regular user.
Most of the commands in /sbin require root privileges to do their jobs,
but there are a few that don't, at least for certain limited parts of
their jobs.  (/sbin/ifconfig is probably the most famous.)

If you want to run this command without root privileges, you can add
/sbin to your PATH.  This is not a security problem.  It's just that most
regular users don't need these commands.  There is a minuscule decrease
in efficiency when another directory in PATH has to be searched, but
it's probably not going to be noticeable.

Re: Debian repository: no updates for PygreSQL package

[Greg Wooledge]

On Thu, Nov 10, 2016 at 09:01:22AM +0900, Mark Fletcher wrote:
> Current stable is Debian 8 (Jessie). And it is not likely to pick up new 
> versions either. It became stable a couple of years back (sorry I don't 
> remember exactly when and don't have time to look it up, but you can see 
> on Debian's website).

Remember, remember,
The Fifth of November,
Gunpowder treason and plot;
For I see no reason
Why Gunpowder Treason
Should ever be forgot.

Jessie was frozen on November 5, 2014.  The date is also known as Guy
Fawkes Day in the UK.

Stretch's "transition freeze" was initiated on November 5, 2016.
Or at least it was supposed to have been.

Re: Problem attempting to use xorriso

[Greg Wooledge]

On Thu, Nov 10, 2016 at 02:53:14PM +, Lisi Reisz wrote:
> Richard - are you clear that the permissions are not for the partitions but 
> for the directories on the mount points on the filing system on which those 
> partitions have been hung??  This can be hard to grasp, but it can and does 
> sometimes make a difference, e.g. if the same partition or device gets 
> mounted somewhere else.
> 
> Being slightly older than you, Richard and coming from the pre-electronic 
> computer generation, I am hoping to grasp and understand the basic Unix 
> filing system finally some time before I keel over.  (I *think* that 
> electronic computers are slightly older than you are.) ;-)

Well, let's see if I can shed some light here.  Probably not, but
I'll try.

At the bottom layer of this whole thing, we've got actual hardware.
The computer can make the disk retrieve ("read") or store ("write")
information by modifying the voltage on various wires.  The kernel
knows how to tell the computer to do this (by dark magic).  The kernel
can, for example, read byte number 13543287 of the disk.

Storing all of your information in one gigantic chunk is not always
the best policy, so you have the ability to subdivide the disk into
"partitions".  Each partition is then treated as a separate hunk of
bytes.  The kernel also knows about these, and it can request byte
number 9986351 of partition number 3.

Even with partitions, retrieving information from a disk in this way
would be terribly inconvenient for most applications, so this is almost
never done.  Instead, there is another layer: the file system.  A disk,
or a partition, can have an organizational structure laid on top of
it which allows information to be stored in "files" which have names.
Instead of requesting byte number 9986351 of partition number 3, you can
request byte number 0 of the file named "bin/ls" inside the file system on
partition number 3.  This is the layer at which most applications operate.

Following the unix philosophy, the kernel presents an interface to each
of these layers, including access controls.

For the raw disk layer, there is a block device like /dev/sda.  You
can read byte number 13543287 of /dev/sda and see what it is.  In
order to do this, you need read permission on the /dev/sda file.

At the partition layer, there are block devices like /dev/sda3.  You
can read byte number 9986351 of /dev/sda3 and see what it is.  For
this, you need read permission on the /dev/sda3 file.

Those are simplistic layers, and not often used.  Pretty much the only
time you would ever read from one of those devices is to retrieve the
partition table from the disk, or to see what kind of file system is on
a given partition.  Lower level tools like mkfs and fsck and fdisk and
lsblk handle these details.

Things become much more interesting when we move up to the file system
layer.

The first thing to know about file systems is that they have to be
"mounted" in order to work.  The word "mount" comes from old tape drive
technology (reel to reel), when operators would be requested to mount
a tape, which is a physical act not dissimilar to hanging a picture on
a wall.  It has been adopted for file systems, even though there isn't
a physical movement of objects.

In order to mount a file system, you need to know which disk or partition
the file system is stored on, and what directory you want to attach it to.
You also have to be root, because this is a potentially VERY intrusive
thing to do.  If an ordinary user could mount a file system on /bin then
he could easily take over the whole system, because users would be
executing HIS version of /bin/ls and so on.

Typically the directory where you mount a file system is just an empty
stub.  But it doesn't have to be.  Let's say you have a single file
system (/) mounted currently, and it has a directory called "home" in
it.  Now let's say you've got some files in this directory.  If you mount
/dev/sda3 on /home then the contents of /dev/sda3's file system become
visible inside /home.  The files that you saw in /home BEFORE the mount
are hidden.  They're still in the / file system but you can't see them
or interact with them.

The second thing you need to know about file systems is that they
have their own metadata.  File ownerships, permissions, and so on are
stored within the inodes (index nodes) of the file system.  When you
mount the file system, you see only the files and the metadata from
the mounted file system.  The metadata of the directory that you mounted
it on is no longer relevant.  The metadata of the block device that
stores the file system is also irrelevant.

Before mounting:
drwxr-xr-x 4 john doe 4096 Aug 22 11:41 /home

After mounting:
drwxr-xr-x 4 root root 4096 Sep 22 11:41 /home

Block device:
brw-rw 1 root disk 8, 3 Nov  1 09:39 /dev/sda3

The group "disk" may have write access to /dev/sda3, but that doesn't
let them write to /home.  The permissions of /dev/sda3 are not relevant
when operating 

Re: My bash script is missing something - what?

[Greg Wooledge]

On Mon, Oct 10, 2016 at 11:51:37AM -0400, songbird wrote:
> Richard Owlett wrote:
> > I have a trivial bash script named test.sh which has been marked 
> > as executable.

>   also remember that test itself is a builtin
> or binary on some systems.

It's required by POSIX, so it will be a command on *every* system.
Whether it's a shell builtin is not specified, but every modern shell
makes it a builtin -- even dash.

>   you may be running on thing and thinking
> you are running another.
> 
>   in this particular case with the .sh 
> extension you are safe, but forget that
> once and ...

Yes, this is excellent advice.  After being bitten by this once or twice
in my early Unix years, I stopped making commands called "test" and made
commands called "foo", "bar", "foobar", etc.