<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Justin,<br>
&nbsp;&nbsp;&nbsp; I have verified this issue.&nbsp; Its not quite what it seems.&nbsp; The real
issue at hand is that the CLUSTER_USER gets created with the same UID
as the existing ubuntu user.&nbsp; So anything that uses a UID is going to
report back the 'ubuntu' user rather than the CLUSTER_USER.&nbsp;
Starcluster needs to get rid of or replace the ubuntu user or use a new
starting UID/GID.&nbsp; But we would have to be careful to make sure that
sudo still works, since that is indexed by name rather than uid.&nbsp; In
this case, its just luck that sudo works for the CLUSTER_USER since the
UID matches the ubuntu user.&nbsp; The GIDs collide as well.<br>
<br>
&nbsp;&nbsp;&nbsp; To reproduce, do the following:<br>
pip install starcluster<br>
pip install boto=1.9b&nbsp; # to get the working version of boto<br>
starcluster createvolume 1 use-east-1a<br>
# edit your .starcluster/config to use the new volume and mount it at
/home<br>
starcluster start smallcluster<br>
<br>
Here is a variety of the consequences:<br>
<tt><br>
$ grep 1000 /etc/passwd<br>
ubuntu:x:1000:1000:Ubuntu,,,:/home/ubuntu:/bin/bash<br>
sgeadmin:x:1000:1000::/home/sgeadmin:/bin/bash<br>
<br>
$ grep 1000 /etc/group<br>
ubuntu:x:1000:<br>
sgeadmin:x:1000:<br>
<br>
ubuntu@domU-12-31-38-04-C8-B5:~$ w<br>
&nbsp;13:30:30 up 19 min,&nbsp; 1 user,&nbsp; load average: 0.00, 0.00, 0.00<br>
USER&nbsp;&nbsp;&nbsp;&nbsp; TTY&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FROM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LOGIN@&nbsp;&nbsp; IDLE&nbsp;&nbsp; JCPU&nbsp;&nbsp; PCPU WHAT<br>
sgeadmin pts/1&nbsp;&nbsp;&nbsp; oh-76-1-37-133.d 13:29&nbsp;&nbsp;&nbsp; 0.00s&nbsp; 0.25s&nbsp; 0.00s w<br>
<br>
ubuntu@domU-12-31-38-04-C8-B5:~$ id<br>
uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu)<br>
<br>
ubuntu@domU-12-31-38-04-C8-B5:~$ ls -l /home/<br>
total 20<br>
drwx------ 2 root&nbsp;&nbsp; root&nbsp;&nbsp; 16384 2010-10-15 13:06 lost+found<br>
drwxr-xr-x 4 ubuntu ubuntu&nbsp; 4096 2010-10-15 13:20 sgeadmin</tt><br>
<br>
Austin<br>
<br>
On 10/14/2010 04:58 PM, Justin Riley wrote:
<blockquote cite="mid:4CB76EFA.8020309@mit.edu" type="cite">
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
  <br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
  <br>
Hi Adam,<br>
  <br>
Sorry for the late response.<br>
  <br>
There is some magic that occurs when creating users in order to avoid<br>
having to chmod /home folders which might contain hundreds of<br>
gigabytes of data. Basically, StarCluster inspects the top level<br>
folders under the /home folder and if the CLUSTER_USER's home folder<br>
already exists, then the CLUSTER_USER is created with the same uid/gid<br>
as the existing home folder to avoid a recursive chmod. Otherwise,<br>
StarCluster looks at the uid/gid of the other directories in /home and<br>
chooses the highest gid/uid combo plus 1 to be the uid/gid for the<br>
CLUSTER_USER. If that calculation ends up with a uid/gid less than<br>
1000 then it defaults to 1000 for the gid/uid of CLUSTER_USER.<br>
  <br>
A couple questions that might help me to understand what happened:<br>
  <br>
