how to substitute the remote login menu for the regular login text box in CDE.

how to substitute the remote login menu for the regular login text box in CDE.

Post by joao coel » Thu, 18 Mar 2004 23:38:24



I want to login remotely from the login text box in the login window.
I want to disable the remote login and force the user to login through
the login text box.  I would like to then capture the user login and
depending on a certain user, i login the user in to a remote box.  All
using CDE.
 
 
 

how to substitute the remote login menu for the regular login text box in CDE.

Post by ta.. » Sun, 21 Mar 2004 01:48:00



Quote:> I want to login remotely from the login text box in the login window.
> I want to disable the remote login and force the user to login through
> the login text box.  I would like to then capture the user login and
> depending on a certain user, i login the user in to a remote box.  All
> using CDE.

you can copy /usr/dt/conifg and /usr/dt/appconfig to /etc/dt

you then can edit /etc/dt/config/C/Xresources
to change the behavior of dtlogin.

to disable the remote host menu you can uncomment the line:
!Dtlogin*remote_host_menu*sensitive:      False

by removing the ! in front of it.
Now as far as captureing the user name and password and based on the user
name transparently log that user into another remote display i dont see
an easy way to do this. i cant think of anything that uses only
dtlogin and the standard sun X tools.

I did play around with this though and found a solution.

you need to install ssh on the local machine and the remote machine.
then you need to use ssh-keygen to crate an ssh key for passwordless login to
the remote host by the user you have selected to transparently login to a
remote machine.

the following are the steps you need to take to disable the remote host menu
and force a specific user to log into the remote host and run CDE.

install ssh either openssh or preferably sun's SSH which is installed by
default in Solaris 8 and 9.

make sure that sshd is running on the remote host.

mkdir /etc/dt and  run
cp -r /usr/dt/config /etc/dt/
open up /etc/dt/config/C/Xresources in a text editor and remove the ! in
!Dtlogin*remote_host_menu*sensitive:      False

create a user account on the local machine for the user you want to redirect.
login as that user and run ssh-keygen

just hit enter when prompted for a passphrase.

login to the users account on the remote machine and create the directory .ssh
in his home directory.
copy the $HOME/.ssh/id_rsa.pub file on the local machine to the
$HOME/.ssh/authorized_keys file

next you have to create a xsession script in the users home directory on the
remote machine it should look like this:

#!/bin/ksh
export DISPLAY=$1
/usr/dt/bin/Xsession

make sure this xsession script is executable or it wont work.

on the local machine create a .dtprofile file with the following contents.
SESSIONTYPE=xdm
DTSOURCEPROFILE=true

that will cause the Xsession script to run the .xsession script in the users
home directory instead of attempting to start CDE on the local machine.

the .xsession script needs to be executable and should look like this.
just replace ryoko with the name of the remote host and /opt/home/talon with
the home directory of the user on the remote host.
#!/bin/sh
scp .Xauthority ryoko:
scp .TTauthority ryoko:
ssh ryoko /opt/home/talon/xsession $HOSTNAME:0

this can also be done using rsh but its even less secure than what I've
described.

it may also be possible to encrypt all X traffic by using ssh X11 forwarding
but i havent tested that.

If youve followed the steps above this is what should happen:

1. a user logs in using dtlogin on a sun workstation.
if the user doesnt have a .dtprofile with SESSIONTYPE=xdm  in it and
a .xsession file CDE is started on the local workstation as normal.
if he does have the modified .dtsession and .xsession files it will

copy the .Xauthority and .TTauthority files to the remote host and execute the
xsession script on the remote host which sets DISPLAY to the hostname and
display number of the workstation. and runs Xsession. This will pop up CDE
running on the remote machine onto the workstation display just as if he had
logged in through a remote dtlogin on the remote machine.

 
 
 

how to substitute the remote login menu for the regular login text box in CDE.

Post by joao coel » Wed, 24 Mar 2004 00:23:43


