[Glass] problem with stone log and permissions :(

Tue Feb 7 06:19:35 PST 2017

Hi Dale,

I am reviving an old thread. I quote your most important part:

-----
*"I've looked at the c code and when we do a fork we do a chdir() to the
`workingDirectory` and throw the error that you see if the chdir() fails..*

*It looks like startstone does a fork using '.' as the working directory so
it is literally using the current directory (i.e., environment variables
are involved at all) when it does the fork. *
*"*
*-----*

As you know, after I create a stone via `createStone` I do:

sudo chown -R $gsDevKitUser:$stoneOSUser $GS_HOME/server/stones/myStone

And then, all the starts/stops of stone, netldi and gems are triggered with
the OS user $stoneOSUse. So far so good. But I have 2 scenarios:

1) Me (a sysadmin) logs into the system with a given OS user. Say you are
ate /home/mariano. You do "sudo su $stoneOSUse" and then try to start
stone. That will fail, becasue current dir is "/home/mariano" and
$stoneOSUse does not have access to it. So..everything I do this I must do
a "cd" to a place that i know it can fork (like $GS_HOME).

2) Monit trying to start/restart my stuff. Same problem. Monit is started
by root and the given user $stoneOSUse cannot fork on the current
directory.

I have been suffering this problem already with my `startAllStones` and
`stopAllStones` as well as with my `startSeasideGems`.

Anyway, the workaround I did is pretty simple, and it's the place where you
do:

# set up stone environment
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

I added a line "cd $stonePath" before that and everything works correct. I
cannot imagine GsDevKit_home code that would break if I change working dir.
Maybe there is, but I haven't faced it yet. If you think we are safe and
you think this is correct, then I could like to add this to `startStone`
and `stopStone` in a issue + PR.

Another possibility would be to do it in a much generic place to avoid
modifying each script. Say..in `${GS_HOME}/bin/private/shFeedback`  we
could do "cd $GS_HOME" but maybe too risky ?

Thoughts ?

On Fri, Sep 19, 2014 at 2:26 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