1. I'm assuming you must have had MOUNT_PATH=/home for the volume in<br>
your cluster template's VOLUME list, correct?<br>
  <br>
2. Did your volume already contain a 'sgeadmin' folder at the root of<br>
the volume?<br>
  <br>
3. What does "ls -l" look like on the root of the volume that exhibits<br>
this behavior?<br>
  <br>
Also, you will find useful information about the uid/gid chosen by<br>
StarCluster for the CLUSTER_USER in your debug file:<br>
  <br>
/tmp/starcluster-debug-&lt;your_username&gt;.log<br>
  <br>
(if you're on mac, this file will be in the directory returned by<br>
"python -c 'import tempfile; print tempfile.gettempdir()'")<br>
  <br>
Just grepping for gid or uid in your log file(s) should print out the<br>
relevant messages: "grep -ri gid /tmp/starcluster-*"<br>
  <br>
~Justin<br>
  <br>
  <br>
On 10/3/10 5:19 PM, Adam Marsh wrote:<br>
  <span style="white-space: pre;">&gt;<br>
  <br>
&gt; I've had some challenges to getting SC running correctly<br>
when EBS<br>
  <br>
&gt; volumes are mounted to the head node during configuration.<br>
I<br>
  <br>
&gt; initially setup the EBS volumes with database files by<br>
first<br>
  <br>
&gt; configuring and mounting the volume on any available EC2 VM<br>
I had<br>
  <br>
&gt; running at the time. By default, most of the time I was<br>
working as<br>
  <br>
&gt; user 'ubuntu'. However, whenever an EBS volume with files<br>
or folders<br>
  <br>
&gt; having 'ubuntu' as the owner and group were included in the<br>
VOLUMES<br>
  <br>
&gt; list of the SC config file and were mounted during setup to<br>
the head<br>
  <br>
&gt; node, two odd things occurred:<br>
  <br>
&gt; 1. when the cluster_user account was setup by SC (like<br>
'sgeadmin'),<br>
  <br>
&gt; the owner and user of the /sgeadmin folder under /home was<br>
'ubuntu';<br>
  <br>
&gt; 2. connecting via ssh to the sgeadmin account always<br>
defaulted to<br>
  <br>
&gt; logging in to the 'ubuntu' user account.<br>
  <br>
&gt;<br>
  <br>
&gt; I worked around the problem by changing own/grp settings on<br>
all EBS<br>
  <br>
&gt; folders/files to the cluster_user name used in the config<br>
file.<br>
  <br>
&gt; All works fine now.<br>
  <br>
&gt;<br>
  <br>
&gt; Is this just a rare instance of SC system behavior? If not,<br>
is there<br>
  <br>
&gt; a better way to prepare EBS volumes for use with SC to<br>
avoid own/grp<br>
  <br>
&gt; conflicts?<br>
  <br>
&gt;<br>
  <br>
&gt; Thanks,<br>
  <br>
&gt;<br>
  <br>
&gt; &lt;Adam<br>
  <br>
&gt; <br>
  <br>
&gt;</span><br>
  <br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.16 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla - <a moz-do-not-send="true"
 class="moz-txt-link-freetext" href="http://enigmail.mozdev.org/">http://enigmail.mozdev.org/</a><br>
  <br>
iEYEARECAAYFAky3bvoACgkQ4llAkMfDcrnhgQCeNx/PPR9pg01D626krxXQcv8L<br>
M9cAn2vXyBmjMUMHqGU0PT94+ffR2xm4<br>
=VX9F<br>
-----END PGP SIGNATURE-----<br>
  <br>
  <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
StarCluster mailing list
<a class="moz-txt-link-abbreviated" href="mailto:StarCluster@mit.edu">StarCluster@mit.edu</a>
<a class="moz-txt-link-freetext" href="http://mailman.mit.edu/mailman/listinfo/starcluster">http://mailman.mit.edu/mailman/listinfo/starcluster</a>
  </pre>
</blockquote>
<br>
</body>
</html>