Guy Fawkes

Welcome to Invision Community 5! Over the coming weeks, we'll be exploring a bunch of new features and improvements coming to our user interface including our brand new theme editor, a new mobile UI, dark mode and performance improvements thanks to a reduction in both JavaScript and CSS. To kick off this series, let’s take a closer look at the new sidebar layout and new view modes for the forum index and topic pages. Sidebar Layout Traditionally, Invision Community has shipped with a horizontal header and navigation bar at the top of the page, which is still available in version 5. We're introducing a brand new (and optional) sidebar layout, which can be enabled or disabled easily from within your theme settings. The sidebar not only provides convenient access to your applications, activity streams and search bar, but you can now add links to nodes for even easier access to popular or commonly used areas of your community. For example - a category from your forum, an album from the Gallery, or a product group from Commerce.

Unmounting an NFS Remote Share If you no longer want the remote directory to be mounted on your system, you can unmount it by moving out of the share’s directory structure and unmounting, like this: cd ~ sudo umount /nfs/home sudo umount /nfs/general Take note that the command is named umount not unmount as you may expect. This will remove the remote shares, leaving only your local storage accessible: df -h Output Filesystem Size Used Avail Use% Mounted on tmpfs 198M 972K 197M 1% /run /dev/vda1 50G 3.5G 47G 7% / tmpfs 989M 0 989M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock /dev/vda15 105M 5.3M 100M 5% /boot/efi tmpfs 198M 4.0K 198M 1% /run/user/1000 If you also want to prevent them from being remounted on the next reboot, edit /etc/fstab and either delete the line or comment it out by placing a # character at the beginning of the line. You can also prevent auto-mounting by removing the auto option, which will allow you to still mount it manually.

Mounting the Remote NFS Directories at Boot You can mount the remote NFS shares automatically at boot by adding them to /etc/fstab file on the client. Open this file with root privileges in your text editor: sudo nano /etc/fstab At the bottom of the file, add a line for each of your shares. They will look like this: /etc/fstab . . . host_ip:/var/nfs/general /nfs/general nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0 host_ip:/home /nfs/home nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0 Make sure you save and close this file so that your changes take effect.

