need to be checked, but "passwd/user-gid" could work on preseed.

At the very least, the LDAP and local pfs groups should have different names unless they can have the same GID.

The specific problem is temporary and there is a workaround. Development is done by individual users with pfs gid=2085, writing into /software. The pfs user (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.

Until INSTRM=322 is done, actor write log files into $ICS_MHS_LOGS_ROOT, which is currently, ugh, /software/mhs/logs. I can change that to /data/logs and make sure that the /data pfs GID is 1000.

OK, I linked /software/mhs/logs to /data/logs, and made all of /data gid=1000. As long as only user pfs runs actors and other MHS programs, this should work.

We still need to unify the LDAP and local IDs.

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 Yoshida, Hiroshige or shimono check?). But if that is not possible would a PAM solution work? Something like:

• rename the LDAP pfs group to pfsldap or something
• add a pam_group line which adds the pfs gid==1000 group to any member of the pfsldap group?

Subaru CDM says 1000-1999 are reserved.

it seems we may be better to configure as:

• 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)
• just load ldap, which has pfs (gid:2085), but does not have pfs user

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...)?

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.

There is a bit of a mess at Subaru right now. The pfs accounts have pfs gid 1000, but the other accounts have gid 2085. Software was installed by users (me, mostly), so /software is almost entirely gid=2085; the exception is /software/devel/pfs, which is where ics_mcsActor is currently running from. But /data (notably /data/mcs/ and /data/logs/) is all pfs gid=1000. You can use ls -ln to determine what hides under the lying name.

I suggest that after this engineering run we fix up all pfs accounts (notably on mcs and shell-ics) to gid 2085, and chgrp -R 2085 /data, etc. Until then be extra aware of which account you are working as.

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.
https://salsa.debian.org/installer-team/user-setup/blob/master/user-setup-apply#L123

so, it seems we need to:

• change 'name' between default local account and ldap group. (if so, uid/gid mismatch will not be an issue)
• use the same 'name' and 'id' among default local account, default local group, and ldap group.

so, this cannot be done at installation (even if we reinstall things), we may run groupmod carefully (like, with checking 'find / -nogroup' or something).

Note also that since there is not LDAP pfs user (since there cannot be a uid=1000 LDAP user), there is no shared /home/pfs: those are different on all the machines. This makes life more difficult.

I am inclined to ask for pfs uid=2085 on the Subaru LDAP (Yoshida, Hiroshige), then change all instances of pfs:pfs to 2085:2085 on all machines. Now: before the 2018-09 engineering run. As shimono points out we still have to deal with ansible, either nicely or by force.

For pfs user home, as we chatted on slack, we will keep how it works now.
(pfs user is meant for admin and needs to be available anytime.)

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(cloomis) confirm that it meets your requirements and fix issues we have now?

(Kiaina Schubert) (Yoshida, Hiroshige) (shimono)

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 pfs 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 pfs user as well.

To get rid of all traces of the 1000s, besides adding pads uid=2085 in the LDAP, all the /etc/passwd and /etc/group files need to be edited (removing 1000s, adding 2085 only if you do not trust your LDAP). Then find $everywhere -user 1000 -o -group 1000 and decide what to do – being careful because chown/chgrp can clear g+s, I believe.

And the ansible/pre-ansible Linux provisioning scripts need to be changed.

Task-wise, for the most of part, I believe we are on the same page.

>Then find $everywhere -user 1000 -o -group 1000 and decide what to do – being careful because chown/chgrp can clear g+s, I believe.

>
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.
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... 
Can you(cloomis) let us(Kiaina Schubert, Yoshida, Hiroshige, shimono) know how you think?

>And the ansible/pre-ansible Linux provisioning scripts need to be changed.

>
Yes, but not expecting this before Sep run, right? 

I’ll deal with the VMs. Can you deal with ansible, etc after the Sept run? I’d start by looking at shimono’s comments.

Thank you. If you do not mind, can we confirm the VMs you are going to deal with?

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.

So, I am assuming,

• gw-ics
• dnsmasq-ics
• logger-ics
• Three vm hosts
• Four vm guests for monitoring

will be handled by Subaru, and 

• shell-ics
• db-ics
• gen2-ics
• mhs-ics
• alert-ics

will be handled by you(cloomis). Does this sound right?

Yes, finally started working on this. A couple of points.

• In ldap, gid 1000 is "gurus", so I imagine you are eager for me to change everything.
• can you change the login shell for pfs to bash?

>In ldap, gid 1000 is "gurus", so I imagine you are eager for me to change everything.
>
Yes, on these VMs.

• shell-ics
• db-ics
• gen2-ics
• mhs-ics
• alert-ics

I thought what we agreed was

• CDM make pfs user id 2085 on our LDAP
• update pfs user on PFS ICS VMs.
• We do not touch gid/uid 1000 on LDAP.  

Could you reconfirm what we agreed?

>can you change the login shell for pfs to bash?
>
Yes, will do it. This requires interaction with Fujitsu. As soon as this gets done, i will let you know.

I confirm that we agreed on all those.

And that I am responsible for fixing the system (/etc/

and user files on the shell/db/gen2/mhs/alert VMs. There will be no files owned by uid 1000 or gid 1000.

pfs user's shell is changed to /bin/bash.

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 (cloomis) put it back?

[Ref]
pfs@db-ics:~$ grep pfs /etc/passwd
pfs@db-ics:~$ grep sudo /etc/group
sudo:x:27:cloomis
pfs@shell-ics:~$ grep pfs /etc/passwd
pfs@shell-ics:~$ grep sudo /etc/group
sudo:x:27:pfs,cloomis,rhl,hassans

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. 

From admin perspective, it may cause big mess though..
[i.e]

• LDAP client config messed up. Then, no login until we use run level 1 and fix it...
• Network interface config messed up. Then, no login until we use run level 1 and fix issue...
• etc...

Let us know if you have any comments and questions.

Kiaina Schubert, Yoshida, Hiroshige, naoyuki.tamura, shimono

I will put those back in. I had misunderstood what you wanted for the `pfs` user, sorry.

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.

I think this is done, except for extensions in INSTRM-501 and INSTRM-502.

Craig (cloomis),

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.

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.

I would prefer to do it after MCS run and with all VMs shutdown to avoid unexpected negative impact on production environment. 

For PFS operations, I felt it was important to make all instrument files correct, so fixed all the files in /software/ and /data/:

 
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# 

And all the software was restarted after the changes.

What other files are you worried about?

Sorry for delay. I agree that it is important to have consistent owner:group on files.

Not major, but /virt/pki for example. Also, I would prefer to have guest VMs shutdown before we touch UID:GID on VM hosts...

Would you mind if we have 1 day downtime on 10/5, 10/9 or later?

Hi 

I have changed the UID and GID of "pfs" account on mcs machine.  

pfs@mcs:~$ id
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)

Sorry kyono, 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?

Hi Craig(cloomis)
No rush from our perspective. I even think, for next run, we should be ok with current configuration.
Sorry, but I plan to join PFS meeting on 10th but will be off on that day. How about 11th?

kyono 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:

Good for user pfs, in pfs group:

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

Not good for user cloomis, in pfs group:

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

I added cloomis to the local (non-LDAP) /etc/group pfs, but that did not help.

cloomis
Does 11th work?

Sure.

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.

FWIW, the problem I reported about the pfs group not being respected for non-pfs accounts has been fixed by the reboot.

With today's work on the servers, we can now declare this zombie ticket properly and peacefully closed.