Users and collective work
If you are following these docs as a guide we are about to begin setting up a space for collective work. When setting up a machine that is going to be accessed and potentially also maintained by several people we should carefully consider how best to set up the system. This is a question of labour (who is doing what), governance (to what degree different people can have access), but also transparency and accountability (who was online when something happened).
Therefore, at some point in developing the collaborative environment, we should discuss and choose a user and access structure. Whatever structure is decided upon, we should decide how to communicate between sysadmins, how to keep records and how to handover work etc.
As we will come to see in more detail in 01.3 SSH when we enter a machine via ssh, we specify that we are entering into a username’s account on that machine. However, there are also moments when you will be acting as the root user sudo, or working on a multiplexer. This means that in some instances you will be acting on behalf of others. For this reason it’s important to establish consistent protocols for co-working. This might include how to assign roles, log changes, share information and keep documentation.
During a working session we noted that there can be fine line between transparency and surveillance. That being said, we also understand that when maintaining a collaborative space, we need to know how we can approach and support each others mistakes when things go wrong (which they will), and document them in order to learn from them. This is another reason to take the time to establish how to work comfortably as a group early in the process.
[!note] During our first working session (see servpub website) Luke (Varia) and Mara (Systerserver) both shared examples from their own experience and collective work. Both collectives made different user accounts for each person who needed access but not everyone needed sudo access. When accessing Jean, a server run by systerserver, we made users for everyone who needed access and we made everyone a sudo user.`
Reference for how to create users and make them sudo can be found here 01.2 Creating Users
Names
During the process of setting up your collaborative environment, we will need to give certain elements names. For example, we will come to refer to a username on the server (Servpub01) and the server’s hostname (pubdoc). A hostname is a unique, human-readable name that identifies the server on a network.
When creating systems you should consider what you would like your naming conventions for users and hostnames. The conventions should be legible and easy to remember and to discern from each-other. You might also want to make them significant to you and your project.
Going forward, we will also have to name: - The physical server machine, and its other future nodes - One public user - for use during collaborative workshops for instance (optional) - Separate user account (named after members) - The domain (which will be publicly accessible when hosting things online)