BitCurator install fails when group differs from username

[Geoff Short]

I'm trying to install BitCurator 4.3.0 on Ubuntu 22.04 using the quickstart method, my user is uid=2638(csrv667) gid=2000(csrv)

The install fails with several group errors, for instance:
`file_|-/home/csrv667/.local_|-/home/csrv667/.local_|-recurse:
__id__: /home/csrv667/.local
__run_num__: 226
__sls__: bitcurator.env.dot-local
changes: {}
comment: Group csrv667 is not available
duration: 2.204
name: /home/csrv667/.local
result: false

It's not detecting my actual group, from the file definition:
/home/csrv667/.local:
file.recurse:
- source: salt://bitcurator/env/.local
- user: csrv667
- group: csrv667
- makedirs: True
- file_mode: keep

What's the best way to go about fixing these errors? This is going to make it impossible to install on our managed Linux PCs which uses enterprise authentication.

Thanks in advance,

Geoff Short
Team Leader - Apple, Print & Linux

Desktop, Print & Support Group - IT Services, University of York

Quantum House, Innovation Way, York YO10 5BR

Email disclaimer - see: https://www.york.ac.uk/docs/disclaimer/email.htm

[co...@digitalsleuth.ca]

Hi Geoff,

Can you take a look in the following directory and attach the saltstack.log file found there so I can find out what the issue is?

/var/cache/bitcurator/cli/v4.3.0/saltstack.log

Cheers!

Corey Forman

[co...@digitalsleuth.ca]

Hi again, Geoff,

Can you also tell me, are you setting it up and choosing a new user, or are you setting it up in the context of the existing (logged in) user?

[Kam Woods]

This appears to be the result of group policy that does not match the default in Ubuntu. Normally if a local user "csrv667" is created, the associated group will also be "csrv667", and several states in our install stack assume this (via "- group: {{user}}"). But your enterprise policy has the group as "csrv", as you noted.

Interestingly, this has never come up before on list. One fix I can think of would be to update the installer to take another flag, so that if you needed to specify both a user and a group you could do so (e.g. "sudo bitcurator install --user csrv667 --group csrv"), and update the states as needed. I'm not sure I can think of another option since we can't know specifically how the policy is being enforced ahead of time.

As a sanity check, I went ahead and tested all the "regular local user, non-policy-enforced" cases (install with local user csrv667 via "sudo bitcurator install" and "sudo bitcurator install --user csrv667, and install with local user bcadmin creating a new user via "sudo bitcurator install --user csrv"). Those all work fine.

Kam

--
You received this message because you are subscribed to the Google Groups "BitCurator Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcurator-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/55d38d6d-e5aa-4f6b-b3bf-36f10e6aa176n%40googlegroups.com.

[Kam Woods]

Ah...disregard that. I'll follow up with a simpler proposed fix in an issue on the repo.

Kam

[Corey Forman]

Hey Kam,

Actually I think the best and easiest way to approach this is to modify the states to have them detect the appropriate group for the chosen user, which can be done with a short command. I'm working on the changes now, and I'll upload a PR tonight with the proposal!

---

From: bitcurat...@googlegroups.com <bitcurat...@googlegroups.com> on behalf of Kam Woods <kamw...@gmail.com>
Sent: Tuesday, November 1, 2022 5:20:46 PM
To: bitcurat...@googlegroups.com <bitcurat...@googlegroups.com>
Subject: Re: BitCurator install fails when group differs from username

 

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/CAAOjFxBWE5fnjgFT6Ot7HDkzn7mqj%3D6OdM4vSNFaLAsO69fEQg%40mail.gmail.com.

[Kam Woods]

Yeah, sorry, that’s what I realized and put in the gh issue :)

Kam

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/YQXPR01MB464323CDF5D435046C531488DD369%40YQXPR01MB4643.CANPRD01.PROD.OUTLOOK.COM.

[Geoff Short]

Hi there,

Firstly, thanks very much for jumping on this so quickly.

To confirm - yes, I'm installing for the existing logged in user. It is a fresh install of Ubuntu, the user has been manually added with the non-default group id.

For context (and why it's not come up before) - previously we would have used a standalone Ubuntu install for this sort of software. Our University is tightening up it's security polices and it will be required to use IT managed machines and user accounts to handle confidential material.

Cheers, Geoff

[co...@digitalsleuth.ca]

Hi Geoff, no problem!

Since you're manually creating the users first, with the non-standard group ID, then we have a solution to resolve this, which I'll push out with Kam shortly.

What will happen now is the state files will check the group ID of the existing user first, and then use that as the group ID for any permissions changes going forward.

We'll let you know once we release the updates!

[Kam Woods]

The update has now been released as BitCurator 4.4.0. Still working on building an OVA and docker image, but you should find that the installer now works for this case.

Kam

[Geoff Short]

Hi Kam,

Thank you very much - I've tested the 4.4.0 install on our managed Ubuntu PC and it now installs cleanly for the logged-in user.  

Yours,  Geoff