https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/INSTRM-349 Instrument control development <p>Local (<tt>/etc/{passwd,group</tt>}) and LDAP UIDs and GIDs are different, which makes shared work difficult! Specifically, in a context where we care about the <tt>pfs</tt> GID:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-sh"> cloomis@db-ics:~$ id -a uid=10929(cloomis) gid=2046(coll) groups=2046(coll),992(vpnusers),2044(hsc),2085(pfs) </pre> </div></div> <p> vs.</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-sh"> pfs@db-ics:~$ id -a uid=1000(pfs) gid=1000(pfs) groups=1000(pfs),20(dialout),27(sudo) </pre> </div></div> <p>Not sure how this should be fixed.</p> INSTRM-349

Unify LDAP and local UIDs and GIDs

Task Major Done Done Unassigned cloomis MCS Tue, 1 May 2018 15:48:40 +0000 Fri, 12 Oct 2018 03:46:31 +0000 Mon, 1 Oct 2018 18:21:31 +0000 0 5 <p>need to be checked, but "passwd/user-gid" could work on preseed.</p> <p>At the very least, the LDAP and local <tt>pfs</tt> groups should have different names unless they can have the same GID.</p> <p>The specific problem is temporary and there is a workaround. Development is done by individual users with pfs gid=2085, writing into <tt>/software</tt>. The <tt>pfs</tt> <em>user</em> (with pfs gid=1000) will then run that software. This confusing, but the real problem comes when the actors write files. As long as those directories have gid=1000 we are ok for now.</p> <p>Until INSTRM=322 is done, actor write log files into $ICS_MHS_LOGS_ROOT, which is currently, ugh, <tt>/software/mhs/logs</tt>. I can change that to <tt>/data/logs</tt> and make sure that the <tt>/data</tt> pfs GID is 1000.</p> <p>OK, I linked <tt>/software/mhs/logs</tt> to <tt>/data/logs</tt>, and made all of <tt>/data</tt> gid=1000. As long as only user <tt>pfs</tt> runs actors and other MHS programs, this should work. </p> <p>We still need to unify the LDAP and local IDs.</p> <p>We are going to go clean out of our minds if this does not get fixed. Ideally, the pfs group in the Subaru LDAP can be given gid=1000 (can <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=hiro" class="user-hover" rel="hiro">Yoshida, Hiroshige</a> or <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=atsushi.shimono" class="user-hover" rel="atsushi.shimono">shimono</a> check?). But if that is not possible would a PAM solution work? Something like:</p> <ul class="alternate" type="square"> <li>rename the LDAP <tt>pfs</tt> group to <tt>pfsldap</tt> or something</li> <li>add a <tt>pam_group</tt> line which adds the <tt>pfs gid==1000</tt> group to any member of the <tt>pfsldap</tt> group?</li> </ul> <p>Subaru CDM says 1000-1999 are reserved.</p> <p>it seems we may be better to configure as:</p> <ul> <li>on installation, create the first normal account pfs (uid:1000) with its default group pfs (gid:2085) for all instances (incl. VM guest, NFS server)</li> <li>just load ldap, which has pfs (gid:2085), but does not have pfs user</li> </ul> <p>but this might need a system restart (or better to reinstall?). for short term operation, it might be easier just to add pfs user into gid:2085 ldap group (display will be confusing, but it could work, i think...)?</p> <p><br/> I agree: just use gid=2085 all over. If we can also get uid=2085 that might be clearer, but not essential. LAM and JHU can adapt.</p> <p>There is a bit of a mess at Subaru right now. The <tt>pfs</tt> accounts have pfs gid 1000, but the other accounts have gid 2085. Software was installed by users (me, mostly), so <tt>/software</tt> is almost entirely gid=2085; the exception is <tt>/software/devel/pfs</tt>, which is where <tt>ics_mcsActor</tt> is currently running from. But <tt>/data</tt> (notably <tt>/data/mcs/</tt> and <tt>/data/logs/</tt>) is all pfs gid=1000. You can use <tt>ls -ln</tt> to determine what hides under the lying name.</p> <p>I suggest that <b>after</b> this engineering run we fix up all pfs accounts (notably on <tt>mcs</tt> and <tt>shell-ics</tt>) to gid 2085, and <tt>chgrp -R 2085 /data</tt>, etc. Until then be extra aware of which account you are working as.</p> <p>it seems there is no option to set different group/gid from user/uid in debian installer for now. so, if we define pfs/uid=1000, default group will be pfs/gid=1000. or if we set pfs/uid=2085, default group will be pfs/gid=2085.<br/> <a href="https://salsa.debian.org/installer-team/user-setup/blob/master/user-setup-apply#L123" class="external-link" rel="nofollow">https://salsa.debian.org/installer-team/user-setup/blob/master/user-setup-apply#L123</a></p> <p>so, it seems we need to:</p> <ul> <li>change 'name' between default local account and ldap group. (if so, uid/gid mismatch will not be an issue)</li> <li>use the same 'name' and 'id' among default local account, default local group, and ldap group.</li> </ul> <p>so, this cannot be done at installation (even if we reinstall things), we may run groupmod carefully (like, with checking 'find / -nogroup' or something).</p> <p>Note also that since there is not LDAP <tt>pfs</tt> <em>user</em> (since there cannot be a uid=1000 LDAP user), there is no shared <tt>/home/pfs</tt>: those are different on all the machines. This makes life more difficult.</p> <p>I am inclined to ask for pfs uid=2085 on the Subaru LDAP (<a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=hiro" class="user-hover" rel="hiro">Yoshida, Hiroshige</a>), then change all instances of pfs:pfs to 2085:2085 on all machines. Now: before the 2018-09 engineering run. As <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=atsushi.shimono" class="user-hover" rel="atsushi.shimono">shimono</a> points out we still have to deal with ansible, either nicely or by force. </p> <p>For pfs user home, as we chatted on slack, we will keep how it works now.<br/> (pfs user is meant for admin and needs to be available anytime.)</p> <p> </p> <p>For uid:gid issue, CDM will create pfs user with uid 2085 on our LDAP. We can modify pfs user's id on pfs ics. Could you(<a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a>) confirm that it meets your requirements and fix issues we have now?</p> <p>(<a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=kiaina" class="user-hover" rel="kiaina">Kiaina Schubert</a>) (<a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=hiro" class="user-hover" rel="hiro">Yoshida, Hiroshige</a>) (<a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=atsushi.shimono" class="user-hover" rel="atsushi.shimono">shimono</a>)</p> <p>The important point is that all accounts on all machines look the same all the time. That was a problem because there were two definitions of the <tt>pfs</tt> group: one with gid=1000 from the ansible builds, and one with gid=2085 from the Subaru LDAP. We decided to get rid of all traces of the gid=1000 version. And to keep the uid==gid convention, we decided to get rid of the uid=1000 <tt>pfs</tt> user as well.</p> <p>To get rid of all traces of the 1000s, besides adding pads uid=2085 in the LDAP, all the <tt>/etc/passwd</tt> and <tt>/etc/group</tt> files need to be edited (removing 1000s, adding 2085 <em>only</em> if you do not trust your LDAP). Then <tt>find $everywhere -user 1000 -o -group 1000</tt> and decide what to do &#8211; being careful because chown/chgrp can clear g+s, I believe.</p> <p>And the ansible/pre-ansible Linux provisioning scripts need to be changed.</p> <p> </p> <p>Task-wise, for the most of part, I believe we are on the same page.</p> <p>&gt;Then <tt>find $everywhere -user 1000 -o -group 1000</tt> and decide what to do – being careful because chown/chgrp can clear g+s, I believe.</p> <p>&gt;<br/> Only this part, I may not have the same image to proceed this task. I can be wrong, but I believe Subaru/cdm can work on whatever VM guests/hosts we manage for PFS IT infra services.<br/> However, for VM guests meant for application development, I prefer not to touch it because there is no way to confirm if we did ok... <br/> Can you(<a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a>) let us(<a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=kiaina" class="user-hover" rel="kiaina">Kiaina Schubert</a>, <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=hiro" class="user-hover" rel="hiro">Yoshida, Hiroshige</a>, <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=atsushi.shimono" class="user-hover" rel="atsushi.shimono">shimono</a>) know how you think?</p> <p>&gt;And the ansible/pre-ansible Linux provisioning scripts need to be changed.</p> <p>&gt;<br/> Yes, but not expecting this before Sep run, right? </p> <p>I’ll deal with the VMs. Can you deal with ansible, etc after the Sept run? I’d start by looking at <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=atsushi.shimono" class="user-hover" rel="atsushi.shimono">shimono</a>’s comments.</p> <p>Thank you. If you do not mind, can we confirm the VMs you are going to deal with?</p> <p>Not doubt that we are on the same page, but I believe this change should be consistent on all PFS servers, at least, where Subaru is involved in management for now.</p> <p>So, I am assuming,</p> <ul> <li>gw-ics</li> <li>dnsmasq-ics</li> <li>logger-ics</li> <li>Three vm hosts</li> <li>Four vm guests for monitoring</li> </ul> <p>will be handled by Subaru, and </p> <ul> <li>shell-ics</li> <li>db-ics</li> <li>gen2-ics</li> <li>mhs-ics</li> <li>alert-ics</li> </ul> <p>will be handled by you(<a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a>). Does this sound right?</p> <p>Yes, finally started working on this. A couple of points. </p> <ul class="alternate" type="square"> <li>In ldap, gid 1000 is "gurus", so I imagine you are eager for me to change everything.</li> <li>can you change the login shell for pfs to bash?</li> </ul> <p>&gt;In ldap, gid 1000 is "gurus", so I imagine you are eager for me to change everything.<br/> &gt;<br/> Yes, on these VMs.</p> <ul> <li>shell-ics</li> <li>db-ics</li> <li>gen2-ics</li> <li>mhs-ics</li> <li>alert-ics</li> </ul> <p>I thought what we agreed was</p> <ul> <li>CDM make pfs user id 2085 on our LDAP</li> <li>update pfs user on PFS ICS VMs.</li> <li>We do not touch gid/uid 1000 on LDAP.  </li> </ul> <p>Could you reconfirm what we agreed?</p> <p>&gt;can you change the login shell for pfs to bash?<br/> &gt;<br/> Yes, will do it. This requires interaction with Fujitsu. As soon as this gets done, i will let you know.</p> <p>I confirm that we agreed on all those.</p> <p>And that I am responsible for fixing the system (/etc/</p> {group,password,shadow,gshadow} <p> and user files on the shell/db/gen2/mhs/alert VMs. There will be no files owned by uid 1000 or gid 1000.</p> <p>pfs user's shell is changed to /bin/bash.</p> <p>I see db-ics and shell-ics do not have local pfs user on the VM guests. Since it is not what we agreed, can you (<a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a>) put it back?</p> <p><span class="error">&#91;Ref&#93;</span><br/> pfs@db-ics:~$ grep pfs /etc/passwd<br/> pfs@db-ics:~$ grep sudo /etc/group<br/> sudo:x:27:cloomis<br/> pfs@shell-ics:~$ grep pfs /etc/passwd<br/> pfs@shell-ics:~$ grep sudo /etc/group<br/> sudo:x:27:pfs,cloomis,rhl,hassans</p> <p> </p> <p>I appreciate and respect your work, but these changes are not what we expected. As we chatted on slack, we can consider how pfs/admin account should be. It requires farther consideration and agreement among us, i think. </p> <p>From admin perspective, it may cause big mess though..<br/> <span class="error">&#91;i.e&#93;</span></p> <ul class="alternate" type="square"> <li>LDAP client config messed up. Then, no login until we use run level 1 and fix it...</li> <li>Network interface config messed up. Then, no login until we use run level 1 and fix issue...</li> <li>etc...</li> </ul> <p>Let us know if you have any comments and questions.</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=kiaina" class="user-hover" rel="kiaina">Kiaina Schubert</a>, <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=hiro" class="user-hover" rel="hiro">Yoshida, Hiroshige</a>, <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=naoyuki.tamura" class="user-hover" rel="naoyuki.tamura">naoyuki.tamura</a>, <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=atsushi.shimono" class="user-hover" rel="atsushi.shimono">shimono</a></p> <p> </p> <p>I will put those back in. I had misunderstood what you wanted for the `pfs` user, sorry.</p> <p>I personally believe that you should allow (key-only) root ssh logins. That is the account you really want when things like LDAP or NFS go wrong. And I think it is less of a security risk than requiring password sudo.</p> <p>I think this is done, except for extensions in <a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-501" title="mcs host needs modified pfs user and group IDs" class="issue-link" data-issue-key="INSTRM-501"><del>INSTRM-501</del></a> and <a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-502" title="Settle on emergency and root access to pfs hosts" class="issue-link" data-issue-key="INSTRM-502">INSTRM-502</a>.</p> <p>Craig (<a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a>),</p> <p>Sorry to mention it now. Our part regarding this ticket is not done yet, and planning to do it after MCS run in this month.</p> <p>It is because to fully change UID:GID, we need to touch files stored on shared directory. At least, for MCS run, I believe this should not have negative impact on it.</p> <p>I would prefer to do it after MCS run and with all VMs shutdown to avoid unexpected negative impact on production environment. </p> <p>For PFS operations, I felt it was important to make all instrument files correct, so fixed all the files in /software/ and /data/:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> root@shell-ics:/home/pfs# find /data \( -uid 1000 -o -gid 1000 \) -ls root@shell-ics:/home/pfs# find /software \( -uid 1000 -o -gid 1000 \) -ls root@shell-ics:/home/pfs# find /home/pfs \( -uid 1000 -o -gid 1000 \) -ls root@shell-ics:/home/pfs# </pre> </div></div> <p>And all the software was restarted after the changes.</p> <p>What other files are you worried about?</p> <p>Sorry for delay. I agree that it is important to have consistent owner:group on files.</p> <p>Not major, but /virt/pki for example. Also, I would prefer to have guest VMs shutdown before we touch UID:GID on VM hosts...</p> <p>Would you mind if we have 1 day downtime on 10/5, 10/9 or later?</p> <p>Hi </p> <p>I have changed the UID and GID of "pfs" account on mcs machine.  </p> <p> </p> <p>pfs@mcs:~$ id<br/> uid=2085(pfs) gid=2085(pfs) groups=2085(pfs),0(root),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),30(dip),46(plugdev),113(lpadmin),128(sambashare)</p> <p> </p> <p>Sorry <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=kyono" class="user-hover" rel="kyono">kyono</a>, I somehow missed your question. Since we have the MCS testing to do, can I ask that you wait until the 10th? If that is making you nervous, the 9th?</p> <p>Hi Craig(<a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a>)<br/> No rush from our perspective. I even think, for next run, we should be ok with current configuration.<br/> Sorry, but I plan to join PFS meeting on 10th but will be off on that day. How about 11th?</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=kyono" class="user-hover" rel="kyono">kyono</a> The situation is currently a bit confusing: the file and user ids are correct on the vm clients, but the group ids are not respected for NFS writes:</p> <p>Good for user pfs, in pfs group:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>pfs@shell-ics:/software$ id -a uid=2085(pfs) gid=2085(pfs) groups=2085(pfs),20(dialout),27(sudo) pfs@shell-ics:/software$ ls -ldn /software drwxrwsr-x 6 2085 2085 89 Oct 8 09:09 /software pfs@shell-ics:/software$ touch x pfs@shell-ics:/software$ rm x </pre> </div></div> <p>Not good for user cloomis, in pfs group:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>cloomis@shell-ics:/software$ id -a uid=10929(cloomis) gid=2046(coll) groups=2046(coll),27(sudo),992(vpnusers),2044(hsc),2085(pfs) cloomis@shell-ics:/software$ ls -ldn /software drwxrwsr-x 6 2085 2085 89 Oct 8 09:09 /software cloomis@shell-ics:/software$ touch x touch: cannot touch 'x': Permission denied </pre> </div></div> <p>I added cloomis to the local (non-LDAP) /etc/group pfs, but that did not help. </p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a><br/> Does 11th work?</p> <p>Sure.</p> <p>OK. We will work on this 11th. As I mentioned before in this thread, PFS ISC@subaru summit will be down on 11th. Hope we are on the same page. If there is any miscommunication, let us know.</p> <p>FWIW, the problem I reported about the pfs group not being respected for non-pfs accounts has been fixed by the reboot.</p> <p>With today's work on the servers, we can now declare this zombie ticket properly and peacefully closed.</p> Relates INSTRM-501 INSTRM-22 Development Rank 0|ii04fz: