Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #168047 > unrolled thread

Got that network problem solved, now a new one

Back to article view | Back to linux.debian.user

Contents

  Got that network problem solved, now a new one Gene Heskett <gheskett@shentel.net> - 2016-05-18 23:50 +0200
    Re: Got that network problem solved, now a new one Logan Erbst <logan@iccamnetworking.us> - 2016-05-19 00:40 +0200
      Re: Got that network problem solved, now a new one "John L. Ries" <jries@salford-systems.com> - 2016-05-19 01:10 +0200
        Re: Got that network problem solved, now a new one Gene Heskett <gheskett@shentel.net> - 2016-05-19 03:50 +0200
        Re: Got that network problem solved, now a new one cbannister@slingshot.co.nz - 2016-05-21 18:20 +0200
    Re: Got that network problem solved, now a new one Gene Heskett <gheskett@shentel.net> - 2016-05-19 01:20 +0200
      Re: Got that network problem solved, now a new one David Wright <deblis@lionunicorn.co.uk> - 2016-05-19 05:50 +0200
        Re: Got that network problem solved, now a new one <tomas@tuxteam.de> - 2016-05-19 10:20 +0200
          Re: Got that network problem solved, now a new one Gene Heskett <gheskett@shentel.net> - 2016-05-19 11:50 +0200
            Re: Got that network problem solved, now a new one Lisi Reisz <lisi.reisz@gmail.com> - 2016-05-19 12:00 +0200
              Re: Got that network problem solved, now a new one Gene Heskett <gheskett@shentel.net> - 2016-05-19 13:30 +0200
                Re: Got that network problem solved, now a new one Lisi Reisz <lisi.reisz@gmail.com> - 2016-05-19 15:10 +0200
                  Re: Got that network problem solved, now a new one Gene Heskett <gheskett@shentel.net> - 2016-05-19 18:20 +0200
                    Re: Got that network problem solved, now a new one Dan Purgert <dan@djph.net> - 2016-05-19 18:40 +0200
                      Re: Got that network problem solved, now a new one Gene Heskett <gheskett@shentel.net> - 2016-05-19 19:00 +0200
                Re: Got that network problem solved, now a new one Lisi Reisz <lisi.reisz@gmail.com> - 2016-05-19 15:40 +0200
                  Re: Got that network problem solved, now a new one Gene Heskett <gheskett@shentel.net> - 2016-05-19 18:30 +0200
                  Re: Got that network problem solved, now a new one Bob Bernstein <poobah@ruptured-duck.com> - 2016-05-19 21:30 +0200
            Re: Got that network problem solved, now a new one Gene Heskett <gheskett@shentel.net> - 2016-05-21 13:40 +0200

#168047 — Got that network problem solved, now a new one

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
-- 
"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>

[toc] | [next] | [standalone]

#168050

[Multipart message — attachments visible in raw view] — view raw

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.

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

[toc] | [prev] | [next] | [standalone]

#168054

[Multipart message — attachments visible in raw view] — view raw

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.


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.


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


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.

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

[toc] | [prev] | [next] | [standalone]

#168058

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>

[toc] | [prev] | [next] | [standalone]

#168131

[Please don't top post]

On Wed, May 18, 2016 at 11:09:02PM +0000, 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.
> 
> 
> 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.

That would seem like a serious bug, the package manager doesn't touch the local
tree. I'm guessing it was a 3rd party application which you compiled/installed 
which of course the package manager has no control over.

-- 
The media's the most powerful entity on earth. 
They have the power to make the innocent guilty 
and to make the guilty innocent, and that's power.
 -- Malcolm X

[toc] | [prev] | [next] | [standalone]

#168055

On Wednesday 18 May 2016 17:42:59 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

I did the above, and fixed my script with line ending && so it would bail 
out at the error point, and got two of the 3 of them rebuilt, then 
switched /opt back to 0755 perms.

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>

[toc] | [prev] | [next] | [standalone]

#168060

I feel I've been warned off commenting here in case I come across as a
pontificating know-it-all who's insisting that you do everything in
"My Way". Well, if there are any opinions here about how things
*should* be done, they're nothing to do with me, but just taken from
the FHS (2015-03-19). It uses "must" in the same way that RFCs and
STDs do. Feel free to disagree with any of the observations I make.

On Wed 18 May 2016 at 19:10:10 (-0400), Gene Heskett wrote:
> On Wednesday 18 May 2016 17:42:59 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)

