UNIX for Advanced & Expert Users

All,

I am looking for some guidance on how to handle permissions/access for an application build/deployment.

We need to allow for software deployments via Visual Studio Team Services and a build server running on Windows, deploying to RHEL 7 servers. We would like to use a service account, say 'srv_user', to handle the process. The need will be to:

Thoughts/Concerns:
Hopefully I haven't confused the need too much, any suggestions are appreciated.

Thanks in advance,

HB

Here are some general considerations/suggestions. To be more specific is too much dependant on the specific setting in your shop which is hard to appreciate from afar.

First, identify all the necessary roles and what they need to be allowed. You have already started that but you need that in more detail. Do not only define one role ("srv_user") but also the other roles necessary: i.e. "tester", "admin", ...

Only then sort through these specifications and see where they are different. i.e.:

Basic role "user": right1, right2, right3
Role "tester": like "user", but also right4, right5
Role "srv_user": like "tester" plus right6, right7, right8
etc..

This will give you a basic layout for a group hierarchy and which right should go to which group.

A few caveats: it is quite modern to use "ACLs" instead of classic UNIX privileges. This is a great way of getting yourself into deep kimchi beyond all means of maintenance. Experience shows that you end up (usually more sooner than later) with a heap of rights without any structure and no one knows or understands what is going on. Avoid that at all cost, even if it might appeal to you at first. In the long run it tends to be more a problem than a solution. A good (long-term!) solution is not one that does what you want but one that is also easy to understand and painless to maintain.

Have a look at "sudo", but do NOT overuse it! It is often possible to make up for planning deficiencies by overusage of a tool. In practically all cases this is a very bad idea in the long run. If an implementation looks cumbersome rather plan better than undergo the effort of the implementation.

I hope this helps.

bakunin

If in LAN,i would go with NFS and a cron script on the clients.

You have one windows master build server which has multiple NFS mounts from clients (destination servers) you wish to push changes to.
NFS is supported on newer windows and gid / uid can be mapped via registry to tomcat unix/linux user on clients.

A cron job runs on clients which detects if a new file is copied and does the work (stop tomcat, deploy code or whatever, start tomcat).

Be careful you do not catch files while being copied, rename a file after copy to NFS share on the build machine to file you want that client (destination server) to process.

Using NFSv4 you could probably have one port open between build machine and clients.
It would not involve any kind of access expect copying a file via network share, but some shell code running in cron should be produced.

Have you considering deploying application(s) thru web tomcat interface instead ?

Hope that helps
Regards
Peasant.

@bakunin and @Peasant thank you for your replies and suggestions. My apologies for not updating this thread sooner.

What I have ended up doing is:

Created an RSA key and put it in place on the destination server to allow for passwordless SSH connections from the build server. This gives me the ability to change the password for the 'srv_user' and not have a need to distribute the password.

Created a systemd service for Tomcat so that the processes are always run as 'app_user'. The 'srv_user' connects via ssh, uses sudo to stop Tomcat via the systemd service, does the get of new files, does a build, uses sudo to change permissions back to 'app_user' owner and group, and uses sudo to start Tomcat via systemd service.

So far it seems like the best way to handle the process. I'll be fine tuning it as we progress.

Any thoughts and/or suggestions are welcome.

Thanks,

HB