Status for Andrew DeFaria

Rexec, gpdb_add_project.pl and Nice

I've been making some slow but steady progress with gpdb_add_project.pl. I've:

• Implemented an Rexec Perl module that allows better access to remote sites. It does this by attempting ssh then rsh and finally telnet in an attempt to contact the remote site. It's object oriented and allows you to repeatedly execute remote commands without having to repeatedly login. Finally it can take a different username than the person running the script.
• David then got me set up with a generic gpdb user for the Dallas and Nice sites.

In attempting to use the new generic gpdb user I encountered a few problems. The biggest difference isg pdb user is tcsh (and csh I think) oriented whereas the Rexec module assumes a Borne/Ksh/Bash orientation. This has caused a number of problems:

1. When logging onto the system the prompt is different (csh style shells use "%")
2. When logging onto the Nice site not only is the prompt different but it contains special characters. It uses embedded escape sequences that colorize the prompt. Rexec needs to find the prompt so it knows when it can send commands. Needless to say this si problematic forRexec. For now I set the prompt for gpdb@Nice to simply "% ", which works.
3. Some of the commands that gpdb_add_project.pl issues are decidedly Borne shell oriented. For example, it uses 2>&1 to combine stdout and stderr. This syntax is not valid under csh style shells. Additionally, Rexec would wrap commands in an "echo start; <cmd>; echo errono=$?" in order to obtain the return status of the remotely executed command. The $? variable is not available in csh style shells. So I added a shellstyle parameter to Rexec to handle these differences (though that doesn't fix #2).

One way around all of these problems is to require generic service level accounts such as gpdb to run the default Borne shell (/bin/sh).

Next, and forgive me since my NIS is a bit rusty, but gpdb_add_project.pl would attempt to get certain NIS maps for remote sites that use NIS (it is also NIS+ aware/sensitive). In doing so it does an ls -1 /etc then looks for files such as auto_master. It then cat's auto_master and looks for lines that have "+auto" or "data" in them. It then uses that as a key file for ypcat as in ypcat -k auto_master.

Now @Nice (svrscity01.tif.ti.com) it finds:

% cat /etc/auto_master
# Master map for automounter
#
+auto_master
/xfn -xfn
/net -hosts      -intr,rw,grpid

So it then does ypcat -k auto_master which:

% ypcat -k auto_master
no such map in server's domain

The following does work though:

% ypcat -k auto.master
/clearcase auto.clearcase
/home_drp auto.home_drp -intr,ro
/apps_drp auto.apps_drp -intr,ro
/db_drp auto.db_drp -intr,ro
/user auto.user -intr,rw,grpid
/tool auto.tool -intr,rw,grpid,noquota,noatime
/home auto.home -intr,rw,grpid
/apps auto.tool -intr,rw,grpid,noquota,noatime
/xfn -xfn -noquota
/sim auto.sim
/net -hosts -intr,rw,grpid,noquota
/db auto.db
/u auto.tool -intr,rw,grpid,noquota

It appears to be trying to find the auto_data map, of which there are none, and then will look for "sync_custom" in there. As such I don't see how this ever worked at Nice.

Thoughts? Pointers?

Cygwin, Samba and ssh

Here's the story. I use Cygwin on my XP desktop. I like having a home directory on Windows that is the same home directory on Unix/Linux machines. Often companies offer access to your Unix/Linux home directory via Samba. Also, often companies do not bother to set up a Samba server wish participates in a domain, so the Samba server is configured as being in a workgroup.

Now for a long time I struggled with this. I would map //<samba server>/<home share> -> my H drive then mount the H drive as /home and make sure my Cygwin /etc/password referred to my home directory of /home/$USER. All is great.

But when dealing with Samba servers who are configured into workgroups innocuous activities in Cygwin would elicit permission denied messages. For example, touching a file in the home directory and indeed even vi'ing a file, etc. Creating a file within Windows Explorer or using other Windows oriented tools would work just fine. Files created on the Unix/Linux side would also work fine but when looked at from Cygwin on the PC would have odd (read "nobody") ownerships and permissions.

Of course as Cygwin is often not supported by the typical company's IT department and because many people do not attempt to utilize Cygwin fully often requests for assistance and change fell on deaf ears...

Eventually I figured out that my Windows SID in /etc/passwd is the SID of my domain user and since the Samba server was not in the domain my SID does not authenticate properly. Then I had a break through in that I realized that I was using SMBNTSEC as well as NTSEC in my Cygwin environment. I figured "Yeah I want to use the same Windows security for SMB mounted drives too". This is where my problem lies and it's because the Samba server configured by the client does not participate in the Windows domain from which I've logged in.

Now I'm pretty sure that Samba could be configured properly into a Windows domain as Samba can be configured as a PDC or a BDC, but many clients don't bother to go that far. So why is Windows able to deal with this but not Cygwin?

I believe that this is because within Samba a very basic approach is kept towards storing of user identification information. Indeed basic Samba just has an smbpasswd file which is much like your typical Unix/Linux /etc/passwd file and it is not designed to carry extra information about users and machine accounts as well as multiple groups and trust associations, etc. Even Samba documents talks about hooking Samba up to either LDAP or what they call a Trivial DataBase (TDB) in order to store such additional Windows only information.

So I thought the simple solution was to remove SMBNTSEC from my Cygwin environment and all would be fine. And indeed it is! Well almost...

Along comes ssh... So I like to use ssh to log into various Unix/Linux systems as I work. And again I share my home directory between Windows and Unix/Linux. Finally I like setting up passwordless public key ssh login as I'm not one of those who likes having to type in his password hundreds of times a day. But ssh's is picky about permissions of your ~/.ssh and ~/.ssh/id_<type> key files. When ssh'ing from Cygwin to a Unix/Linux box I am now receiving the following:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/x0062320/.ssh/id_rsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /home/x0062320/.ssh/id_rsa
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/x0062320/.ssh/id_dsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /home/x0062320/.ssh/id_dsa
x0062320@stashu's password:

And, of course, I need to type in my password again! What I believe is happening is that because my home directory is SMB mounted and SMBNTSEC is off then Cygwin reports that files like ~/.ssh/id_rsa are 0644 even if I change them on Unix/Linux to 0600. So, for example:

<unix box>$ ls -l ~/.ssh/id_rsa
-rw-------  1 x0062320 generic 887 Aug 31 16:43 /home/x0062320/.ssh/id_rsa

While:

<cygwin>$ ls -l ~/.ssh/id_rsa
-rw-r--r-- 1 x0062320 Domain Users 887 Aug 31 16:43 /home/x0062320/.ssh/id_rsa

Is there any way to work around this problem (short of reconfiguring the Samba server)?