==== Virtual Boxes ====

We use virtual machines for various purposes at the observatory.
For the concept of virtualization and virtual machines, see [[https://en.wikipedia.org/wiki/Virtual_machine|wikipedia]] and google. We use [[https://www.virtualbox.org | VirtualBox]] which is free and has been very reliable in the past.

Note that when you reboot/shutdown a machine that has a VBox running on it, that virtual box is not shutdown correctly but simply terminated which may result in **corrupted** disk image! Therefore always shut down the virtual boxes on that machine **first**, then reboot the host, and then restart the virtual boxes again.

The following virtual machines are installed at the observatory:

{| class="wikitable"
|-
!VBox
!OS
!Host
!running
!Purpose
|-

| auriga
| linux
| leo
| yes
| [[admin:cups|Print server]]
|-
| hydrus | linux | leo | yes | Web service (lectures) ^
| cetus | linux | draco | yes | new web server ^
| antlia | linux | draco | yes | Openproject ^
| erosita.fau.de | linux | serpens | yes | eROSITA NRTA ^
| gallus| Windows 8.1 | | no| Athena ^
| circinus | linux | | no | basic linux box for setup of new boxes ^
| | Windows XP | ursa | on demand | CCD Lab 1 ^
| | Windows XP | andromeda | on demand | CCD Lab 2 ^
| | Windows XP | tucana | on demand | camera East dome ^
| | Windows XP | reticulum | on demand | camera West dome ^

[[Category:Admin]]

Virtual Boxes

2018-04-11T13:35:43Z

Kreykenbohm:

==== Virtual Boxes ====

We use virtual machines for various purposes at the observatory.
For the concept of virtualization and virtual machines, see [[https://en.wikipedia.org/wiki/Virtual_machine|wikipedia]] and google. We use [[https://www.virtualbox.org | VirtualBox]] which is free and has been very reliable in the past.

Note that when you reboot/shutdown a machine that has a VBox running on it, that virtual box is not shutdown correctly but simply terminated which may result in **corrupted** disk image! Therefore always shut down the virtual boxes on that machine **first**, then reboot the host, and then restart the virtual boxes again.

The following virtual machines are installed at the observatory:

{| class="wikitable"
|-
!VBox
!OS
!Host
!running
!Purpose
|-

| auriga | linux | leo | yes | [[admin:cups|Print server]] ^
| hydrus | linux | leo | yes | Web service (lectures) ^
| cetus | linux | draco | yes | new web server ^
| antlia | linux | draco | yes | Openproject ^
| erosita.fau.de | linux | serpens | yes | eROSITA NRTA ^
| gallus| Windows 8.1 | | no| Athena ^
| circinus | linux | | no | basic linux box for setup of new boxes ^
| | Windows XP | ursa | on demand | CCD Lab 1 ^
| | Windows XP | andromeda | on demand | CCD Lab 2 ^
| | Windows XP | tucana | on demand | camera East dome ^
| | Windows XP | reticulum | on demand | camera West dome ^

[[Category:Admin]]

Virtual Boxes

2018-04-11T13:33:13Z

Kreykenbohm: Created page with "==== Virtual Boxes ==== We use virtual machines for various purposes at the observatory. For the concept of virtualization and virtual machines, see https://en.wikipedia.or..."

CUPS

2018-04-11T13:32:11Z

Kreykenbohm: Created page with " ==== Printing Service CUPS ==== Printing at the observatory is handled by CUPS. CUPS is installed in the virtual box auriga (which lives..."

==== Printing Service CUPS ====

Printing at the observatory is handled by [[https://www.cups.org/index.html|CUPS]].
CUPS is installed in the virtual box auriga (which lives on leo) and can be administered through a web interface running on port 631: http://auriga:631/ (accessible only from within the institute).

Through this web interface, printers can be added or modified, queues can be stopped, jobs canceled, and other other maintenance jobs can be performed. To perform such tasks, CUPS requires you to login: use ''ubuntuadmin'' and the corresponding password.

When addong new printers, do forget to enable ''sharing'' to make the printer visible in the entire cluster.

Check out the [[https://www.cups.org/documentation.html|CUPS documentation]] how to work with CUPS.

=== Trouble shooting ===

If a printer is not responding/not accessible:
* make sure that the printer is online (also check the network cable!), working properly, and not just busy.
* check the web interface of that printer, try to print a test page from the web interface.
* check the web interface for jobs in that queue. Remove failed jobs.

If no printers are availble (or just a generic printer), CUPS is probably down:
* login to auriga as ubuntuadmin
* restart the CUPS service:
<code>
sudo service cups stop
sudo service cups start
</code>
* sometimes it might be necessary to reboot the entire virtual box (CUPS will automatically be started after the reboot):
<code>
sudo shutdown -r now
</code>

=== List of Printers on the Cluster ===

[[Category:Admin]]

Overflow Filesystem

2018-04-11T13:28:28Z

Kreykenbohm: Created page with " ==== overflow file system ==== If the root file system is 100% full for some time, but the kernel or other system related jobs urgently need some space on the root file syste..."

==== overflow file system ====
If the root file system is 100% full for some time, but the kernel or other system related jobs urgently need some space on the root file system, e.g., to create temp files in /tmp, the kernel creates a small **overflow** file system which is then mounted on /tmp:
<code>
Filesystem Size Used Avail Use% Mounted on
overflow 1.0M 20K 1004K 2% /tmp
</code>
which resides in memory. Usually these overflow file systems are really tiny (1MB) - just large enough for urgent needs of the system.

First of all you need to make space on the actual root file system, see the article on the [[admin:unmet#completely_full_root_partition|completely full root file system]].

Once you have freed enough space on the root file system, this overflow file system is no longer needed. However, since it usually contains several files in use by the system you can **not** simply unmount the file system. Instead of trying to figure out which files are open and trying to close them, it is in general much more straightforward to simple reboot the machine, once you have made sure that no important jobs are running on the machine:
<code>
shutdown -r now
</code>

[[Category:Admin]]

Unmet Dependencies

2018-04-11T13:26:03Z

Kreykenbohm: Created page with "==== Unmet dependencies ==== Some machines report an unmet dependencies error without prior warning. This error message usually appears after the update of the kernel or modu..."

==== Unmet dependencies ====

Some machines report an unmet dependencies error without prior warning.
This error message usually appears after the update of the kernel or modules, i.e. the system update cron job reports (in case of successful updates, it is silent):

<code>
E: Unmet dependencies. Try using -f.
</code>

Typical approach to resolve the issue:

* login to that machine as ubuntuadmin
* run ''sudo apt-get -f install''

However, sometimes, you'll find that apt-get starts installing the missing packages, but then stops somewhere in the middle reporting **no space left on device** or similar.

In this case, first of all check how much free space is available on the root partition:
<code>
df -h /

Filesystem Size Used Avail Use% Mounted on
/dev/sda1 33G 31G 0 100% /
</code>

There are two cases:
* the root partition is completely full
* the root partition has lots of free space

=== completely full root partition ===
If the root partition is completely full, you need to find what is filling the root partition. Remember that the system normally uses less than 15GB!
The problem is sometimes to find **what** is using so much space (several GBs!).
Typical problems are:
* a lot of stuff in **/tmp**: /tmp should only contain small stuff. Big files or directories must go elsewhere.
* **huge log files** in /var/log: over time some log files grow huge. In this case old log files can be removed to make space. However, you should investigate **why** the log files have grown so large (it takes a lot of logging to create GB large files...) and solve that problem (whatever it might be)
* too many **kernels**: new kernels are released (and installed) usually more than once per month. Once the new kernel is installed by the system update, the older unneeded kernels are removed. However, sometimes the older kernels (along with configuration files, headers etc) remain on the system for some reason. In these cases the older kernel files have to be removed manually (see below).
* **torque** trash: torque produces temporary output/error files in /var/spool/torque/. Once the job is complete, the corresponding files are transferred to the destination specified by the torque job. However, does not complete but is interrupted (reboot, crash, ...) these temporary files remain. Over time a substantial amount of sometimes very large files can accumulate. All files not associated with currently running jobs can therefore be removed
* **other large files in /var**: there are more system services and processes that create (large) files somewhere under /var (rarely also elsewhere). In such a case you need to figure out what is filling up the disk, remove the large files and also check why such files have been created in the first place.

If the root file system was completely full, you may find that /tmp is mounted as [[admin:overflowfs|overflow file system]].

Once you have removed enough stuff from the system such that several GB are free again, you can complete the installation:
<code>
sudo apt-get install -f
</code>

=== root partition with enough empty space ===
If all relevant disks have several GB of free space available, the problem is something else.
In this case, the affected device is **not** one of the regular disks, but the **inital ram disk** which contains the modules needed for booting the PC. I.e. the initial ramdisk is too full and the needed new modules can not be installed. In this case you need to remove older unneeded modules from the initial ramdisk and the whole system.

List all installed kernel headers:
<code>
dpkg -l | grep linux-headers
</code>

However, you can not simply remove old kernels using ''apt-get'' as apt-get will first try to complete the installation, resulting again in the error message above. You therefore need to remove the old kernels and headers using dpkg. Remove basically all old kernel headers.

Example:
<code>
sudo dpkg -r linux-headers-3.13.0-100 linux-headers-3.13.0-100-generic
</code>

Note: do **not** bother to remove the linux kernel images, as these get removed by apt-get during an update and only a small configuration file remains.

Once you have removed a substantial amount of headers, you can then run apt-get to install the missing packages:

<code>
sudo apt-get install -f
</code>

Finally reboot the system and you're done.

[[Category:Admin]]

Login Problems

2018-04-11T13:22:42Z

Kreykenbohm: Kreykenbohm moved page Login Problems to Login

#REDIRECT [[Login]]

Login

2018-04-11T13:22:42Z

Kreykenbohm: Kreykenbohm moved page Login Problems to Login

Especially in the course of the update of 14.04 to 16.04 the following issues have turned out to happen quite often. The text was copied from Ingo's mail to the admin list.

* the .dmrc problem: if something else than "plasma" is specified in
this file in the home directory of the user, you'll get a "can not load
session" (or similar) error message. Since lightdm sort of "caches" the
value of this file in a file of its own, this can be very annoying to
sort out.

* the .Xauthority problem: can happen if a machine is newly installed
and the user has worked on that machine before the update, i.e. a wrong
key is stored in .Xauthority

* akonadi / baloo crap: if enabled, these daemons cause heavy IO load
and potentially slow down / inhibit login or make the machine barely
usable while creating the databases

* useless KDE animations: on older or weaker machines, enabling (or not
disabling) tons of KDE animations can make the machine very slow, or
might even crash the graphics driver

* reboot necessary: as it turned out in Marias case, the machine needed
a reboot. It seems that the new KDE is new more touchy w.r.t. a
necessary reboot. I.e. if KDE components have been updated by the
nightly cron jobs, the KDE/Ubuntu 16 system services (dbus et al)
apparantly do not get along very well any more causing these frozen
logins and a reboot is needed.
==> if this happens more often, we have to think about whether we can
continue with the nightly updates, or whether we do them only once a
week and have reboots afterwards (something like "reboot Monday" or
similar).

* _possibly_ some other cron job may interfere with the new KDE causing
these frozen logins.

[[Category:Admin]]

Login

2018-04-11T13:18:20Z

Kreykenbohm: Created page with " Especially in the course of the update of 14.04 to 16.04 the following issues have turned out to happen quite often. The text was copied from Ingo's mail to the admin list...."

Especially in the course of the update of 14.04 to 16.04 the following issues have turned out to happen quite often. The text was copied from Ingo's mail to the admin list.

* the .dmrc problem: if something else than "plasma" is specified in
this file in the home directory of the user, you'll get a "can not load
session" (or similar) error message. Since lightdm sort of "caches" the
value of this file in a file of its own, this can be very annoying to
sort out.

* the .Xauthority problem: can happen if a machine is newly installed
and the user has worked on that machine before the update, i.e. a wrong
key is stored in .Xauthority

* akonadi / baloo crap: if enabled, these daemons cause heavy IO load
and potentially slow down / inhibit login or make the machine barely
usable while creating the databases

* useless KDE animations: on older or weaker machines, enabling (or not
disabling) tons of KDE animations can make the machine very slow, or
might even crash the graphics driver

* reboot necessary: as it turned out in Marias case, the machine needed
a reboot. It seems that the new KDE is new more touchy w.r.t. a
necessary reboot. I.e. if KDE components have been updated by the
nightly cron jobs, the KDE/Ubuntu 16 system services (dbus et al)
apparantly do not get along very well any more causing these frozen
logins and a reboot is needed.
==> if this happens more often, we have to think about whether we can
continue with the nightly updates, or whether we do them only once a
week and have reboots afterwards (something like "reboot Monday" or
similar).

* _possibly_ some other cron job may interfere with the new KDE causing
these frozen logins.

[[Category:Admin]]

Admin:computer intro

2018-04-11T13:16:21Z

Kreykenbohm: Kreykenbohm moved page Admin:computer intro to Computer Introduction

#REDIRECT [[Computer Introduction]]

Computer Introduction

2018-04-11T13:16:21Z

Kreykenbohm: Kreykenbohm moved page Admin:computer intro to Computer Introduction

Computer Introduction

2018-04-11T12:32:40Z

Kreykenbohm:

Computer Introduction

2018-04-11T12:16:59Z

Kreykenbohm: Created page with "====== The computer introduction ====== * general introduction to the system (client server, Linux, ...) * distribute accounts & passwords * permissions (do not change..."

====== The computer introduction ======

* general introduction to the system (client server, Linux, ...)
* distribute accounts & passwords
* permissions (do not change)
* explain location of PCs
* if not not enough PCs, students should contact supervisors
* WLAN (refer to RRZE)
* no Ethernet connection for laptops (do not disconnect PCs!)
* USB sticks
* Printing
* remind students that bandwidth is limited
* in case of problems contact admins (telephone, Email)
* ask for questions

Setup prakti accounts

2018-04-11T12:10:41Z

Kreykenbohm: Created page with " Category:Admin ==== Setup prakti accounts ==== Shortly //before// a new lab course begins, initialize the prakti accounts: * login as ubuntuadmin on the home server..."

[[Category:Admin]]

==== Setup prakti accounts ====

Shortly //before// a new lab course begins, initialize the prakti accounts:
* login as ubuntuadmin on the home server phoenix: ''ssh ubuntuadmin@phoenix''
* become root: ''sudo su''
* go to /home/praktikum/intern/setup
* run the script setup: ''./setup''\\ This script will rsync the template prakti directory to the 7 prakti home directories. It will also remove anything from the prakti home directories not present in the template
* log out of phoenix
* log into crux as ubuntuadmin
* set new passwords for the prakti accounts:
* create a new random password, e.g. using http://passwordsgenerator.net/
* set the password: ''sudo passwd prakti1''
* note the password in a file
* do the above for all prakti accounts (use different passwords for every account)
* notify all users at remeis that the accounts have been setup and include the new passwords

//After// a block of the lab course is finished, you need to backup the accounts:
* get confirmation from Jörn, Uli, or Manami that all students are finished and the reports have been submitted.
* backup the prakti accounts:
* login as ubuntuadmin on the home server phoenix
* become root
* rsync the prakti accounts to your PC, e.g.,\\ ''rsync -av /home/praktikum/prakti* kreykenbohm@orion:/scratch1/DVD-Burner''
* check how much disk space is used by the accounts.
* if more than ~4 GB are used, remove unneeded files from the prakti accounts, i.e. firefox/chrome caches, Download folders etc.
* get as many blank DVDs as needed
* backup the accounts to the DVDs using ''k3b''
* label the DVDs appropriately (year, spring/fall, block, and disk number (if applicable))
* get jewel cases for the DVDs from the closet in the server room
* store the DVDs in closet to the right in the meeting room

**Note**: the timing is especially important between the first and second block of a lab course. You have very little time to get confirmation that all groups of the first block are finished, back up all accounts, and initialize the accounts for the second block. Sometimes (if some students are not finished in time) the setup can only be done in the morning of the day when the next block begins...

**Note**: in some rare cases a group does not finish before the next block begins. In this case do **not** initialize all accounts using the setup script, but keep the account of the delayed group and only initialze the other accounts.