Is setting a specific GroupID in PKGBUILD a common practice?

Linoman · 2016-03-16 09:54:37

I was attempting to install the terraria-server but couldn't because another service in the server already uses the GID 197

Here's the PKGBUILD in question

Is manually setting the GID a common practice?
Is this ok?
Can I just set it to whatever number as long as it is consistent or will I have trouble updating it in the future?
Should I rename the GID of the other service?
Should I flag it this AUR pkg?

I'm not sure how to proceed.

Lone_Wolf · 2016-03-16 10:21:19

No clue about harcoding UID/GID in PKGBUILD, but 197 is a bad choice for an aur package.

Check https://wiki.archlinux.org/index.php/De … D_Database , 197 is used by rabbitmq from [community] .

I suggest to add a comment about this on terrarria-server aur page It should be named teraria-server-bin imo as it installs pre-compiled stuff ) .

Linoman · 2016-03-16 10:55:18

Lone_Wolf wrote:

No clue about harcoding UID/GID in PKGBUILD, but 197 is a bad choice for an aur package.
Check https://wiki.archlinux.org/index.php/De … D_Database , 197 is used by rabbitmq from [community] .
I suggest to add a comment about this on terrarria-server aur page It should be named teraria-server-bin imo as it installs pre-compiled stuff ) .

Yes, RabbitMQ is the service in question. I'll guess I'll have to flag it.

Trilby · 2016-03-16 11:53:37

Why do you want to hardcode a GID anyways? Groupadd will create a new gid that doesn't conflict with anything currently on the system. You can't create this group until the install script, but you could chown the relevant files to that group in the install script instead of trying to hardcode a numerical group value.

EDIT: see the following discussion on why my suggestion is probably not the right approach.

Awebb · 2016-03-16 13:35:36

The install script has a bug, I have posted a comment on the package site.

Trilby wrote:

Why do you want to hardcode a GID anyways? Groupadd will create a new gid that doesn't conflict with anything currently on the system. You can't create this group until the install script, but you could chown the relevant files to that group in the install script instead of trying to hardcode a numerical group value.

In addition, please have a look at the groupadd manpage and /etc/login.defs. There are GID_MIN/MAX and SYS_GID_MIN/MAX variables:

#
# Min/max values for automatic gid selection in groupadd
#
GID_MIN                  1000
GID_MAX                 60000
# System accounts
SYS_GID_MIN               500
SYS_GID_MAX               999

Scimmia · 2016-03-16 14:43:31

If you want packaged files or dirs to be owned by that group, then yes, hardcoding the GID is normal and necessary.

Awebb · 2016-03-16 22:02:12

Scimmia wrote:

If you want packaged files or dirs to be owned by that group, then yes, hardcoding the GID is normal and necessary.

Would it be okay to add the group ID to this list, then? https://wiki.archlinux.org/index.php/De … D_Database

Trilby · 2016-03-16 22:12:35

Scimmia wrote:

If you want packaged files or dirs to be owned by that group, then yes, hardcoding the GID is normal and necessary.

Scimmia, this makes sense to me for established/commonly used groups like those in the wiki link above. But in this case this is a group specifically for this software. It seems to be there is no reason that it needs to have a specific number for the GID: there is no reason the group needs to have the same numerical value on different systems. Based on this it would be safer and easier to create the group in the install script and chown the relevant files.

Is there something I'm missing that would favor using a specific number for this group and set this in the PKGBUILD?

Scimmia · 2016-03-16 23:06:31

Awebb, unfortunately, that page is really only for packages in the official repos. AFAIK, there's not a central database for packages in the AUR, and that can cause problems like this.

Trilby, the main thing is that files and dirs should not be being chown'd in the post-install/upgrade scripts. Doing this can screw up custom configurations, which is why pacman doesn't automatically change ownership when the package differs from the filesystem. If a file or dir should be owned by a specific user or group, it should be set in the package function, which requires a static UID/GID.

Trilby · 2016-03-16 23:45:08

Thanks, that makes sense.

Arch Linux

#1 2016-03-16 09:54:37

Is setting a specific GroupID in PKGBUILD a common practice?

#2 2016-03-16 10:21:19

Re: Is setting a specific GroupID in PKGBUILD a common practice?

#3 2016-03-16 10:55:18

Re: Is setting a specific GroupID in PKGBUILD a common practice?

#4 2016-03-16 11:53:37

Re: Is setting a specific GroupID in PKGBUILD a common practice?

#5 2016-03-16 13:35:36

Re: Is setting a specific GroupID in PKGBUILD a common practice?

#6 2016-03-16 14:43:31

Re: Is setting a specific GroupID in PKGBUILD a common practice?

#7 2016-03-16 22:02:12

Re: Is setting a specific GroupID in PKGBUILD a common practice?

#8 2016-03-16 22:12:35

Re: Is setting a specific GroupID in PKGBUILD a common practice?

#9 2016-03-16 23:06:31

Re: Is setting a specific GroupID in PKGBUILD a common practice?

#10 2016-03-16 23:45:08

Re: Is setting a specific GroupID in PKGBUILD a common practice?

Board footer