Installation of SCREEN with multi access

  • Follow


I'm currently working on a client's system (SunOS 5.8).  Screen has been 
installed.  I'm trying to get it running such that when it's active, 
others can look at my screens.

Screen has been installed twice on this system (that I know of).  Once 
for general use (other clients and users) and once for the material I'm 
setting up.  The one for me is installed under my own data tree.  This 
was done because I need to set up things (such as multi-access) that 
they don't want under general access.

One problem I've got is that whoever installed it didn't provide access 
to the man pages for screen; I've been working with what I can find on 
the web, and it doesn't necessarily match up.



The default screenrc file has been modified with "multiuser on" and 
"acladd alpha,beta" to identify all allowed users.



I keep on getting the message "Must run suid root for multiuser 
support" whenever I (alpha) try to connect to a beta screen instance or 
vice versa.

It took a while, but the best I've found out so far is that "run suid 
root" actually means "chmod +s screen" in screen's binary directory.

Unfortunately, it doesn't seem to do the job; I still get the error 
message.

(I also get the message when, as alpha and with a detached instance 
called CHK, I type screen -r alpha/CHK.)

How do I make it work?



(Also, on an RHE system I can find the current existing screens listed 
by creator under /var/run/screen as S-alpha, S-beta and the like.  Where 
is the equivalent under SunOS?)



Under RHE, I can attach with "screen -r alpha/CHK" whether I'm alpha or 
beta.  I can have multiple attachments (say, 2 from beta and 1 from 
alpha) all simultaneously to the same screen session.  Judging by the 
screen documentation, I need to use screen -x if someone is already 
attached.



Thanks for any help you can give.



-- 
Ken Andrews
Reyder Axeman, EQ1, Xegony, 52 Paladin (Retired)
Reyder Armoursmith, EQ2, Permafrost, 80 Armoursmith
0
Reply Ken 10/2/2008 9:11:41 PM

Ken Andrews wrote...

>I keep on getting the message "Must run suid root for multiuser 
>support" whenever I (alpha) try to connect to a beta screen instance or 
>vice versa.
>
>It took a while, but the best I've found out so far is that "run suid 
>root" actually means "chmod +s screen" in screen's binary directory.
>
>Unfortunately, it doesn't seem to do the job; I still get the error 
>message.


