Re: Got that network problem solved, now a new one
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>
Reply to: