Hello, I have a bit of an unusual setup, as I am running GNU Guix in a VM on a Synology NAS. Unfortunately, their DSM software sucks quite badly, but I am currently stuck with this hardware as I don't have the budget to replace it. But I don't want to make any long-term commitment to their software either. One of the awesome features of GNU Guix is that it can nicely and easily be deployed elsewhere. However, for this to work, I need to be able to extract my data easily, so storing anything inside that VM that's not on GitLab isn't an option. I have decided to NFS-mount an encrypted shared folder from the NAS and store all data there.
This is working perfectly fine so far, but there is a tiny little problem with PostgreSQL: The 'postgresql-service-type' contains an 'account-service-type' extension to create the 'postgres' database user - which is what you'd normally want to do. But since I'd like to store all the actual data on that NFS share, the UID and GID of the 'postgres' user needs to match that of the server. The UID and GID values on the server aren't going to change for as long as I'm using that hardware, but I might want to deploy GNU Guix to a second machine to have a test server and have it reliably boot and setup. I'm currently using a temporary work-around by commenting out the 'postgresql-activation' in gnu/services/database.scm and creating the account via (operating-system (users ...)). This works, but is ugly, and I'd rather upstream this than depending on a local fork. This morning, I decided to submit a patch, but then realized that there are two ways of doing this, and I'd like to get your feedback about which one you'd prefer. Or maybe there's a better solution for this? - We could add (create-account? #f) to <postgresql-configuration>. - We could add (uid #f) and (gid #f) - possibly in addition to (create-account? #f) there. There is already 'data-directory' and 'log-directory', so I think it would make sense to add an option to specify a custom UID / GID for the service account. I've looked at other services and there doesn't seem to be a consistent way of doing such thing; most services also won't need such option. If you like either of these two approaches - or have a better idea - I will gladly submit a patch for it. Looking forward to hearing back from you, Martin