Did you run "suid root" or "suid alpha"?
What is the ownership of the screen binary? (c.f. you mentioned
screen's binary directory).


0
Reply harryooopotter 10/3/2008 5:06:45 AM


harryooopotter@hotmail.co_ (Harry331) wrote
> Ken Andrews wrote...
 
>>I keep on getting the message "Must run suid root for multiuser 
>>support" whenever I (alpha) try to connect to a beta screen instance
>>or vice versa.
>>
>>It took a while, but the best I've found out so far is that "run suid 
>>root" actually means "chmod +s screen" in screen's binary directory.
>>
>>Unfortunately, it doesn't seem to do the job; I still get the error 
>>message.
> 
> Did you run "suid root" or "suid alpha"?
> What is the ownership of the screen binary? (c.f. you mentioned
> screen's binary directory).

I can't find any program named "suid" to run, so I neither ran "suid
root" nor "suid alpha". 

What I did do was cd to the binaries directory and then "chmod +s
screen".  Ownership of screen is mine, both user and group. 

I also just found out that the system has been configured to
automatically reset things at night.  screen's status of "rwsrwsrwx" had
reverted to "rwxrwxrwx" when I logged on this morning. 



-- 
Reyder Axeman, EQ1, Xegony, 52 Paladin (Retired)
Reyder Armoursmith, EQ2, Permafrost, 80 Armoursmith
0
Reply Ken 10/3/2008 2:11:33 PM

On Oct 3, 7:11=A0am, Ken Andrews <nowh...@nohow.com> wrote:

> I can't find any program named "suid" to run, so I neither ran "suid
> root" nor "suid alpha".
>
> What I did do was cd to the binaries directory and then "chmod +s
> screen". =A0Ownership of screen is mine, both user and group.
>
> I also just found out that the system has been configured to
> automatically reset things at night. =A0screen's status of "rwsrwsrwx" ha=
d
> reverted to "rwxrwxrwx" when I logged on this morning.

suid is not a command.
"suid root" on screen means that the screen binary should be owned
by root, and then it has  been "chmod u+s".

$ su - root
$ cd where_to_find_screen
$ chown root screen
$ chmod u+s screen
0
Reply Harry 10/3/2008 4:05:38 PM

Ken Andrews <nowhere@nohow.com> wrote:
> I'm currently working on a client's system (SunOS 5.8).  Screen has been 
> installed.  I'm trying to get it running such that when it's active, 
> others can look at my screens.
> 
> Screen has been installed twice on this system (that I know of).  Once 
> for general use (other clients and users) and once for the material I'm 
> setting up.  The one for me is installed under my own data tree.  This 
> was done because I need to set up things (such as multi-access) that 
> they don't want under general access.
> 
> One problem I've got is that whoever installed it didn't provide access 
> to the man pages for screen; I've been working with what I can find on 
> the web, and it doesn't necessarily match up.
> 
> 
> 
> The default screenrc file has been modified with "multiuser on" and 
> "acladd alpha,beta" to identify all allowed users.
> 
> 
> 
> I keep on getting the message "Must run suid root for multiuser 
> support" whenever I (alpha) try to connect to a beta screen instance or 
> vice versa.
> 
> It took a while, but the best I've found out so far is that "run suid 
> root" actually means "chmod +s screen" in screen's binary directory.
> 
> Unfortunately, it doesn't seem to do the job; I still get the error 
> message.
> 
> (I also get the message when, as alpha and with a detached instance 
> called CHK, I type screen -r alpha/CHK.)

on one solaris 8 machine I see the screen sessions stored in /tmp/uscreen/
0
Reply Cydrome 10/3/2008 8:05:19 PM

Harry <harryooopotter@hotmail.com> wrote
> On Oct 3, 7:11�am, Ken Andrews <nowh...@nohow.com> wrote:

>> I can't find any program named "suid" to run, so I neither ran "suid
>> root" nor "suid alpha".
>>
>> What I did do was cd to the binaries directory and then "chmod +s
>> screen". �Ownership of screen is mine, both user and group.
>>
>> I also just found out that the system has been configured to
>> automatically reset things at night. �screen's status of "rwsrwsrwx"
>> had reverted to "rwxrwxrwx" when I logged on this morning.
> 
> suid is not a command.
> "suid root" on screen means that the screen binary should be owned
> by root, and then it has  been "chmod u+s".

Confirming (in re the chmod) what I found up above.


> $ su - root
> $ cd where_to_find_screen
> $ chown root screen
> $ chmod u+s screen

Found out about the "root" ownership the hard way, so now I've got
screen correctly owned and chmodded.



Now for a related problem.

I've a detached screen whose existence gets checked every 5 minutes.  
It's supposed to be owned by user beta, but with multi set "on" so alpha 
can attach.

I've set up a crontab entry for beta that does the checking and, if it 
doesn't see the session, restarts it.  So far, so good, it does in fact 
restart it.

On an RHE system, this works perfectly.  The session starts, it's tagged 
with the name SVB (title we apply with -S option), and it's multi.  
Users alpha and beta can both attach to it.

On the Solaris box, however, it's flagged Private.  User beta can 
attach, user alpha cannot.  This is despite the fact that screen is now 
correctly owned by root and correctly chmodded.

If I kick the session manually from a beta login, it's flagged multi and 
both can access.  If it's kicked from crontab, it's flagged private and 
only beta can access.


-- 
Reyder Axeman, EQ1, Xegony, 52 Paladin (Retired)
Reyder Armoursmith, EQ2, Permafrost, 80 Armoursmith
0
Reply Ken 10/4/2008 9:14:48 PM

Cydrome Leader <presence@MUNGEpanix.com> wrote

> on one solaris 8 machine I see the screen sessions stored in
> /tmp/uscreen/ 

Yes, finally found them there on Friday on this one.  Thanks for the 
confirmation.

-- 

Reyder Axeman, EQ1, Xegony, 52 Paladin (Retired)
Reyder Armoursmith, EQ2, Permafrost, 80 Armoursmith
0
Reply Ken 10/4/2008 9:17:01 PM

On Oct 5, 10:17=A0am, Ken Andrews <nowh...@nohow.com> wrote:
> Cydrome Leader <prese...@MUNGEpanix.com> wrote
>
> > on one solaris 8 machine I see the screen sessions stored in
> > /tmp/uscreen/
>
> Yes, finally found them there on Friday on this one. =A0Thanks for the
> confirmation.
>
> --
>
> Reyder Axeman, EQ1, Xegony, 52 Paladin (Retired)
> Reyder Armoursmith, EQ2, Permafrost, 80 Armoursmith

Probably profile related as crontab does not execute a users profile
when it runs unless you explicitly tell it to>
0
Reply Deepdweller 10/5/2008 8:08:53 PM

Deepdweller <barrymcq@gmail.com> wrote

> Probably profile related as crontab does not execute a users profile
> when it runs unless you explicitly tell it to>

Verified.  Turns out that even though it's running a custom install of 
screen, it's still grabbing for the screenrc file in the etc file, rather 
than the one associated with the custom install.  Had to set an environment 
variable to tell it explicitly where to go for the screenrc file.

It works, now, and that's what's important.

Thanks all for suggestions.


Ken Andrews


-- 
Reyder Axeman, EQ1, Xegony, 52 Paladin (Retired)
Reyder Armoursmith, EQ2, Permafrost, 80 Armoursmith
0
Reply Ken 10/8/2008 12:08:51 AM

8 Replies
252 Views

(page loaded in 0.113 seconds)

Similiar Articles:













7/24/2012 8:34:16 AM


Reply: