bryan/hartman-server
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Beta

Browse Source
This commit is contained in:
Bryan Roessler
2021-10-22 16:38:48 -04:00
parent 7a797f30da
commit 0b6e092c20
4 changed files with 116 additions and 482 deletions
Download Patch File Download Diff File Expand all files Collapse all files

154
README.html
View File

@@ -1195,33 +1195,22 @@ github.com style (c) Vasily Polovnyov <vast@whiteants.net>
<script src="https://cdn.jsdelivr.net/npm/katex-copytex@latest/dist/katex-copytex.min.js"></script>
</head>
<body class="vscode-body vscode-light">
<body class="vscode-body">
<h1 id="hartman-lab-server-manual-">Hartman Lab Server Manual <!-- omit in toc --></h1>
<ul>
<li>Bryan C. Roessler</li>
<li>Last updated: 2021-10-22</li>
</ul>
<p><img src="file:////home/bryan/develop/scripts/hartmanlab/manual-images/anyconnect.png" alt="UAB AnyConnect VPN"></p>
<h2 id="important-information">Important information</h2>
<p>At some point UAB may restrict <code>ssh</code> access to the Hartman Lab Server, which will require users to first connect to the UAB VPN using the <a href="https://www.uab.edu/vpn/">UAB AnyConnect VPN</a>. Once the VPN connection is established, follow the rest of the manual to connect to the server.</p>
<p>For users that do not have UAB VPN credentials, a whitelist exception for the user's IP address will need to be added to the UAB firewall. Requests to UAB IT can be made <a href="https://uabprod.service-now.com/service_portal?id=sc_cat_item&amp;sys_id=daf70746374ce3c0daa253b543990e7f">here</a> using your UAB credentials, and should resemble the following:</p>
<pre><code class="language-(text)"><code><div>Type: Permit
Application Name: ssh
Firewall: UAB Internet Border
Source IP Addresses: User address(es)
Destination IP address: 138.26.17.151
TCP Port: 22
UDP Port: N/A
Other Protocols: N/A
Reason: Outside collaboration/(Other reason)
</div></code></code></pre>
<p>© 2021 Bryan C. Roessler</p>
<p>Last updated: 2021-10-22</p>
<h2 id="table-of-contents-">Table of Contents <!-- omit in toc --></h2>
<ul>
<li><a href="#important-information">Important information</a></li>
<li><a href="#for-users">For users</a>
<ul>
<li><a href="#first-time-login">First time login</a></li>
<li><a href="#sshsftp-file-server">SSH/SFTP file server</a></li>
<li><a href="#file-server">File server</a>
<ul>
<li><a href="#sshsftp">SSH/SFTP</a></li>
<li><a href="#samba-file-shares">Samba file shares</a></li>
</ul>
</li>
<li><a href="#x2go-remote-desktop">X2Go remote desktop</a>
<ul>
<li><a href="#session-tab">Session tab</a></li>
@@ -1239,7 +1228,6 @@ Reason: Outside collaboration/(Other reason)
</li>
<li><a href="#windows-10-virtual-machines">Windows 10 Virtual Machines</a></li>
<li><a href="#robot-computer-access">Robot computer access</a></li>
<li><a href="#samba-file-server">Samba File Server</a></li>
<li><a href="#webcam-robot-monitoring">Webcam robot monitoring</a></li>
<li><a href="#rstudio-server">RStudio Server</a></li>
<li><a href="#recommendations">Recommendations</a>
@@ -1259,7 +1247,6 @@ Reason: Outside collaboration/(Other reason)
<li><a href="#unban-a-user">Unban a user</a></li>
<li><a href="#fix-or-repair-user-file-permissions">Fix or repair user file permissions</a></li>
<li><a href="#services">Services</a></li>
<li><a href="#adding-a-drive">Adding a drive</a></li>
<li><a href="#virtual-machines">Virtual Machines</a>
<ul>
<li><a href="#allow-access-to-the-samba-share-within-the-windows-vm-windows-bug-workaround">Allow access to the samba share within the Windows VM (Windows bug workaround)</a></li>
@@ -1269,12 +1256,30 @@ Reason: Outside collaboration/(Other reason)
</li>
<li><a href="#updating-all-software">Updating all software</a></li>
<li><a href="#scheduling-a-restart">Scheduling a restart</a></li>
<li><a href="#adding-a-drive">Adding a drive</a></li>
<li><a href="#logging">Logging</a></li>
</ul>
</li>
<li><a href="#resources">Resources</a></li>
<li><a href="#contact">Contact</a></li>
</ul>
<h2 id="important-information">Important information</h2>
<p>If UAB restricts direct <code>ssh</code> access to the Hartman Lab Server, users will need to first connect to the UAB VPN using the <a href="https://www.uab.edu/vpn/">UAB AnyConnect VPN</a>. Once the VPN connection is established, follow the rest of the manual to connect to the server.</p>
<p>For users that do not have UAB VPN credentials, a whitelist exception for the user's IP address will need to be added to the UAB firewall. Requests to UAB IT can be made <a href="https://uabprod.service-now.com/service_portal?id=sc_cat_item&amp;sys_id=daf70746374ce3c0daa253b543990e7f">here</a> using your UAB credentials, and should resemble the following:</p>
<pre><code class="language-(text)"><code><div>Type: Permit
Application Name: ssh
Firewall: UAB Internet Border
Source IP Addresses: User address(es)
Destination IP address: 138.26.17.151
TCP Port: 22
UDP Port: N/A
Other Protocols: N/A
Reason: Outside collaboration/(Other reason)
</div></code></code></pre>
<ul>
<li>Network Manager UAB VPN settings
<img src="manual-images/anyconnect.png" alt="UAB AnyConnect VPN"></li>
</ul>
<h2 id="for-users">For users</h2>
<h3 id="first-time-login">First time login</h3>
<ol>
@@ -1286,11 +1291,37 @@ Reason: Outside collaboration/(Other reason)
<li>Re-login: <code>ssh blazerid@hartmanlab.genetics.uab.edu</code> using the new password</li>
<li><em>Optional:</em> Change Samba password (default password is your username): <code>smbpasswd</code></li>
</ol>
<h3 id="sshsftp-file-server">SSH/SFTP file server</h3>
<h3 id="file-server">File server</h3>
<h4 id="sshsftp">SSH/SFTP</h4>
<p>Files can be transferred to/from the server using <code>sftp</code>.</p>
<p>Users can access the server directly through a terminal (text-based) ssh client (<code>ssh</code> in OSX/Linux, or <a href="http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html"><code>PuTTY</code></a> in Windows) or via a GUI SFTP program such as <a href="https://filezilla-project.org/download.php?type=client">Filezilla</a> or <a href="https://winscp.net/eng/index.php">WinSCP</a>. Linux users can access and mount the SFTP share directly within most file managers (Fig. 2) or by using <a href="https://www.digitalocean.com/community/tutorials/how-to-use-sshfs-to-mount-remote-file-systems-over-ssh"><code>sshfs</code></a>.</p>
<p>Users can access the server directly through a terminal (text-based) ssh client (<code>ssh</code> in OSX/Linux, or <a href="http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html"><code>PuTTY</code></a> in Windows) or via a GUI SFTP program such as <a href="https://filezilla-project.org/download.php?type=client">Filezilla</a> or <a href="https://winscp.net/eng/index.php">WinSCP</a>. Linux users can access and mount the SFTP share directly within most file managers or by using <a href="https://www.digitalocean.com/community/tutorials/how-to-use-sshfs-to-mount-remote-file-systems-over-ssh"><code>sshfs</code></a>.</p>
<ul>
<li>
<p>Using <code>caja</code> to access sftp shares:
<img src="manual-images/sftp-native-linux.png" alt="Caja SFTP Example"></p>
</li>
<li>
<p>Using <a href="https://filezilla-project.org/download.php?type=client">Filezilla</a> to access sftp shares:
<img src="manual-images/filezilla.png" alt="Filezilla SFTP Example"></p>
</li>
</ul>
<h4 id="samba-file-shares">Samba file shares</h4>
<p>Samba file shares can be mounted cross-platform as if the data existed locally. The server provides two shares:</p>
<ol>
<li>The shared data array (<code>/mnt/data</code>): <code>\\username\data</code></li>
<li>The user's home directory (<code>$HOME</code>): <code>\\username\username</code></li>
</ol>
<p>The default Samba credentials are the same as your server username and password. Users can change their Samba password using <code>smbpasswd</code>.</p>
<ul>
<li>Mounting samba shares on Windows:
<ol>
<li><img src="manual-images/samba-windows1.png" alt="Samba shares on Windows"></li>
<li><img src="manual-images/samba-windows2.png" alt="Samba shares on Windows"></li>
</ol>
</li>
</ul>
<h3 id="x2go-remote-desktop">X2Go remote desktop</h3>
<p>X2Go provides a remote virtual desktop over <code>vnc</code> secured using <code>ssh</code>. X2Go clients are provided for Windows, OSX, and Linux systems on the <a href="http://wiki.x2go.org/doku.php">X2Go website</a> or from your package manager (<code>x2goclient</code>).</p>
<p>X2Go provides a remote virtual desktop over <code>vnc</code> secured with <code>ssh</code>. X2Go clients are provided for Windows, OSX, and Linux systems on the <a href="http://wiki.x2go.org/doku.php">X2Go website</a> or from your package manager (<code>x2goclient</code>).</p>
<p>X2Go sessions can be paused or closed from the X2Go client window. Multiple sessions can be saved in the client, making it easy to select alternate quality settings based on location/bandwidth or to provide multiple user login sessions on the same machine.</p>
<p><strong>Note:</strong> Some programs do not continue to run at full speed when an X2Go session is paused. In these cases, the program should be run via remote SSH (ideally in a <a href="https://en.wikipedia.org/wiki/Tmux"><code>tmux</code></a> or <a href="https://www.gnu.org/software/screen/"><code>screen</code></a> session).</p>
<h4 id="session-tab">Session tab</h4>
@@ -1301,6 +1332,7 @@ Reason: Outside collaboration/(Other reason)
<li>SSH port: 22</li>
<li>Session type: <strong>MATE</strong> (Not all session types are allowed and MATE should provide the best experience with X2Go)</li>
</ul>
<p><img src="manual-images/x2go-session.png" alt="X2Go session preferences"></p>
<h4 id="connection-tab">Connection tab</h4>
<ul>
<li>Set the connection speed to <em>LAN</em> when connecting from within the UAB network. When connecting from off-campus these quality values can be adjusted based on bandwidth and latency.</li>
@@ -1316,7 +1348,8 @@ Reason: Outside collaboration/(Other reason)
<h4 id="shared-folders">Shared folders</h4>
<ul>
<li>Select folders on the client to be shared with the server during a session. Browse to the chosen folder, add it to the share, and select <em>automount</em>.</li>
<li>These folders will then appear on the server under <code>/media/disk/&lt;share_name&gt;</code> (Fig. 4).</li>
<li>These folders will then appear on the server under <code>/media/disk/&lt;share_name&gt;</code>.
<img src="manual-images/x2go-sharedfolders.png" alt="X2Go shared folders"></li>
</ul>
<h3 id="native-x-forwarding">Native X forwarding</h3>
<p>It is possible to launch graphical server programs directly on a client.</p>
@@ -1331,19 +1364,22 @@ Reason: Outside collaboration/(Other reason)
</ul>
<h3 id="windows-10-virtual-machines">Windows 10 Virtual Machines</h3>
<ul>
<li>Access from X2Go:
<li>
<p>Access from within X2Go:</p>
<ul>
<li><em>Applications&gt;Internet&gt;Remote Viewer</em>: <a href="spice://localhost:5900"><code>spice://localhost:5900</code></a></li>
<li><em>Applications&gt;Internet&gt;Remote Viewer</em>: <a href="spice://localhost:5900"><code>spice://localhost:5900</code></a>
<img src="manual-images/virt-viewer.png" alt="Samba shares on Windows"></li>
</ul>
</li>
<li>External access:
<ul>
<li><code>virt-viewer</code> is available for all platforms (<a href="https://virt-manager.org/download/">Windows</a>, <a href="https://www.spice-space.org/page/OSX_Client">OSX</a>)</li>
</ul>
<li>
<p>Direct external access:
<a href="/usr/local/bin/virt-viewer"><code>virt-viewer</code></a> is available across all platforms (<a href="https://virt-manager.org/download/">Windows</a>, <a href="https://www.spice-space.org/page/OSX_Client">OSX</a>).</p>
</li>
</ul>
<li>
<p>The SPICE password is: <strong><code>hartmanlab</code></strong></p>
<p>The virtualized Windows 10 instances require logging in with your UAB e-mail address and password.</p>
</li>
</ul>
<p>The virtualized Windows 10 instances require logging in with your UAB email address and password.</p>
<ul>
<li><strong>Note:</strong> Users should NOT log in with a pin when prompted, it will disable access to the Samba file shares (Windows bug). Users should always log in with a password.</li>
</ul>
@@ -1352,13 +1388,6 @@ Reason: Outside collaboration/(Other reason)
<ul>
<li>While logged into the server, launch <em>Applications&gt;Internet&gt;Remote Viewer&gt;Connection&gt;New</em>: <code>vnc://192.168.16.101:5900</code></li>
</ul>
<h3 id="samba-file-server">Samba File Server</h3>
<p>Samba file shares can be mounted on any client as if the data existed locally. The server provides two shares:</p>
<ol>
<li>The shared data array (<code>/mnt/data</code>): <code>\\username\data</code></li>
<li>The user's home directory (<code>$HOME</code>): <code>\\username\username</code></li>
</ol>
<p>The default Samba credentials are the same as your server username and password. Users can change their Samba password using <code>smbpasswd</code>.</p>
<h3 id="webcam-robot-monitoring">Webcam robot monitoring</h3>
<p>The robot webcam is viewable in a web page within an X2Go session at: <code>localhost:8888</code></p>
<h3 id="rstudio-server">RStudio Server</h3>
@@ -1440,32 +1469,25 @@ Reason: Outside collaboration/(Other reason)
<ul>
<li><code>script-files-permissions-set</code> <em><code>username</code></em> <em><code>password</code></em> <em><code>PATH[...]</code></em>
<ul>
<li>This script will walk you through fixing or setting the permissions on one or more <code>PATH</code>'s.</li>
<li>This script will walk you through fixing or setting the permissions on one or more <code>PATH</code>'s. If no PATH is provided the <code>$PWD</code> is used.</li>
</ul>
</li>
<li><code>script-files-permissions-reset</code>
<li><code>script-files-permissions-reset</code> <em><code>PATH[...]</code></em>
<ul>
<li>If things go really south, use this script as a method of last resort to reset permissions on the entire shared data array <code>/mnt/data</code> so they are writeable by the <code>smbgrp</code> group.</li>
<li>If no <em><code>PATH[...]</code></em> is provided it will reset the data array <code>/mnt/data</code>.</li>
<li>If things go really south, use this script as a method of last resort to reset permissions on a path by resetting the original permissions for the shared data.</li>
</ul>
</li>
</ul>
<h3 id="services">Services</h3>
<ul>
<li>Start: <em>sudo systemctl start smb.service</em></li>
<li>Stop: <em>sudo systemctl stop smb.service</em></li>
<li>Start at boot: <em>sudo systemctl enable smb.service</em></li>
<li>Do not start at boot: <em>sudo systemctl disable smb.service</em></li>
<li>Restart service: <em>sudo systemctl restart smb.service</em></li>
<li>Reload services: <em>sudo systemctl daemon-reload</em></li>
<li>Read service: <em>sudo systemctl cat smb.service</em></li>
</ul>
<h3 id="adding-a-drive">Adding a drive</h3>
<ul>
<li><s><code>sudo scripts-drive-add</code> <code>/dev/sdX</code></s> (Under construction)
<ul>
<li>To determine the correct drive, use <code>lsblk -f</code>.</li>
</ul>
</li>
<li>Start: <code>sudo systemctl start smb.service</code></li>
<li>Stop: <code>sudo systemctl stop smb.service</code></li>
<li>Start at boot: <code>sudo systemctl enable smb.service</code></li>
<li>Do not start at boot: <code>sudo systemctl disable smb.service</code></li>
<li>Restart service: <code>sudo systemctl restart smb.service</code></li>
<li>Reload services: <code>sudo systemctl daemon-reload</code></li>
<li>Read service: <code>sudo systemctl cat smb.service</code></li>
</ul>
<h3 id="virtual-machines">Virtual Machines</h3>
<ul>
@@ -1516,9 +1538,19 @@ slmgr -ato
</ul>
<h3 id="scheduling-a-restart">Scheduling a restart</h3>
<ul>
<li><s><code>sudo script-system-restart</code> <em><code>datetime</code></em></s> (Under construction)
<li><code>sudo script-system-scheduled-restart</code> <em><code>OnCalendar</code></em>
<ul>
<li>This will alert users via <code>notify-send</code> in X2Go and <code>wall</code> in ssh of the scheduled restart.</li>
<li>If a valid <code>OnCalendar</code> is not passed, assumes <code>*-*-* 01:30:00</code> (1:30 AM).</li>
<li>See <a href="https://www.freedesktop.org/software/systemd/man/systemd.time.html">Calendar Events</a> for proper time format.</li>
<li>This will alert users via <code>notify-send</code> in X2Go, <code>wall</code> in ssh, and add a reminder to the <code>motd</code> about the scheduled restart.</li>
</ul>
</li>
</ul>
<h3 id="adding-a-drive">Adding a drive</h3>
<ul>
<li><s><code>sudo scripts-drive-add</code> <code>/dev/sdX</code></s> (Under construction)
<ul>
<li>To determine the correct drive, use <code>lsblk -f</code>.</li>
</ul>
</li>
</ul>

41
README.md
View File

@@ -36,13 +36,13 @@ Last updated: 2021-10-22
- [Unban a user](#unban-a-user)
- [Fix or repair user file permissions](#fix-or-repair-user-file-permissions)
- [Services](#services)
- [Adding a drive](#adding-a-drive)
- [Virtual Machines](#virtual-machines)
- [Allow access to the samba share within the Windows VM (Windows bug workaround)](#allow-access-to-the-samba-share-within-the-windows-vm-windows-bug-workaround)
- [Make an existing Windows 10 account user an administrator](#make-an-existing-windows-10-account-user-an-administrator)
- [Creating more VM disk space](#creating-more-vm-disk-space)
- [Updating all software](#updating-all-software)
- [Scheduling a restart](#scheduling-a-restart)
- [Adding a drive](#adding-a-drive)
- [Logging](#logging)
- [Resources](#resources)
- [Contact](#contact)
@@ -162,13 +162,13 @@ It is possible to launch graphical server programs directly on a client.
- Access from within X2Go:
- *Applications&gt;Internet&gt;Remote Viewer*: [`spice://localhost:5900`](spice://localhost:5900)
- Direct external access:
- [`virt-viewer`](/usr/local/bin/virt-viewer) is available across all platforms ([Windows](https://virt-manager.org/download/), [OSX](https://www.spice-space.org/page/OSX_Client)):
![Samba shares on Windows](manual-images/virt-viewer.png)
- Direct external access:
[`virt-viewer`](/usr/local/bin/virt-viewer) is available across all platforms ([Windows](https://virt-manager.org/download/), [OSX](https://www.spice-space.org/page/OSX_Client)).
The SPICE password is: **`hartmanlab`**
- The SPICE password is: **`hartmanlab`**
The virtualized Windows 10 instances require logging in with your UAB e-mail address and password.
The virtualized Windows 10 instances require logging in with your UAB email address and password.
- **Note:** Users should NOT log in with a pin when prompted, it will disable access to the Samba file shares (Windows bug). Users should always log in with a password.
@@ -244,24 +244,20 @@ Once configured, the user will no longer need to enter their password to access
### Fix or repair user file permissions
- `script-files-permissions-set` *`username`* *`password`* *`PATH[...]`*
- This script will walk you through fixing or setting the permissions on one or more `PATH`'s.
- `script-files-permissions-reset`
- If things go really south, use this script as a method of last resort to reset permissions on the entire shared data array `/mnt/data` so they are writeable by the `smbgrp` group.
- This script will walk you through fixing or setting the permissions on one or more `PATH`'s. If no PATH is provided the `$PWD` is used.
- `script-files-permissions-reset` *`PATH[...]`*
- If no *`PATH[...]`* is provided it will reset the data array `/mnt/data`.
- If things go really south, use this script as a method of last resort to reset permissions on a path by resetting the original permissions for the shared data.
### Services
- Start: *sudo systemctl start smb.service*
- Stop: *sudo systemctl stop smb.service*
- Start at boot: *sudo systemctl enable smb.service*
- Do not start at boot: *sudo systemctl disable smb.service*
- Restart service: *sudo systemctl restart smb.service*
- Reload services: *sudo systemctl daemon-reload*
- Read service: *sudo systemctl cat smb.service*
### Adding a drive
- ~~`sudo scripts-drive-add` `/dev/sdX`~~ (Under construction)
- To determine the correct drive, use `lsblk -f`.
- Start: `sudo systemctl start smb.service`
- Stop: `sudo systemctl stop smb.service`
- Start at boot: `sudo systemctl enable smb.service`
- Do not start at boot: `sudo systemctl disable smb.service`
- Restart service: `sudo systemctl restart smb.service`
- Reload services: `sudo systemctl daemon-reload`
- Read service: `sudo systemctl cat smb.service`
### Virtual Machines
@@ -310,6 +306,11 @@ Once configured, the user will no longer need to enter their password to access
- See [Calendar Events](https://www.freedesktop.org/software/systemd/man/systemd.time.html) for proper time format.
- This will alert users via `notify-send` in X2Go, `wall` in ssh, and add a reminder to the `motd` about the scheduled restart.
### Adding a drive
- ~~`sudo scripts-drive-add` `/dev/sdX`~~ (Under construction)
- To determine the correct drive, use `lsblk -f`.
### Logging
- First point of reference for server problems: `sudo journalctl`

400
manual.texinfo
View File

@@ -1,400 +0,0 @@
\input texinfo
@setfilename manual
@settitle Hartman Lab Server Manual
@copying
Copyright @copyright{} 2021 Bryan C. Roessler
Last updated: @today{}
@end copying
@titlepage
@title Hartman Lab Server Manual
@author Bryan C. Roessler
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage
@contents
@node Top
@top Hartman Lab Server Manual - @today{}
@menu
* Updates:: Recent manual updates
* Index:: Complete index.
@c @detailmenu
@c --- The Detailed Node Listing ---
@c Overview of Texinfo
@c * Updates::
@c …
@c Beginning a Texinfo File
@c * First Section::
@c …
@c @end detailmenu
@end menu
@node Updates
At some point in the future UAB may restrict direct ssh access to the Hartman Lab Server. If this occurs you will first need to connect to the UAB intranet via the UAB AnyConnect VPN. Directions for connecting to the UAB VPN can be found here (Linux users, see Fig. A). Once the VPN connection is established you can follow the rest of the manual to connect to the server.
For users that do not have UAB VPN credentials, a whitelist exception will need to be added to the UAB firewall for the specific IP address that the user will be connecting from. The requests can be made here using your UAB credentials.
Type: Permit
Application Name: ssh
Firewall: UAB Internet Border
Source IP Addresses: Users address(es)
Destination IP address: 138.26.17.151
TCP Port: 22
UDP Port: N/A
Other Protocols: N/A
Reason: Outside collaboration/(Other reason)
This is the first chapter.
@cindex index entry, another
Here is a numbered list.
@node Introduction
@section Server Features
@enumerate
@item
SSH/SFTP file server
@item
This is the second item.
@end enumerate
1. SSH/SFTP file server
2. Linux X2Go remote desktop
3. Windows 10 SPICE QEMU/KVM remote desktop
4. Samba-compatible file server
5. Webcam robot monitoring
6. Robot computer remote access
First section of first chapter.
@node Second Section
@section Second Section
Second section of first chapter.
@node Index
@unnumbered Index
@printindex cp
@bye
Presently, the server offers the following remote features:
1. SSH/SFTP file server
2. Linux X2Go remote desktop
3. Windows 10 SPICE QEMU/KVM remote desktop
4. Samba-compatible file server
5. Webcam robot monitoring
6. Robot computer remote access
First time login
1. Login via ssh client (ssh or putty): ssh blazerid@hartmanlab.genetics.uab.edu
2. Default password is identical to blazerid
3. System will prompt you to create new password
4. System will log user out after successful password generation
5. Re-login: ssh blazerid@hartmanlab.genetics.uab.edu
6. Enter new password
7. Change smbpasswd: smbpasswd (default password is your blazerid)
SSH/SFTP file server
Files can be transferred between systems on the network using the “sftp” command. Use of sftp requires a valid userid and password on the server.
Users can access the server directly through a terminal (text-based) ssh client (ssh in OSX/Linux, or putty in Windows) or can alternatively use a GUI SFTP program such as Filezilla. Linux users can access and mount the SFTP share directly within most file managers (Fig. 2).
A standard user will have access to their $HOME directory as well as /media/data. $HOME resides on a fast (yet storage constrained) SSD while /media/data refers to a large 4TB drive that will be used for lab data and file sharing. Therefore it is recommended that users keep their large files within /media/data and only use $HOME for temporary operations that require fast data access. Presently there is no set limit to user $HOME size but as a general rule users should try to keep their $HOME directories below 30GB of space with the exception of short-term data storage to run calculations. Long-term storage should be kept in /media/data.
Linux X2Go remote desktop
X2Go clients are provided for Windows, OSX, and Linux systems on the X2Go website: http://wiki.x2go.org/doku.php. Linux clients should first check their distribution's repository for the x2goclient software.
While each X2Go client software is slightly unique, the following instructions should provide a general overview of how to connect to the X2Go server (Fig. 3).
Session tab:
Session Name=Hartman Server
Host=hartmanlab.genetics.uab.edu
Login=blazerid
SSH port=22
session type=MATE (required!)
Connection tab:
Connection speed should be set to LAN while the client is connected to the UAB network to provide the best user experience. Compression should be left at the default or be set to “adaptive” for ease of use. While connecting to the server off-campus these quality values can be lowered in order to provide a fluid user experience at the expense of image quality.
Input/output tab:
Set the desired startup window resolution size manually. If there are any issues with keyboard mapping (ex. the arrow keys are not working), select “Configure keyboard” and leave the default settings.
Media tab:
Disable sound support. This will prevent pulseaudio from spamming the server logs
Shared folders:
The user may select folders on his/her local computer to be shared with the server during the active session. The user should browse to the chosen folder on his/her computer, add it to the share, and select “automount”. Upon login, these folders will then appear on the server under /media/disk/<share_name> (Fig. 4).
Once configured, the user can select the session from the right side of X2Go client. If passwordless login is setup, X2Go will automatically login to a new session for that user. If password login is being used, the user will be prompted to enter his/her ssh password before logging in.
Running sessions can be paused or closed from the main client window. Also, multiple session parameters can be stored in the X2Go client, making it easy to select alternate quality settings based on internet client speed, or to provide multiple user login sessions on the same machine.
Note: Some programs do not continue to run at full speed when an X2Go session is paused. In these cases, the program should be run via remote SSH (optionally, in a tmux or screen session) and not in a graphical X2Go session.
Native X forwarding
Linux and OSX: The server supports X11 forwarding so that graphical programs launched via a terminal ssh session will open on the client computer as if the program is running locally. You can activate X11 forwarding by appending the “-X” option to the ssh command: ssh -X blazerid@hartmanlab.genetics.uab.edu
Windows: users can mimic the above functionality by installing Xming and enabling X11 forwarding in the PuTTY options.
You will now be able to launch graphical programs from the server and have them display on your client machine. For example, launch Matlab by running the matlab command after logging into the server via ssh with X forwarding enabled. The Matlab graphical display will launch on your client machine even if Matlab is not installed locally.
Windows SPICE QEMU/KVM remote desktop
A Windows 10 VM is launched automatically on startup and shared with the lab over a SPICE connection. SPICE clients exist for all platforms that will handle the connection seamlessly for the end user. For ease of use it is recommended that Linux, Windows and OSX users download and install virt-viewer.
The SPICE password for users (port 5900) is: hartmanlab
Alternatively the VMs can be accessed using remote-viewer (Applications >Internet>Remote Viewer) within an existing x2go session (Fig. 5).
The virtualized Windows 10 instances utilize UAB’s Azure protocol for account creation, thus you will need to login with your UAB e-mail address and password. Note: users should NOT login with a pin when prompted—it will disable access to the samba network shares (this is a Windows bug). Users should always log in with a password.
Once you are finished using the Windows virtual machine, it is vital that users log out of their Windows account so that subsequent users do not accidentally login to their account. Windows will perform an automatic logoff after 30 minutes of inactivity.
Robot computer access
While in an x2go or local session, launch remote-viewer (Applications>Internet>Remote Viewer) and create a new connection (connection>new, see Fig. 5):
vnc://192.168.16.101:5900
Samba File Server
While it is possible to mount Linux SFTP shares directly in Windows with third-party tools, it is better to allow native access to files from Windows clients for compatibility reasons. Linux samba shares can be mounted on Windows machines as if the drive exists locally.
Because samba uses a separate protocol from ssh/sftp, it requires a separate authentication token in order to grant users access to the share. On first login, users should change their default samba password using the smbpasswd command. The default password is the same as your blazerid—it is recommended that users select the same password they used for ssh login.
There are two samba shares per user, a private user home directory shared at \\blazerid\blazerid that maps to ~, and a global shared file storage directory shared at \\blazerid\data that maps to /media/data. These directories can be mapped to local drives in the Windows VM and mounted automatically at login (see Fig. 6).
Webcam robot monitoring
The lab webcam is viewable within an X2Go session by opening a web browser and entering: localhost:8888 in the url bar.
RStudio Server
Newer versions of RStudio do not support IDE access via X2Go. The IDE can be accessed via web browser at localhost:8787 in an X2Go session or via an SSH tunnel, i.e.:
ssh -f blazerid@hartmanlab.genetics.uab.edu -L 8787:localhost:8787 -N
Backing up data
The rsync, rsnapshot, and syncthing tools for making backups are all pre-installed on the server.
rsync is generally recommended for users that would like to periodically backup their ~ directory to a local machine over ssh. This can be accomplished by running:
rsync -azH –-delete blazerid@hartmanlab.genetics.uab.edu:~/ ~/backup
A graphical alternative is syncthing (Applications>Internet>Syncthing) which runs in the browser and can sync folders or files between machines using encrypted relays.
OPTIONAL
Passwordless (public-private key) authentication
In addition to password-based authentication, the SSH server also support public-private key authentication. Not only is this authentication method more secure than passwords, it will streamline the login process so that the user will not need to enter his/her password for most operations on the server. This is especially convenient if the user regularly transfers files via SCP or SFTP or accesses the remote desktop or VMs.
In order to set up public-private key authentication, the user will need to generate a public and private keypair on the client machine. The user will then store the private key locally on their computer and transfer the public key to the server.
Linux and OSX users can use ssh-keygen and Windows users can use PuTTYgen to generate a public-private keypair. The following is an example using ssh-keygen (note: entering a passphrase is not necessary):
blazerid@local-host$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/jsmith/.ssh/id_rsa):[Enter key]
Enter passphrase (empty for no passphrase): [Enter key]
Enter same passphrase again: [Enter key]
Your identification has been saved in /home/jsmith/.ssh/id_rsa.
Your public key has been saved in /home/jsmith/.ssh/id_rsa.pub.
Linux users can then use the ssh-copy-id command to automatically copy the public key to the server:
ssh-copy-id -i ~/.ssh/id_rsa.pub blazerid@hartmanlab.genetics.uab.edu
Similar utilities exist for OSX and Windows users but most find it easier to copy and paste the entire contents of the generated id_rsa.pub file into the ~/.ssh/authorizedkeys file on the server (or create the file if it does not yet exist) (Fig. 7).
Linux users have the added benefit that most programs should prioritize public/private key authentication over password based so little additional configuration is necessary.
Once the public key is stored on the server and the user has tested passwordless login via SSH, the X2Go client can be configured to utilize passwordless login by checking the “Try autologin” box (Fig. 3). Windows and OSX users should leave the box disabled and select their private key manually (i.e. id_rsa) in the “Use RSA/DSA key for ssh connection”. Additionally, they may need to add their private key to PuTTY and/or FileZilla/WinSCP to achieve passwordless login.
Once configured, the user will no longer need to enter their password to access the SFTP or X2Go server, which simplifies the process and enhances security.
Additional information for administrators
Installing software
Most software should be available directly from the CentOS repository. The Hartman server also has enabled the EPEL repository which expands upon the software selection available from CentOS. If a user needs a specific piece of software, an administrator should install it for them.
Search the repository for software: sudo yum search "program_name” (quotes are recommended if using * or ? wildcards)
Install the software: sudo yum install <program_name>
Some software (usually obscure or proprietary) will not be available in the repos. In this case an administrator should install the software package to /usr/local and create links to the pertinent binaries in /usr/local/bin, which is accessible to all users.
Most third-party software packages should come with a relevant INSTALL or README file that will provide instructions on how to compile and install the software. When all else fails, try the following “Big 3” commands:
1. ./configure
2. make
3. sudo make install
Maintaining software
The server uses the yum-cron service to automatically download and install security updates. However, periodically the CentOS developers will release updated software packages with new features that a user may need or request. In this case the package should be updated using: sudo yum update <packagename>
System-wide CentOS updates can be performed by running: sudo yum makecache && sudo yum update
It is generally good practice to restart the server after kernel or systemd updates.
Adding a new UNIX user:
1. sudo system-config-users
2. Add user
3. Use blazerid, add full name, and add temp password (make same as blazerid), click OK
4. Select user>properties>password info>force password change on next login
Allow user access to the Samba share:
1. sudo system-config-users
2. Select user blazerid>Properties>Groups>Select “smbgrp”>Click OK
3. sudo smbpasswd -a blazerid
4. Enter default password (same as blazerid)
5. Prompt user to change smbpasswd at next login
Make the new user an administrator:
1. sudo system-config-users
2. Select user>properties>groups>add user to 'wheel' group (this gives the user power to use the ‘sudo’ command to run programs as root)
Reset a user password:
1. sudo passwd blazerid
2. Enter temp password (same as blazerid)
3. Follow step 4 under “Adding a new user” to force the user to set a new password on next login
Remove an existing user and their home directory
1. sudo userdel -r username
Searching for currently installed software:
sudo yum list installed | grep -i "program_name"
Enabling/disabling services (systemd):
Ex. smb (samba sharing)
1. start automatically: sudo systemctl enable smb.service
2. do not start automatically: sudo systemctl disable smb.service
3. start: sudo systemctl start smb.service
4. stop: sudo systemctl stop smb.service
5. restart: sudo systemctl restart smb.service
6. reload unit-file: sudo systemctl daemon-reload
7. read unit-file: sudo systemctl cat smb.service
Maintaining hardware
Adding a new hard drive and automounting it on startup:
1. create GPT partion table
2. format w/ filesystem du jour
3. find partition UUID: sudo blkid
4. add to fstab (see existing /media/data line as reference): sudo gedit /etc/fstab
Adding a new virtual machine (VM)
Only system administrators can create and manage virtual machine resources. This is accomplished by running: sudo virt-manager
Use virt-manager to create a new machine and optionally copy an existing Windows .qcow2 disk so that Windows and the virtio drivers do not need to be reinstalled.
In case a new VM is required, the virtio virtualization drivers for QEMU/KVM are stored at /usr/share/virtio-win/ and more information can be found at: https://fedoraproject.org/wiki/Windows_Virtio_Drivers
System administrators should note that Windows 10 will not activate over the UAB network KMS correctly from a VM. Open a cmd window as an administrator and run the following to activate Windows 10 in the VM:
slmgr -skms itis-msls.ad.uab.edu
slmgr -ato
You may also need to manually configure the IPv4 DNS servers to connect to UAB network resources. These are: 138.26.5.2, 138.26.5.66
Virtual machine resources
Memory (but not CPU time!) is reserved for each running VM. Thus it is recommended to assign the least amount of memory possible to each running VM to accomplish specific tasks. The default memory assigned to each VM is 8GB.
CPU performance is complicated but in general it is fine to assign the number of hardware CPUs (sans hyperthreading) available to each VM.
Allow new users to access samba share within the Windows VM (Windows bug workaround)
1. Open C:\Windows\system32\drivers\etc\hosts file and copy contents
2. Open new text document, paste contents of existing hosts file and add appropriate blazerid and server IP line (see existing entries)
3. Save as “hosts” (no extension)
4. Copy new hosts file to C:\Windows\system32\drivers\etc\ (allow it to overwrite existing hosts file)
5. The new user will be able to map/access their samaba shares at \\blazerid\data and \\blazerid\blazerid
Making an existing Windows 10 account user an administrator
1. Login to the PC as the Azure AD user you want to be a local admin. This gets the GUID onto the PC.
2. Log out as that user and login as a local admin use
3. Open a command prompt as Administrator and using the command line, add the user to the administrators group: net localgroup administrators AzureAD\blazerid@uab.edu /add
4. Log back in as the user and they will be a local admin now
Creating more VM disk space
Example: sudo qemu-img resize /var/lib/libvirt/images/win10-5901.qcow2 +20G
Then add gparted iso (in /media/share/documentation) as boot device and expand working partition)
Security
The server has several security features in place, namely a stateful firewall and fail2ban brute-force blocker. Since all internet-facing services are initiated via ssh or samba, only two incoming ports are required to be open (22), which limits the attack surface. Fail2ban is configured to whitelist the UAB subnet, however repeated failed authentication attempts from off-campus clients will result in a three hour “cool down” period where any access from that IP address will be blocked. In cases of emergency, this can be reset manually by an administrator using the following command: sudo fail2ban-client set sshd unbanip IPADDRESS
If in the future it is discovered that ssh port scans are affecting server network performance, it is recommended that the ssh port be changed to something non-standard and the clients be reconfigured.
Logging
Global logs can be read using: sudo journalctl
This should be your first point of reference for server problems.
Session problems
If users do not exit X2Go sessions and the server is improperly shut down (i.e., sudden power loss), corruption may occur which will prevent future logins. I recommend running x2goterminate-session as the affected user through ssh to help rectify.
Current limitations and future ideas
There is a bug in the Windows PIN handling and SMB shares. There are some registry workarounds, but it’s best to avoid that and hope that Microsoft patches the bug in the future.
Configuration files
I have hard-linked some common file server configuration files in /media/data/documentation for easy administration.
Resources
RHEL documentation: https://access.redhat.com/documentation/en/red-hat-enterprise-linux/
Navigating the Linux command-line: https://www.digitalocean.com/community/tutorials/basic-linux-navigation-and-file-management
yum cheat sheet: https://access.redhat.com/articles/yum-cheat-sheet
systemd cheat sheet: https://access.redhat.com/articles/systemd-cheat-sheet
QEMU/libvirtd: https://wiki.archlinux.org/index.php/QEMU

3
script-files-permissions-set
View File

@@ -36,11 +36,12 @@ for path in "${paths[@]}"; do
echo -e "PATH\tUSER\tGROUP"
echo -e "$path\t$og_user\t$og_group"
if [[ "$group" != "smbgrp" || "$og_group" != "smbgrp" ]]; then
echo "$path is not world-accessible by the smbgrp group"
echo "$path is not world accessible by the smbgrp group"
ask_ok "Change $path group $og_group to smbgrp?" && group="smbgrp"
fi
done
ask_ok "Apply user: $user and group: $group to ${paths[*]} and all subdirs?" && \
chown -R "$user":"$group" "${paths[@]}"