При попытке смонтировать ntfs раздел sda3 под linux получал ошибку следующего вида:
klepto # mount -t ntfs-3g /dev/sda3 /mnt/media
The disk contains an unclean file system (0, 0).
Metadata kept in Windows cache, refused to mount.
Falling back to read-only mount because the NTFS partition is in an
unsafe state. Please resume and shutdown Windows fully (no hibernation
or fast restarting.)
Could not mount read-write, trying read-only
Так бывает, если windows завершила работу некорректно, была в гибридном сне или гибернации. В этих случаях помогает перезагрузка в windows и\или проверка диска на ошибки из под этой OS. В моем случае эти методы не помогали, но к счастью ошибки можно поправить из linux с помощью утилиты ntfsfix.
Итак - лечим.
Сначала размонтируем раздел
umoun /dev/sda3
После чего, чиним
sudo ntfsfix /dev/sda3
Mounting volume... The disk contains an unclean file system (0, 0).
Metadata kept in Windows cache, refused to mount.
FAILED
Attempting to correct errors...
Processing $MFT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($LogFile)... OK
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sda3 was processed successfully.
Теперь раздел можно смонтировать и он будет доступен для записи.
Вам ведь не нужно напоминать, что вы все делаете на свой страх и риск, и автор статьи не несет ответственности за возможный причиненный ущерб? ;-) Экспериментируйте, ведь дорогу осилит идущий.
Довольно частое явление, когда один из дисков выпадает из рейда и надо его добавить снова.
Проверяем состояние рейда:
$ sudo cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda1[0]
1953381376 blocks super 1.2 [2/1] [U_]
bitmap: 13/15 pages [52KB], 65536KB chunk
Как видно (в результате одна буква U вместо двух) одного диска, в данном случае sdb1 не хватает что показывает результат команды
$ sudo mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Thu Nov 28 14:23:43 2019
Raid Level : raid1
Array Size : 1953381376 (1862.89 GiB 2000.26 GB)
Used Dev Size : 1953381376 (1862.89 GiB 2000.26 GB)
Raid Devices : 2
Total Devices : 1
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Wed May 19 14:21:25 2021
State : active, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0
Consistency Policy : bitmap
Name : sirma:0 (local to host sirma)
UUID : 9ae9a023:bf0caa1c:f60c90f2:89458fe0
Events : 41373
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
- 0 0 1 removed
Первое, что нужно попробовать и что в большинстве случаев помогает - заново добавить диск в рейд
sudo mdadm --manage /dev/md0 --add /dev/sdb1
Читаем результат
$ sudo mdadm --manage /dev/md0 --add /dev/sdb1
mdadm: re-added /dev/sdb1
Проверяем результат
$ sudo cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdb1[1] sda1[0]
1953381376 blocks super 1.2 [2/2] [UU]
bitmap: 4/15 pages [16KB], 65536KB chunk
unused devices: <none>
Радуемся.
Эта статья не позволяет полностью решить все возникшие проблемы, но элементарно восстановить работоспособность можно.
Вам ведь не нужно напоминать, что вы все делаете на свой страх и риск, и автор статьи не несет ответственности за возможный причиненный ущерб? ;-) Экспериментируйте, ведь дорогу осилит идущий.
Много работаю в консоли и у меня постоянно открыта куча вкладок с разными серверами. Заметил такую особенность, в частности на calculate linux (другие дистрибутивы не проверял): если сессия долго открыта и находится в фоновой вкладке, то сессия зависает. На нажатия клавиатуры не реагирует, а при закрытии окна терминала и последующей попытке подключиться заново, до ввода пароля дело не доходит.
Происходит это из-за того, что эта сессия уже заняла сокет на котором должно инициироваться подключение. Перезапуск службы sshd тут не работает и единственный способ (за исключением перезагрузки), который я нашел, это удалить файл сокета, который находится по этому пути:
/home/user/.ssh/cm_socket/=user@192.168.1.1:22
этих файлов там может быть много, в зависимости от количества подключенных сессий ssh, так что выбираем зависший и удаляем. После чего можно подключаться уже без проблем, а файл создастся заново
Вам ведь не нужно напоминать, что вы все делаете на свой страх и риск, и автор статьи не несет ответственности за возможный причиненный ущерб? ;-) Экспериментируйте, ведь дорогу осилит идущий.
Достался мне в наследство от старого админа такая штука, как open exchange server. Никому он не был нужен, но вдруг начальству потребовался схожий функционал и пришлось разбираться.
Как завести пользователя? А вот шут его знает, в официальной документации я не нашел информации, на просторах интернета ее тоже практически нет. Долго искал как войти в панель администратора в надежде, что оттуда это можно сделать, но нет.
В конечном итоге, нарыл искомое в bash history пользователя root.
Добавление пользователя:
/opt/open-xchange/sbin/createuser -c 1 -A oxadmin -P пароль_oxadmin -u i.ivanov -d "Иванов Иван" -g Иван -s Иванов -p пароль_от_почты_нового_пользователя --language ru_RU --timezone Europe/Moscow --company имя_компании --department IT -e i.ivanov@почта.ru --imaplogin i.ivanov@почта.ru --imapserver ip_входящей_почты_сервера --smtpserver ip_исходящей_почты_сервера
Удаление пользователя:
/opt/open-xchange/sbin/deleteuser -c 1 -A oxadmin -P пароль_oxadmin -u i.ivanov
Редактирование пользователя:
Например, мы хотим изменить группу пользователя и перенесте его из IT в Managers, делаем соответствующие изменения:
/opt/open-xchange/sbin/changeuser -c 1 -A oxadmin -P пароль_oxadmin -u i.ivanov -d "Иванов Иван" -g Иван -s Иванов -p пароль_от_почты_нового_пользователя --language ru_RU --timezone Europe/Moscow --company имя_компании --department Managers -e i.ivanov@почта.ru --imaplogin i.ivanov@почта.ru --imapserver ip_входящей_почты_сервера --smtpserver ip_исходящей_почты_сервера
Как видно, все нужные скрипты лежат в каталоге /ope/open-xchange/sbin/ так что их можно вдумчиво почитать.
Вам ведь не нужно напоминать, что вы все делаете на свой страх и риск, и автор статьи не несет ответственности за возможный причиненный ущерб? ;-) Экспериментируйте, ведь дорогу осилит идущий.
Как-то я решил, что мне слишком скучно в последнее время и я решил обновить ubuntu на моем vps с версии 18 до 20.04
Сказано - сделано!
После перезапуска mysql-сервера, проблемы начались на двух из трех сайтов, а именно они использовали эту субд. При попытке зайти на сайт с drupal cms вылезало окошечко:
PDOException: SQLSTATE[42000]: Syntax error or access violation: 1231 Variable 'sql_mode' can't be set to the value of 'NO_AUTO_CREATE_USER'
Так случилось из-за обновленной версии mysql. К счастью - правится это легко.
Открываем файл в редакторе
/var/www/your_website/includes/database/mysql/database.inc
Ищем строку режима работы sql и удаляем из нее NO_AUTO_CREATE_USER, так как именно на это ругается drupal
Было
sql_mode="REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER"'
Стало
sql_mode="REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO"'
Все, с Drupal разобрались. Можно переходить к piwigo
Тут все тяжелее и легче. Ругань подобного рода.
arning: [mysql error 1064] You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'groups, show_title, id_line, width
Как исправить это, я не нашел, но примерно понял, что проблема скорее всего с дополнительными плагинами. На это указывал еще и тот факт, что мобильная версия сайта запускалась и прекрасно работала, а для нее плагины типа additional page, header manager не предназначены.
Все что я сделал, это забрался в админку через версию для телефона и обновил все плагины и саму версию piwigo до 11. Теперь все работает.
Вам ведь не нужно напоминать, что вы все делаете на свой страх и риск, и автор статьи не несет ответственности за возможный причиненный ущерб? ;-) Экспериментируйте, ведь дорогу осилит идущий.
Созрела необходимость пользоваться защищенным контейнером на сервере с ubuntu 20.10 без gui, чтобы хранить всякую рабочую информацию, которую временами нужно убрать с глаз посторонних.
В официальных репозиториях я не нашел veracrypt, потому скачал с официального сайта необходимую мне актуальную версию.
и установил ее
dpkg -i veracrypt-console-1.24-Update7-Ubuntu-20.10-amd64.deb
Теперь, создаем новый том
veracrypt --create
и готовимся ответить на несколько вопросов касающихся размера, файловой системы, точки монтирования etc.
тип тома (обычный или скрытый)
Volume type:
1) Normal
2) Hidden
Select [1]:
путь до файла контейнера
Enter volume path: /home/your_name/new_conteiner
Укажем размер контейнера (мой будет 10GB)
Enter volume size (sizeK/size[M]/sizeG): 10000
Выберем алгоритм шифрования (по умолчанию AES)
Encryption Algorithm:
1) AES
2) Serpent
3) Twofish
4) Camellia
5) Kuznyechik
6) AES(Twofish)
7) AES(Twofish(Serpent))
8) Camellia(Kuznyechik)
9) Camellia(Serpent)
10) Kuznyechik(AES)
11) Kuznyechik(Serpent(Camellia))
12) Kuznyechik(Twofish)
13) Serpent(AES)
14) Serpent(Twofish(AES))
15) Twofish(Serpent)
Select [1]: 1
Выберем алгоритм хэша (по умолчанию SHA-512)
Hash algorithm:
1) SHA-512
2) Whirlpool
3) SHA-256
4) Streebog
Select [1]: 1
Определимся с файловой системой. Мой диск должен читаться как в linux так и в windows, кроме того, на него будет записаны файлы размером больше 4GB, потому я остановился на NTFS
Filesystem:
1) None
2) FAT
3) Linux Ext2
4) Linux Ext3
5) Linux Ext4
6) NTFS
7) exFAT
8) Btrfs
Select [2]: 6
теперь нужно придумать пароль для контейнера
Enter password:
и повторить его
Re-enter password:
теперь нас просят ввести PIM. Эта штука нужна для, своего рода, двухфакторной аутентификации и каждый раз при монтировании диска, придется вводить еще и PIM. Соответственно, это увеличивает безопасность.
Enter PIM:
На этом шаге, нас просят указать путь к ключевому файлу, без которого открыть контейнер не получится. По умолчанию файл не создается и можно просто нажать enter
Enter keyfile path [none]:
Теперь нужно 320 раз напечатать различные буквы, цифры и символы. Требуется для шифрования
Please type at least 320 randomly chosen characters and then press Enter:
После этого начнется создание тома и в результате он (барабанная дробь) будет создан!
Done: 100.000% Speed: 64 MiB/s Left: 0 s
с этого момента, можно переходить к главе о монтировании тома.
Том мы создали, теперь осталось смонтировать его
создадим каталог для точки монтирования
mkdir /home/username/vera_volumes
Смонтируем диск опираясь на следующий синтаксис:
sudo veracrupt -t /путь_до_файла_контейнера /точка_куда_монтируем
sudo veracrupt -t /home/your_name/new_conteiner /home/username/vera_volumes
у нас просят пароль на контейнер
Enter password for /home/your_name/new_conteiner:
Номер pin (пропустить, если не указывали его при создании контейнера)
Enter PIM for /home/your_name/new_conteiner:
путь до ключевого носителя (если указывали при создании контейнера)
Enter keyfile [none]:
вопрос о наличии скрытого тома (если указывали при создании контейнера)
Protect hidden volume (if any)? (y=Yes/n=No) [No]:
отмонтировать том можно командой
veracrypt --dismount /home/your_name/new_container
Собственно это все. Том подключен и им можно пользоваться.
Вам ведь не нужно напоминать, что вы все делаете на свой страх и риск, и автор статьи не несет ответственности за возможный причиненный ущерб? ;-) Экспериментируйте, ведь дорогу осилит идущий.