Thank you for your help.  I just started reading your response and i
am still digesting it.  I have been playing with rlogin instead from
the user's sessionetc file.  As i was reading this weekend the book X
Window System User's Guide, i also got some ideas that i wanted to
try.  But my boss at this point is thinking that we may be spending
too much time with this issue, which i my own opinion does not deserve
this much work.  Here is the problem we are trying to solve.  Our
current application is a unixware app that is character based. It runs
on one server with a secondary server running as a back up of data.
These two servers run the application on large forest fires. One
server is the primary and runs the app the other is a secondary and
acts as a tape backup of the database at a specified interval.  In the
current system if a a certain user needs to use the secondary system
to access the database they need to cross login to the primary and
have the application run remotely on the secondary.  So if i am on
secondary and i type at the login prompt user1 for example, a script
knowing that this user must go to the primary system will rlogin that
user to the primary system. I personally think that Solaris has that
problem solved for us, because if i login to the remote system from
the login window, it sends me directly to the primary and brings up
the dtterm window where the application runs.  It would be nice not to
force the user to click on two more buttons, but it's not vital.  Your
solution sounds interesting but as i said we may just go the regular
route after all, howeve i am interested in what you did as we may want
to go ahead and provide such flexibility.  Thanks.


> > I want to login remotely from the login text box in the login window.
> > I want to disable the remote login and force the user to login through
> > the login text box.  I would like to then capture the user login and
> > depending on a certain user, i login the user in to a remote box.  All
> > using CDE.

> you can copy /usr/dt/conifg and /usr/dt/appconfig to /etc/dt

> you then can edit /etc/dt/config/C/Xresources
> to change the behavior of dtlogin.

> to disable the remote host menu you can uncomment the line:
> !Dtlogin*remote_host_menu*sensitive:      False

> by removing the ! in front of it.
> Now as far as captureing the user name and password and based on the user
> name transparently log that user into another remote display i dont see
> an easy way to do this. i cant think of anything that uses only
> dtlogin and the standard sun X tools.

> I did play around with this though and found a solution.

> you need to install ssh on the local machine and the remote machine.
> then you need to use ssh-keygen to crate an ssh key for passwordless login to
> the remote host by the user you have selected to transparently login to a
> remote machine.

> the following are the steps you need to take to disable the remote host menu
> and force a specific user to log into the remote host and run CDE.

> install ssh either openssh or preferably sun's SSH which is installed by
> default in Solaris 8 and 9.

> make sure that sshd is running on the remote host.

> mkdir /etc/dt and  run
> cp -r /usr/dt/config /etc/dt/
> open up /etc/dt/config/C/Xresources in a text editor and remove the ! in
> !Dtlogin*remote_host_menu*sensitive:      False

> create a user account on the local machine for the user you want to redirect.
> login as that user and run ssh-keygen

> just hit enter when prompted for a passphrase.

> login to the users account on the remote machine and create the directory .ssh
> in his home directory.
> copy the $HOME/.ssh/id_rsa.pub file on the local machine to the
> $HOME/.ssh/authorized_keys file

> next you have to create a xsession script in the users home directory on the
> remote machine it should look like this:

> #!/bin/ksh
> export DISPLAY=$1
> /usr/dt/bin/Xsession

> make sure this xsession script is executable or it wont work.

> on the local machine create a .dtprofile file with the following contents.
> SESSIONTYPE=xdm
> DTSOURCEPROFILE=true

> that will cause the Xsession script to run the .xsession script in the users
> home directory instead of attempting to start CDE on the local machine.

> the .xsession script needs to be executable and should look like this.
> just replace ryoko with the name of the remote host and /opt/home/talon with
> the home directory of the user on the remote host.
> #!/bin/sh
> scp .Xauthority ryoko:
> scp .TTauthority ryoko:
> ssh ryoko /opt/home/talon/xsession $HOSTNAME:0

> this can also be done using rsh but its even less secure than what I've
> described.

> it may also be possible to encrypt all X traffic by using ssh X11 forwarding
> but i havent tested that.

> If youve followed the steps above this is what should happen:

> 1. a user logs in using dtlogin on a sun workstation.
> if the user doesnt have a .dtprofile with SESSIONTYPE=xdm  in it and
> a .xsession file CDE is started on the local workstation as normal.
> if he does have the modified .dtsession and .xsession files it will