So, assuming you are and were in /opt, you must in the past have had write
permission as user gene to execute a mv.

> > hg clone http://lwtools.projects.l-w.ca/hg/ lwtools
> > cd lwtools
> > make
> > sudo make install

So presumably "gene" is not an alias for "root", ie $UID != 0 or you
wouldn't have bothered to sudo.

> > cd ..
> > echo
> > echo
> > echo "lwtools has been built, next is toolshed"
> > echo
> > echo
> > chown -R gene:www-data lwtools # make visible to the web

Someone pointed out that you could only do this as root.
I don't think this is true. As long as the files were owned by gene,
and gene is in both the old and new groups involved, then there's
no permission problem with changing the group ownership.

> > [ script repeats the same sort of stuff twice more ]

> > ==================================
> > 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.

Well that would suggest you are used to having world write permission
in /opt; very unusual.

> > Better yet, how can I fix it? /opt permissions are 40755,

...which is "correct".

> 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.

Is it possible that you had the same idea three years ago?

> > Thanks all.
> >
> > Cheers, Gene Heskett
> 
> I did the above, and fixed my script with line ending && so it would bail 
> out at the error point,

I don't quite follow you here (the reference to &&), but I assume
you've just set /opt to world-writeable and then run the script.

> and got two of the 3 of them rebuilt, then 
> switched /opt back to 0755 perms.

...which perhaps you didn't remember to do three years ago.

So what changed it back to 755? Well, there are less than obvious ways
like extracting files from a tar archive. That's caught people out in
the past.

It's highly unusual to have /opt world-writable. You, as admin, are
expected to make do with /opt/{bin,doc,include,info,lib,man}/ if
you create them. It's conceivable that an archive might contain,
say:
opt/
opt/lwtools/
opt/lwtools/...
with more conventional directory metadata.

(I couldn't follow the posts about bugs in the shell. What sort of bug
specifically are we, sorry, they, talking about?)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#168063

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, May 18, 2016 at 10:45:12PM -0500, David Wright wrote:
> I feel I've been warned off commenting here in case I come across as a
> pontificating know-it-all who's insisting that you do everything in
> "My Way" [...]

;-)

Yes, I totally agree with David's analysis here. The problem is
the "mv", and the root is in /opt's permissions. Since the script
didn't change, /opt must have been writable by gene in the past,
and not in the present.

Opt's permissions (04755) are "correct", by default /opt shouldn't
be world writable. You might "fix" your problem by making it so,
but you should know the other side of the deal (is this a public
Web server? What if someone hijacks the Apache -- or one of its
underling CGI scripts and starts scribbling over /opt? Things like
that).

What I'd do

Consider making a subdirectory of /opt dedicated to whatever you
are doing with these scripts and setting its ownership to gene
(start as restricted as possible with that and widen as necessary,
e.g. to make parts of it readable to www-data via the group as your
scripts seem to do already.

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlc9df8ACgkQBcgs9XrR2ka7SQCeJJfj2UGgaMfzHEZ4IH8utE33
KmIAnj1+IXCJuPBiVMHvirRqNDJytD+4
=Q2vv
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#168065

On Thursday 19 May 2016 04:14:55 tomas@tuxteam.de wrote:

> On Wed, May 18, 2016 at 10:45:12PM -0500, David Wright wrote:
> > I feel I've been warned off commenting here in case I come across as
> > a pontificating know-it-all who's insisting that you do everything
> > in "My Way" [...]
>
> ;-)
>
> Yes, I totally agree with David's analysis here. The problem is
> the "mv", and the root is in /opt's permissions. Since the script
> didn't change, /opt must have been writable by gene in the past,
> and not in the present.

