Re: Got that network problem solved, now a new one

--------------------------|

John L. Ries              |

Salford Systems           |

Phone: (619)543-8880 x107 |

or     (435)867-8885      |

--------------------------|

On May 18, 2016, at 7:41 PM, Gene Heskett <gheskett@shentel.net> wrote:

On Wednesday 18 May 2016 19:09:02 John L. Ries wrote:

I guess my first question would be why the script below has anything
to do with /opt. I don't see a change of directory to anything under
that directory and I would assume this is running in some directory
you own.

Nope, this script, and the directories it mv's around, all live in the
root of /opt, and I've been running it that way since 2013. This is
just one of the reasons that I go buy a fresh drive for each new
install, so I can copy all this history from install to install, usually
with mc.

System directory permissions are sometimes changed during software
updates; annoying, but true. I sometimes have to change permissions
on /usr/local/src for that reason.

Good point, although I haven't built anything there, or in /src/src in
yonks, it all gets built in ~/src, no suprises that way.

I don't know about your system, but on most, chown can only be run by
root.

Depends, in this case I own the files as they were just generated by me.
And ISTR I am a member of group www-data. Just checked, yes.

I don't see any bash specific syntax in your script, so you might try
running it under a different Bourne compatible shell (perhaps ash,
dash, or ksh) to see if it works there. This will hopefully rule out
the possibility of a bash bug.

John L. Ries
Salford Systems
Phone: (619)543-8880 x107
or     (435)867-8885
________________________________
From: Logan Erbst <logan@iccamnetworking.us>
Sent: Wednesday, May 18, 2016 5:34 PM
To: debian-user@lists.debian.org
Subject: Re: Got that network problem solved, now a new one

This seems to me that it may be a bug in the version of bash that is
running on the system, but I could be very wrong.

To address that:
gene@coyote:/$ ls -l `locate bin/bash`
-rwxr-xr-x 1 root root 941252 Sep 25 2014 /bin/bash
-rwxr-xr-x 1 root root   6966 Sep 25 2014 /usr/bin/bashbug
gene@coyote:/$ file /bin/bash
/bin/bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux
2.6.26, BuildID[sha1]=1fd3c09266e0feec964431a11fbf7f1132acdb44, stripped

But this script has been run successfully several times since the date on
that /bin/bash.

But the kernel running now is:
gene@coyote:/$ uname -r
3.16.0-0.bpo.4-amd64

This is a 32 bit system for 2 reasons, most annoying being that the 64
bit kernels have horrible interrupt latency so linuxcnc will not even
launch, and while it will run with the 32 bit rtai patched kernels,
there no PAE in those patches so I am a gigabyte or more into swap in 48
hours uptime. With this amd64 kernel, its sees all the memory and takes
weeks to get 200 megs into swap. And this kernel runs the simulated
linuxcnc just fine so I can sit, hack out a thousand lines of gcode and
exercise it cutting virtual air from a nice comfy office chair. Quite
important when I've 2 collapsed disks in my back.

So I'm still bumfuzzled as to why it should suddenly fail. Its worked
for 3+ years.

Does anyone think Dash might be worth a shot?

Thanks, to both of you.

On 5/18/2016 4:42 PM, Gene Heskett wrote:

Greetings all;

I am, because my web page serves as a backup site for the os and some
tools for use with the now 30 year old trs-80 color computers, have a
script IP can run that pulls fresh copies of the sources for this code
using hg, then builds fresh copies and makes it all available on my
web page.

Unfortunately that script, running as me, suddenly has no write
permissions to do what it does. This has been working for several
years.

This is the script:
============================
#!/bin/bash
# since I'm always forgetting who I am
if [ `whoami` != 'gene' ]; then
       echo
       echo "!!!!!!!!!!!!!!!!!! Warning !!!!!!!!!!!!!!!!!!!"
       echo "this script needs to be run by user gene"
       echo
       echo
       exit 1
fi
mv lwtools lwtools-$(date +%Y-%m-%d-%H-%M)
hg clone http://lwtools.projects.l-w.ca/hg/ lwtools
cd lwtools
make
sudo make install
cd ..
echo
echo
echo "lwtools has been built, next is toolshed"
echo
echo
chown -R gene:www-data lwtools # make visible to the web
mv toolshed toolshed-$(date +%Y-%m-%d-%H-%M)
hg clone http://hg.code.sf.net/p/toolshed/code toolshed
cd toolshed
make -C build/unix
sudo make install
cd hdbdos
make
cd ../..
chown -R gene:www-data toolshed
echo
echo
echo "toolshed has been built and installed, next is nitros9"
echo
echo
mv nitros9 nitros9-$(date +%Y-%m-%d-%H-%M)
hg clone http://hg.code.sf.net/p/nitros9/code nitros9
cd nitros9
export NITROS9DIR=$PWD
hgpull;hgupdate
mkdir dsks # this step is temporarily needed
make dsk
make dskcopy
cd ..
chown -R gene:www-data nitros9
echo
echo "nitros9 has been refreshed"
echo "this completes the build of lwtools, toolshed, and nitros9"
==================================
and its now being denied at the first mv operation. /opt of course is
owned by root:root but that hasn't changed in 18 years of running
linux. This script has been running flawlessly about once a month
since July 2013 when I wrote it.

So what was changed to prevent the common user from using /opt as
himself? cd'd to /opt, I can't even "touch ajunkfile". Grrrrrr. Me,
goes in search of my LART.

Better yet, how can I fix it? /opt permissions are 40755, and I'm
assuming a chmod 0777 as root would fix it temporarily, but thats one
hell of a kludge. I'd much rather find where the rules to this game
are and get them fixed.

Thanks all.

Cheers, Gene Heskett

--
Logan Erbst
Member Free Software Foundation

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>