How to Set Up an NFS Mount on Debian or Ubuntu Introduction NFS, or Network File System, is a distributed file system protocol that allows you to mount remote directories on your server. This allows you to manage storage space in a different location and write to that space from multiple clients. NFS provides a relatively standard and performant way to access remote systems over a network and works well in situations where the shared resources must be accessed regularly. In this guide, you’ll go over how to install the software needed for NFS functionality on Debian, configure two NFS mounts on a server and client, and mount and unmount the remote shares. Step 1 — Downloading and Installing the Components You’ll begin by installing the necessary components on each server. On the Host On the host server, install the nfs-kernel-server package, which will allow you to share your directories. Since this is the first operation that you’re performing with apt in this session, refresh your local package index before the installation: sudo apt update sudo apt install nfs-kernel-server Once these packages are installed, switch to the client server. On the Client On the client server, you need to install a package called nfs-common, which provides NFS functionality without including any server components. Again, refresh the local package index prior to installation to ensure that you have up-to-date information: sudo apt update sudo apt install nfs-common Now that both servers have the necessary packages, you can start configuring them. Step 2 — Creating the Share Directories on the Host You’re going to share two separate directories with different configuration settings, in order to illustrate two key ways that NFS mounts can be configured with respect to superuser access. Superusers can do anything anywhere on their system. However, NFS-mounted directories are not part of the system on which they are mounted, so by default, the NFS server refuses to perform operations that require superuser privileges. This default restriction means that superusers on the client cannot write files as root, reassign ownership, or perform any other superuser tasks on the NFS mount. Sometimes, however, there are trusted users on the client system who need to perform these actions on the mounted file system but who have no need for superuser access on the host. You can configure the NFS server to allow this, although it introduces an element of risk, as such a user could gain root access to the entire host system. Example 1: Exporting a General Purpose Mount In the first example, you’ll create a general-purpose NFS mount that uses default NFS behavior to make it difficult for a user with root privileges on the client machine to interact with the host using those client superuser privileges. You might use something like this to store files which were uploaded using a content management system or to create space for users to easily share project files. First, make the share directory on the host server: sudo mkdir /var/nfs/general -p The -p option for mkdir creates the directory and, if required, all parent directories. Since you’re creating it with sudo, the directory is owned by the host’s root user: ls -dl /var/nfs/general Output drwxr-xr-x 2 root root 4096 Apr 17 23:51 /var/nfs/general NFS will translate any root operations on the client to the nobody:nogroup credentials as a security measure. Therefore, you need to change the directory ownership to match those credentials. sudo chown nobody:nogroup /var/nfs/general Output drwxr-xr-x 2 nobody nogroup 4096 Apr 17 23:51 /var/nfs/general You’re now ready to export this directory. Example 2: Exporting the Home Directory In the second example, the goal is to make user home directories stored on the host available on client servers, while allowing trusted administrators of those client servers the access they need to conveniently manage users. To do this, you’ll export the /home directory. Since it already exists, you don’t need to create it. You won’t change the permissions, either. If you did, it could lead to a range of issues for anyone with a home directory on the host machine. Step 3 — Configuring the NFS Exports on the Host Server Next, you’ll dive into the NFS configuration file to set up the sharing of these resources. On the host machine, open the /etc/exports file in your text editor with root privileges: sudo nano /etc/exports The file has comments showing the general structure of each configuration line. The syntax is as follows: /etc/exports directory_to_share client(share_option1,...,share_optionN) You’ll need to create a line for each of the directories that you plan to share. Be sure to change the client_ip placeholder shown here to your actual client public IP address: /etc/exports /var/nfs/general client_ip(rw,sync,no_subtree_check) /home client_ip(rw,sync,no_root_squash,no_subtree_check) Here, you’re using the same configuration options for both directories with the exception of no_root_squash. Take a look at what each of these options mean: rw: This option gives the client computer both read and write access to the volume. sync: This option forces NFS to write changes to disk before replying. This results in a more stable and consistent environment since the reply reflects the actual state of the remote volume. However, it also reduces the speed of file operations. no_subtree_check: This option prevents subtree checking, which is a process where the host must check whether the file is actually still available in the exported tree for every request. This can cause many problems when a file is renamed while the client has it opened. In almost all cases, it is better to disable subtree checking. no_root_squash: By default, NFS translates requests from a root user remotely into a non-privileged user on the server. This was intended as security feature to prevent a root account on the client from using the file system of the host as root. no_root_squash disables this behavior for certain shares. When you are finished making your changes, save and close the file. Then, to make the shares available to the clients that you configured, restart the NFS server with the following command: sudo systemctl restart nfs-kernel-server Before you can actually use the new shares, however, you’ll need to be sure that traffic to the shares is permitted by firewall rules. Step 4 — Creating Mount Points and Mounting Directories on the Client Now that the host server is configured and serving its shares, you’ll prepare your client. In order to make the remote shares available on the client, you need to mount the directories on the host that you want to share to empty directories on the client. Note: If there are files and directories in your mount point, they will become hidden as soon as you mount the NFS share. To avoid the loss of important files, be sure that if you mount in a directory that already exists that the directory is empty. You’ll create two directories for your mounts on the client machine: sudo mkdir -p /nfs/general sudo mkdir -p /nfs/home Now that you have a location to put the remote shares and you’ve opened the firewall, you can mount the shares using the IP address of your host server: sudo mount host_ip:/var/nfs/general /nfs/general sudo mount host_ip:/home /nfs/home These commands will mount the shares from the host computer onto the client machine. You can double-check that they mounted successfully in several ways. You can check this with a mount or findmnt command, but the df -h command, which lists available disk space, provides a more readable output: df -h Copy Output Output Filesystem Size Used Avail Use% Mounted on tmpfs 198M 972K 197M 1% /run /dev/vda1 50G 3.5G 47G 7% / tmpfs 989M 0 989M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock /dev/vda15 105M 5.3M 100M 5% /boot/efi tmpfs 198M 4.0K 198M 1% /run/user/1000 10.124.0.3:/var/nfs/general 25G 5.9G 19G 24% /nfs/general 10.124.0.3:/home 25G 5.9G 19G 24% /nfs/home Both of the shares you mounted appear at the bottom. Because they were mounted from the same file system, they show the same disk usage. To see how much space is actually being used under each mount point, use the disk usage command du and the path of the mount. The -s flag provides a summary of usage rather than displaying the usage for every file. The -h prints human-readable output. For example: du -sh /nfs/home Output 36K /nfs/home This shows us that the contents of the entire home directory is using only 36K of the available space.

So we decided to give our users the opportunity to join in the secure communication! Our matrix server address: matrix.phoenix.lol This is the address you must enter into the Element program settings. Which is available for all platforms! We also have our web version available, which you can use from any device! Web version: element.phoenix.lol Matrix communication technology is an encrypted bunker for your messages, rooms, private and public chats! Communication is carried out both within one server and between servers! Each server is decentralized! Register yourself, invite your friends, raise your nodes in the network! Contact me via matrix: https://matrix.to/#/@fox:matrix.phoenix.lol

If you have solved a problem with Proxmox and Ceph, e.g. the crash of a monitor or OSD deamon has been noted and corrected, the error message often remains in the Proxmox web GUI. These log entries in the GUI are crash logs of the underlying Ceph system. The Ceph crash command can be used to manage Ceph crash logs: List Ceph crashes root@pve-01:~# ceph crash ls ID ENTITY NEW 2020-10-26_15:18:33.471228Z_1e218df6-0c92-4269-8e03-3bf6564e9aac mon.pve-03 2020-10-26_15:29:58.556281Z_1cda3f71-d4a1-47e2-83e9-a08285d2e041 mon.pve-02 Hide Ceph Crashes from the Proxmox GUI ceph crash archive <ID>: Archives single crash entry (will not appear in Proxmox GUI anymore) ceph crash archive-all: Archives all crash entries (no longer appear in the Proxmox GUI) After archiving, the crashes are still viewable with ceph crash ls. Ceph crash commands ceph crash info <ID >: Show details about the specific crash ceph crash stat: Shows the number of crashes since Ceph installation ceph crash rm <ID>: Deletes a single crash entry ceph crash prune <DAYS>: Deletes crashes older than <DAYS> days