> copy the .Xauthority and .TTauthority files to the remote host and execute the
> xsession script on the remote host which sets DISPLAY to the hostname and
> display number of the workstation. and runs Xsession. This will pop up CDE
> running on the remote machine onto the workstation display just as if he had
> logged in through a remote dtlogin on the remote machine.

 
 
 

1. CDE: root can login but not regular users

I'm trying to get CDE working again on a Enterprise 450 running Solaris
2.7 (upgraded from 2.6, CDE broke doing the upgrade).  From the
console, root can log in, but other users (at the console or remotely)
get bumped back to the logon screen after choosing to run CDE.  If you
choose Openwindows, it works just fine, it's just CDE that doesn't
work.  Any ideas would be appreciated.

I reinstalled the CDE pkgs, so all configs should be default with
nothing in /etc/dt.

I checked permissions and got

$ ls -lL /dev/zero
crw-rw-rw-   1 root     sys       13, 12 Jun  6 22:53 /dev/zero
$ ls -lL /dev/null
crw-rw-rw-   1 root     sys       13,  2 Jul  7 14:05 /dev/null
$ ls -lL /dev/tic*
crw-rw-rw-   1 root     sys      105,  2 Jun  6 22:53 /dev/ticlts
crw-rw-rw-   1 root     sys      105,  0 Jun  6 22:53 /dev/ticots
crw-rw-rw-   1 root     sys      105,  1 Jun  6 22:53 /dev/ticotsord

drwxrwxrwt   7 sys      sys         1145 Jul  7 13:27 tmp

I checked /var/dt/Xerrors and got

fbconsole: tcgetattr: No such device or address
/usr/openwin/bin/xset:  bad font path element (#41), possible causes
are:
    Directory does not exist or has wrong permissions
    Directory missing fonts.dir
    Incorrect font server address or syntax
Warning: Cannot convert string "<Key>Escape,_Key_Cancel" to type
VirtualBinding
Warning: Cannot convert string "<Key>Home,_Key_Begin" to type
VirtualBinding
Warning: Cannot convert string "<Key>F1,_Key_Help" to type
VirtualBinding
Warning: Cannot convert string "Shift<Key>F10,_Key_Menu" to type
VirtualBinding
Warning: Cannot convert string "<Key>F10,Shift_Key_Menu" to type
VirtualBinding
Warning: Cannot convert string "<Key>KP_Enter,_Key_Execute" to type
VirtualBindi
ng
Warning: Cannot convert string "Alt<Key>Return,Alt_Key_KP_Enter" to
type Virtual
Binding
Warning: Cannot convert string "<Key>Escape,_Key_Cancel" to type
VirtualBinding
Warning: Cannot convert string "<Key>Home,_Key_Begin" to type
VirtualBinding
Warning: Cannot convert string "<Key>F1,_Key_Help" to type
VirtualBinding
Warning: Cannot convert string "Shift<Key>F10,_Key_Menu" to type
VirtualBinding
Warning: Cannot convert string "<Key>F10,Shift_Key_Menu" to type
VirtualBinding
Warning: Cannot convert string "<Key>KP_Enter,_Key_Execute" to type
VirtualBindi
ng
Warning: Cannot convert string "Alt<Key>Return,Alt_Key_KP_Enter" to
type Virtual
Bindin

Thanks,

Johnny

Sent via Deja.com http://www.deja.com/
Before you buy.

2. help-usenet!

3. regular can not login in with CDE

4. Multithreaded Public Domain Webserver.

5. cde login does not read .login Solaris 2.5.1

6. Passwd Seg fault??

7. Login problem with root, but can successfully login with other user to access CDE

8. PCMCIA (WaveLAN) adapter problems

9. Help! Command login ok, CDE login fails

10. Problem with CDE login with login script

11. (Solaris 2.5 x86) CDE and text console login problems- please help.

12. Change graphic login to text-bsed login

13. How can I change text login in prompt to GUI login prompt