>
>
> On Fri, Sep 19, 2014 at 2:05 PM, Dale Henrichs <
> dale.henrichs at gemtalksystems.com> wrote:
>
>> Mariano,
>>
>> I've looked at the c code and when we do a fork we do a chdir() to the
>> `workingDirectory` and throw the error that you see if the chdir() fails..
>>
>> It looks like startstone does a fork using '.' as the working directory
>> so it is literally using the current directory (i.e., environment variables
>> are involved at all) when it does the fork.
>>
>>
> OK, you needed to go deep to look. I appreciate your dedication!
> At least we have an explanation now :)
>
>
>> you can embed the cd in the -c arg for su, if it makes it any less of a
>> pain:
>>
>> su  $RUNASUSER -c "cd /somePath; '$GEMSTONE_INSTALLATION/bin/startstone
>> -z $GEMSTONE_SYS_CONF -l $APPLICATION_LOG_DIR/log.txt $APPLICATION_NAME >
>> $GEMSTONE_LOGDIR/startup.log 2>&1'"
>>
>>
> Exactly. That's what I ended up doing. And since all my scripts pass that
> line in order to start stone and netlid...just 2 little changes were enough
> to fix everything.
>
> Thanks Dale.
>
> Dale
>>
>>
>>
>>
>> On Thu, Sep 18, 2014 at 7:57 PM, Mariano Martinez Peck <
>> marianopeck at gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Sep 18, 2014 at 2:18 PM, Dale Henrichs <
>>> dale.henrichs at gemtalksystems.com> wrote:
>>>
>>>> Okay, there are several things going on here ... first off, we don't
>>>> recommend that you have GEMSTONE_NRS_ALL set in your startstone environment
>>>> ... in 3.1.0.6 GEMSTONE_NRS_ALL is not consistently applied and in 3.2.3
>>>> and beyond the GEMSTONE_NRS_ALL will be ignored by the startstone command.
>>>> We recommend that you use `-l` to set the log location for the stone, as
>>>> you are doing...
>>>>
>>>> The GEMSTONE_NRS_ALL isn't directly involved, but it does tend to
>>>> confuse things ...
>>>>
>>>>
>>> Ok, I will remove it then.
>>>
>>>
>>>> We haven't reproduced your problem here, but we believe that the
>>>> problem is related to the fact that when you use `su username` the "current
>>>> environment is passed to the new shell" and startstone is probably cd'ing
>>>> to $HOME which is /home/marianopeck/.
>>>>
>>>>
>>> Well..the strange thing is that BEFORE I run the startsone I source a
>>> file with all the variables I export for that site. And one of the things I
>>> export is:
>>>
>>> export HOME=/somePath
>>>
>>> I mean...I export $HOME to the correct place where the stone is and
>>> where the user I then su do have access. So at the time I run:
>>>
>>>
>>> su -m $RUNASUSER -c '$GEMSTONE_INSTALLATION/bin/startstone -z
>>> $GEMSTONE_SYS_CONF -l $APPLICATION_LOG_DIR/log.txt $APPLICATION_NAME >
>>> $GEMSTONE_LOGDIR/startup.log 2>&1 '
>>>
>>> I must have (and I have just checked) the correct $HOME.
>>>
>>> So I still don't understand why the startstone would try to read
>>> /home/marianopeck.
>>>
>>>
>>>> You should try using `su --login username` as the environment for the
>>>> new shell is "similar to what the user would expect had the user logged in
>>>> directly" and startstone will cd to the $HOME for `username`.
>>>>
>>>>
>>> Yes, but I can't do that because otherwise I lost all the vars of the
>>> stone I previously exported. If you see again:
>>>
>>>
>>> su -m $RUNASUSER -c '$GEMSTONE_INSTALLATION/bin/startstone -z
>>> $GEMSTONE_SYS_CONF -l $APPLICATION_LOG_DIR/log.txt $APPLICATION_NAME >
>>> $GEMSTONE_LOGDIR/startup.log 2>&1 '
>>>
>>> if I replace -m for a -l there...all those vars inside the -c will be
>>> gone.
>>>
>>>
>>> Now...something I checked...if I fire this stone start scripts not in
>>> /home/marianopeck but in /somePath (where the user that runs the stone has
>>> access -? $RUNASUSER), then it works perfectly... But it is a pain having
>>> to cd there in order to start the stone...
>>>
>>> Any other idea?  maybe startstone is NOT reading $HOME but $PWD ?
>>>
>>>
>>> Let's see how that works...
>>>>
>>>> Dale
>>>>
>>>> On Wed, Sep 17, 2014 at 9:32 PM, Mariano Martinez Peck via Glass <
>>>> glass at lists.gemtalksystems.com> wrote:
>>>>
>>>>> Hi guys,
>>>>>
>>>>> I am trying to be a bit more strict in file permissions for my stones.
>>>>> When I now try to start a stone, I get this error:
>>>>>
>>>>> startstone[Info]: GemStone version '3.1.0.6'
>>>>> startstone[Info]: Starting Stone repository monitor 'debrisTesting2'.
>>>>> startstone[Info]: GEMSTONE is: '/opt/gemstone/product'.
>>>>> startstone[Info]: GEMSTONE_NRS_ALL is: '#dir:/somePath/data#log:/
>>>>> somePath/log/%N%P.log'.
>>>>> startstone[Info]:
>>>>>     GEMSTONE_SYS_CONF=/somePath/etc/system.conf
>>>>>     GEMSTONE_EXE_CONF=/somePath/etc/gem.conf
>>>>>  ___________________________________________________________
>>>>> __________________
>>>>> |              ERROR:  chdir(/home/marianopeck/) failure:
>>>>>         |
>>>>> |       System Error:  errno=13,EACCES, Authorization failure
>>>>> (permission denied)
>>>>> |___________________________________________________________
>>>>> __________________|
>>>>>
>>>>> startstone[Error]: Stone process (id=25917) has died.
>>>>> startstone[Error]: Could not show end of log file
>>>>> '/somePath/log/log.txt' because: errno=2,ENOENT, The file or directory
>>>>> specified cannot be found
>>>>>
>>>>> So it looks like it cannot create '/somePath/log/log.txt'.
>>>>>
>>>>> The stone is launched this way as part of a larger script.
>>>>>
>>>>>   su  $RUNASUSER -c '$GEMSTONE_INSTALLATION/bin/startstone -z
>>>>> $GEMSTONE_SYS_CONF -l $APPLICATION_LOG_DIR/log.txt $APPLICATION_NAME >
>>>>> $GEMSTONE_LOGDIR/startup.log 2>&1'
>>>>>
>>>>> And then that script is invoked with sudo from my username
>>>>> marianopeck..
>>>>>
>>>>> What I don't understand is why it cannot create the log and why it
>>>>> does a "  chdir(/home/marianopeck/) "
>>>>>
>>>>>
>>>>> Finally...if from comand line I do:
>>>>>
>>>>> sudo su $RUNASUSER -c " touch '/somePath/log/log.txt' "
>>>>>
>>>>> I can create it with no problem.
>>>>>
>>>>> Any idea what could be happening?
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> --
>>>>> Mariano
>>>>> http://marianopeck.wordpress.com
>>>>>
>>>>> _______________________________________________
>>>>> Glass mailing list
>>>>> Glass at lists.gemtalksystems.com
>>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170207/aec9a0b7/attachment.html>