Shortcuts
Sybila (internal resources)
Welcome stranger!
This is the homepage portal detailing internal compute resources of the Sybila lab. The services listed below are typically provided to all students, but sometimes need to be manually activated on an individual basis. In such cases, or with any questions and problems, contact xpastva@fi.muni.cz.
Compute and storage resources
Authentication
You should have a "lab" user account that works for all lab services. The username is your faculty username (i.e. xsomeone), the email address is your faculty email address (i.e. xsomeone@fi.muni.cz). Sadly, the password is different from your faculty and university account (see FAQ). User account has to be first manually created (send email to xpastva@fi.muni.cz). Once the account exists, you can reset your password through the login form at http://infra.sybila.fi.muni.cz/auth.
-
FAQ
- Why another account? Mostly because (a) connecting to university accounts safely is rather complex; (b) we can have accounts for alumni and external collaborators; (c) we can enforce 2FA authentication for some critical services, which is again rather complicated otherwise.
- Can I change my email address? At the moment, this has to be done manually by the admin, but any email address can be used.
- I did not receive the password reset email... The email is currently sent from a personal Gmail account, not the faculty email, because faculty SMTP servers don't want to talk to me. Make sure to check your spam folder and look for messages from
daemontus@gmail.com.
Public file sharing
This service allows you to upload arbitrary files to make them accessible at the https://infra.sybila.fi.muni.cz/public/${PATH} URL. You can use this to (a) publish manuals, papers or any other documentation for your project; (b) publish static websites that don't need special server software; (c) publish large datasets or files that you need to download repeatedly from multiple sources (e.g. for benchmarking). WARNING: Everyone with an account can edit the contents of this "shared folder". Be mindful of others, don't delete stuff that isn't yours. The file editor is available at https://infra.sybila.fi.muni.cz/browse/public (you will be redirected to authentication if you aren't logged in).
In case you need a true permanent link (like a DOI), it's still recommended to upload your data to a proper archive like Zenodo. But assuming you don't need immutability, this shared folder might be a simpler option.
-
FAQ
- How does it work again? You click on the editor link, log in, and you should see a file browser. You upload a file, say
test.txt. Afterwards, anyone can download that usinghttps://infra.sybila.fi.muni.cz/public/test.txt. If the file is an HMTL file, it will be displayed by the browser as a normal website. - Can I upload folders/zip archives? The file browser UI supports folder uploads. You can also upload archives, but it is not possible to extract them in the file browser. You can do this through your workspace though (see below).
- Can I upload data from command line or a CI server? Not at the moment, but this is definitely something that will need to be added at some point.
- Is the data backed up? The data is stored in a RAID array that can recover from one drive failure. So it should not spontaneously disappear. However, we don't have an off-site backup or an option to rollback when data is manually deleted; This should become available later.
- I want data on a different URL? With some extra manual configuration, we can forward almost any URL at
infra.sybila.fi.muni.cz(that isn't conflicting with an existing service) to a file in this shared folder. Send an email :) - I want data on a different domain? This will have to be approved by the unix team (we can generally request any subdomains of
sybila.fi.muni.cz, and in well justified cases also subdomains offi.muni.cz). Send an email, and we can arrange something.
- How does it work again? You click on the editor link, log in, and you should see a file browser. You upload a file, say
Personal workspaces
Each user can have a personal "lab home" on thepsyche07 machine that can be accessed using an online Visual Studio Code instace (isolated in a docker container) at https://infra.sybila.fi.muni.cz/code/${USERNAME}/. Alternatively, from the FI network, you can also use SSH, but this comes with some minor disadavantages (see FAQ). For new users, access to the personal workspace needs to be manually activated---just send an email to xpastva@fi.muni.cz. Using this workspace, you can access up to 24 CPU cores, 200GiB of RAM and 5TiB of RAID SSD storage. There are no per-user quotas or limits, so be mindful of other users (still, it's fine to use all resources as long as noone else needs them).
-
FAQ
- What's up with the docker container? Since each user has a dedicated container, they can install any software in their workspace without affecting others (they can also use
sudodirectly). Another reason is that it somewhat simplifies networking, authentication and maintainability overall (we can "reboot" a workspace or even migrate it to a completely new machine without worring too much about the consequences). - What's available in the workspace container? The container is based on a stripped down version of Ubuntu and comes pre-installed with some basic software (mainly
python,R,gccand essential build tools,openjdk,npm, and other ...). You can access the terminal directly from VSCode. The public file share (see above) is also mounted as/public, so you can directly copy stuff to/from this share. - Can I install my own software? You can and
sudois available in the container (since you already need to be authenticated to access the workspace, the password is just your username). However, upon restart, everything other than your home folder and the public share will reset to the original state. This means you don't have to worry too much about messing up your installation. To make software (or other changes) "permanent", there are two options:- We include it in the base docker image. This is not a big problem sice we control the image itself, and is preferred for simple tools that can be useful to other users as well (again, send an email and we'll make it happen).
- You can create a
~/.startup.shscript in your home folder (don't forget to mark it as executable), and put any installation steps there. If it exists, such script will be executed when the container is booting up, meaning you can put any configuration steps there that need to "survive" a reboot.
- Can I still SSH into this directly? Currently, there's no way to SSH into the workspace docker container directly, but as long as you are on the FI network, you can SSH into the
psyche-computehost to access the "base" operating system that is actually running the docker containers. Just use the VSCode interface to put an authorization SSH key into your home folder, and you can SSH intopsyche-computewith your username. You'll still have access to the same home folder and to the public file share (its location is/nfs/publicon the "base" system), but you will not havesudoprivileges (we try to keep the base system clean and maintainable, but reasonable requests for extra software are welcome :)). This is similar to howpsyche07used to work up to this point. - Can I have multiple workspaces or move my workspace to a different machine? Yes and yes. It requires a bit of extra config, so get in touch and we'll make it happen. With some caveats, we can also create a workspace-like VSCode experience on
aisaoraura, just without the extra isolation provided by docker. - Are the home folders backed up? They are stored on a redundant SSD RAID array, so they should survive single drive failures. However, we do not plan to provide offsite backup of home folders directly (a special "archive" share intended for critical data that need offsite backup will come later).
- What's up with the docker container? Since each user has a dedicated container, they can install any software in their workspace without affecting others (they can also use
Available hardware
This is what is currently being maintained. All "generally available" services run either on psyche07 or on stratus. The other machines require special access rights and are mostly intended for stuff like benchmarking, where exclusive or admin access is useful.
Sybila lab (A418)
Workstation psyche07
- Threadripper 2990WX (32 cores, 3.0-4.2Ghz)
- 256GB DDR4-2933
- 512GB SSD boot drive
- 4x2TB SSD RAID SSD pool (6TB usable)
- Proxmox 8.2
- Running VMs:
psyche-storagepsyche-servicespsyche-compute
Desktop salacia
- i5-6500 (4 cores, 3.6Ghz)
- 16GB DDR4-2133
- 256GB SSD boot drive
- Pop OS 22.04
- Personal use or dedicated benchmarking
Stratus (FI Cloud)
VM infra.sybila
- 0.5 CPU, 4GB RAM
- 4GB Boot drive
- Debian 12 (bookworm)
- Public IP address
- Docker containers:
reverse-proxyauthelia
VM services.sybila
- 0.5 CPU, 4GB RAM
- 4GB Boot drive
- Debian 12 (bookworm)
- Docker containers:
bbm-databasebbm-backendbbm-frontend
External machines
Brno "availability zone"
Desktop mystery-shack
- Ryzen 5800X (8 cores, 4.7Ghz)
- 128GB DDR4-3200
- 1TB and 2TB non-redundant SSD storage
- GTX 1080ti (11GB) and Radeon W6600 (8GB)
- Personal use or dedicated benchmarking
Bratislava "availability zone"
Desktop zavazadlo
- i7 4790 (4 cores, 3.6Ghz)
- 32GB DDR3-1333
- 5TB+4TB+4TB+3TB RAID HDD pool (11TB usable)
- 2x480GB SSD cache (mirrored)
- Personal use, cold storage and backups
Architecture diagram
A brief overview of what's running where. Other documentation, README-s and configuration scripts are available on the Sybila Gitlab.