Apparently true, but it ran just fine, on this install, back on Mar 18, 
2016.

> Opt's permissions (04755) are "correct", by default /opt shouldn't
> be world writable. You might "fix" your problem by making it so,
> but you should know the other side of the deal (is this a public
> Web server?

Yes, its the link in the sig.

> What if someone hijacks the Apache -- or one of its 
> underling CGI scripts and starts scribbling over /opt? Things like
> that).

That apache2 is running bare bones, I don't use any cgi stuff at all.

I changed it to 0777 long enough to be run, then put it back to 0755.

> What I'd do
>
> Consider making a subdirectory of /opt dedicated to whatever you
> are doing with these scripts and setting its ownership to gene
> (start as restricted as possible with that and widen as necessary,
> e.g. to make parts of it readable to www-data via the group as your
> scripts seem to do already.
>
> regards
> -- tomás

That sounds doable, when I wake again.  Thanks Tomas.

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>

[toc] | [prev] | [next] | [standalone]

#168066

On Thursday 19 May 2016 10:48:19 Gene Heskett wrote:
> Yes, its the link in the sig.

Which has been unreachable all morning from here. :-( (Morning by BST=UTC+1)

Lisi

[toc] | [prev] | [next] | [standalone]

#168068

On Thursday 19 May 2016 05:56:49 Lisi Reisz wrote:

> On Thursday 19 May 2016 10:48:19 Gene Heskett wrote:
> > Yes, its the link in the sig.
>
> Which has been unreachable all morning from here. :-( (Morning by
> BST=UTC+1)
>
> Lisi

Thats Lisi, I'll check that out when I wake up again.  Bad night, leg 
cramps, took big B-12, should kick in shortly.

Looking at port forwarding rule, protocol is html, incoming address is 
blank, source port is 6309, fwd is to this machines address on port 80.  
Enabled, so it should Just Work(TM).  But I reset it, then restored my 
config again.  I checked the dns, and it resolves correctly.

Let me know if it still doesn't work.

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>

[toc] | [prev] | [next] | [standalone]

#168069

On Thursday 19 May 2016 12:25:41 Gene Heskett wrote:
> On Thursday 19 May 2016 05:56:49 Lisi Reisz wrote:
> > On Thursday 19 May 2016 10:48:19 Gene Heskett wrote:
> > > Yes, its the link in the sig.
> >
> > Which has been unreachable all morning from here. :-( (Morning by
> > BST=UTC+1)
> >
> > Lisi
>
> Thats Lisi, I'll check that out when I wake up again.  Bad night, leg
> cramps, took big B-12, should kick in shortly.
>
> Looking at port forwarding rule, protocol is html, incoming address is
> blank, source port is 6309, fwd is to this machines address on port 80.
> Enabled, so it should Just Work(TM).  But I reset it, then restored my
> config again.  I checked the dns, and it resolves correctly.
>
> Let me know if it still doesn't work.
>
> Cheers, Gene Heskett

Will reply to Gene off-list as well in order to send a screenshot.  But no, it 
is still not working.  Tried in Chromium and Firefox.

Lisi

[toc] | [prev] | [next] | [standalone]

#168076

On Thursday 19 May 2016 09:04:54 Lisi Reisz wrote:

> On Thursday 19 May 2016 12:25:41 Gene Heskett wrote:
> > On Thursday 19 May 2016 05:56:49 Lisi Reisz wrote:
> > > On Thursday 19 May 2016 10:48:19 Gene Heskett wrote:
> > > > Yes, its the link in the sig.
> > >
> > > Which has been unreachable all morning from here. :-( (Morning by
> > > BST=UTC+1)
> > >
> > > Lisi
> >
> > Thats Lisi, I'll check that out when I wake up again.  Bad night,
> > leg cramps, took big B-12, should kick in shortly.
> >
> > Looking at port forwarding rule, protocol is html, incoming address
> > is blank, source port is 6309, fwd is to this machines address on
> > port 80. Enabled, so it should Just Work(TM).  But I reset it, then
> > restored my config again.  I checked the dns, and it resolves
> > correctly.
> >
> > Let me know if it still doesn't work.
> >
> > Cheers, Gene Heskett
>
> Will reply to Gene off-list as well in order to send a screenshot. 
> But no, it is still not working.  Tried in Chromium and Firefox.
>
> Lisi

For those following along, I had apache2 listening on port 6309, and the 
router was miss-set to port 80.  Ooops.  PEBBAK?  Access.log is now now 
showing some activity.

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>

[toc] | [prev] | [next] | [standalone]

#168078

Gene Heskett wrote:
> On Thursday 19 May 2016 09:04:54 Lisi Reisz wrote:
>> [snip]
>> Will reply to Gene off-list as well in order to send a screenshot. 
>> But no, it is still not working.  Tried in Chromium and Firefox.
>>
>> Lisi
>
> For those following along, I had apache2 listening on port 6309, and the 
> router was miss-set to port 80.  Ooops.  PEBBAK?  Access.log is now now 
> showing some activity.

Yep, looks like it's up now.
-- 
Registered Linux user #585947
Github: https://github.com/dpurgert

[toc] | [prev] | [next] | [standalone]

#168080

On Thursday 19 May 2016 12:24:38 Dan Purgert wrote:

> Gene Heskett wrote:
> > On Thursday 19 May 2016 09:04:54 Lisi Reisz wrote:
> >> [snip]
> >> Will reply to Gene off-list as well in order to send a screenshot.
> >> But no, it is still not working.  Tried in Chromium and Firefox.
> >>
> >> Lisi
> >
> > For those following along, I had apache2 listening on port 6309, and
> > the router was miss-set to port 80.  Ooops.  PEBBAK?  Access.log is
> > now now showing some activity.
>
> Yep, looks like it's up now.

Thanks Dan.

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>

[toc] | [prev] | [next] | [standalone]

#168070

On Thursday 19 May 2016 12:25:41 Gene Heskett wrote:
>
> > cramps, took big B-12, should kick in shortly.

Didn't know that one!  (B12)

Doesn't being old _suck_?

Lisi

[toc] | [prev] | [next] | [standalone]

#168077

On Thursday 19 May 2016 09:30:21 Lisi Reisz wrote:

> On Thursday 19 May 2016 12:25:41 Gene Heskett wrote:
> > > cramps, took big B-12, should kick in shortly.
>
A 2500mg. I have a 250mg in my daily pilltainer, but overdid it a bit 
yesterday, so that wasn't enough.  The Metformin we take for the 
diabetes flushes it out, so you need to put it back in, in wholesale 
amounts.

> Didn't know that one!  (B12)
>
> Doesn't being old _suck_?

Yessum, about 10 EE-33 tor. :)

For the uninitiated, thats equal to about halfway to Alpha-Centari.  
There are mornings when its simply not worth the effort to gnaw thru the 
straps and get up to recycle yesterdays coffee.  But we do anyway.

> Lisi


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>

[toc] | [prev] | [next] | [standalone]

#168084

On Thu, 19 May 2016, Lisi Reisz wrote:

> Doesn't being old _suck_?

Word dat.

-- 
Man is essentially a dreamer, wakened sometimes for a
moment by some peculiarly obtrusive element in the
outer world, but lapsing again quickly into the happy
somnolence of imagination.
                                     Russell

[toc] | [prev] | [next] | [standalone]

#168126

On Thursday 19 May 2016 05:48:19 Gene Heskett wrote:

[...]

> > What I'd do
> >
> > Consider making a subdirectory of /opt dedicated to whatever you
> > are doing with these scripts and setting its ownership to gene
> > (start as restricted as possible with that and widen as necessary,
> > e.g. to make parts of it readable to www-data via the group as your
> > scripts seem to do already.
> >
That has now been done, and all that stuff moved to the subdir, with a 
softlink from the main dir to the latest version, and it seems to work.
ownership and perms on the subdir make it mine.

Thanks for the idea Tomas, works a treat.

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>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web