We try! For ourselves and for people! Стараемся! И для себя и для людей!

Hi! As far as I remember - yes. But memory can fail. Download, install and check. Write whether it is zeroed or not... Привет! Насколько я помню - да. Но память может и подвести. Скачай поставь проверь. Напиши зануленый или нет...

Removing a ProxMox Cluster Sometimes it is necessary to delete the created Proxmox cluster and create a new one. There are instructions on the network, but they are not suitable - after deletion the cluster does not work, but the old nodes hang gray (inactive) and it is not possible to assemble a new cluster. First of all, we stop the cluster rm -fr /etc/pve/nodes/* systemctl stop pve-cluster systemctl stop corosync We are starting the cluster again in single mode pmxcfs -l Delete config files rm /etc/pve/corosync.conf rm -r /etc/corosync/* We kill a single process, preferably several times. killall pmxcfs pmxcfs: no process found e delete the list of nodes from the server, otherwise they will hang around there “dead”. rm -fr /etc/pve/nodes Let's turn on the cluster and enjoy life! systemctl start corosync systemctl start pve-cluster Restart web muzzle service pveproxy restart

Удаление ноды из кластера Proxmox и добавление с таким же именем Удаление ноды из кластера Proxmox При необходимости удаления ноды из кластера Proxmox следуйте этим шагам, чтобы корректно выполнить процесс и подготовить ноду к возможному добавлению в другой кластер. Шаг 1. Остановка сервисов на удаляемой ноде На ноде, которую вы собираетесь удалить, выполните следующие команды: systemctl stop pve-cluster systemctl stop corosync pmxcfs -l Шаг 2. Удаление конфигурации кластера на ноде Удалите конфигурационные файлы кластера с ноды: rm /etc/pve/corosync.conf rm -r /etc/corosync/* Затем завершите процесс pmxcfs: killall pmxcfs После этого перезапустите сервис pve-cluster: systemctl start pve-cluster Шаг 3. Удаление ноды из кластера с другой ноды На любой ноде, которая остаётся в кластере, выполните команду для удаления ноды. Используйте соответствующую команду в зависимости от количества нод в кластере: # Если кластер состоит из двух нод pvecm e 1 pvecm delnode namenode # Если в кластере более двух нод pvecm delnode namenode Замените namenode на имя удаляемой ноды. Шаг 4. Подготовка ноды для добавления в другой кластер Для добавления удалённой ноды в другой кластер очистите остатки конфигурации старого кластера: rm /var/lib/corosync/* Шаг 5. Восстановление ноды с тем же именем Добавление ноды с таким же именем выполняется стандартным способом, но после добавления потребуется обновить сертификаты. Обновление сертификата Выполните следующую команду на одной из нод кластера (эта папка общая для всех нод): ssh-keygen -f /etc/pve/priv/known_hosts Далее выполните команду на всех нодах: pvecm updatecerts --force После выполнения этих шагов нода будет удалена из кластера, и её можно будет использовать для присоединения к другому кластеру или повторного добавления с тем же именем.

View File Александр Стивенсон | Пираты. Большая иллюстрированная энциклопедия (2023) [PDF] Автор: Александр Стивенсон Издательство: Эксмо Серия: Подарочные издания. Досуг ISBN: 978-5-04-185786-8 Жанр: Универсальные энциклопедии Формат: PDF Качество: Необработанный скан (растеризация высокого качества) Иллюстрации: Цветные и черно-белые Описание: На каких кораблях плавали пираты и по каким маршрутам пролегали их основные пути? Что такое «пиратский кодекс» и какое наказание ждало провинившихся? Существовал ли Капитан Крюк и Джек Воробей, какие знаменитые пираты известны в истории разных стран? Поднимите паруса и приготовьтесь к завораживающей истории о золотом веке пиратства — от затопленных бурей парусных кораблей до дразнящих островов сокровищ, от пиратских флагов и моды до их коварного оружия и коварных поступков. Эта книга даст ответы на все вопросы о пиратах, вы узнаете множество тайн и легенд, а также почувствуете дух авантюризма! Путешествуйте вместе с пиратами по известным и далеким морским маршрутам, исследуя карты и раскрывая их секреты. Узнайте об опасностях, с которыми сталкивались пираты, от смертельных штормов до враждебных кораблей и жестоких сражений. Откройте тайны пиратских портов и укрытий, которые служили им базами операций и местами для спрятанных сокровищ. Submitter Guy Fawkes Submitted 01/01/25 Category E-Books RU