mdadm заменить диск, изменить размер массива (программный рейд)

ВАЖНО перед любыми операциями на хранилище убедитесь что бэкапы актуальны и исправны.

Сначала смотрим состояние массива, важно чтоб не шла синхронизация либо пересборка..
(я сделал ошибку, диск сбойнул и электричество выключили, я поменял физически диск и потом пытался собрать массив, что стоило мне немного нервов, надо было дождаться восстановления массива(а диск что вылетел пометить как сбойный), а уже потом идти менять диск.)

cat /proc/mdstat

вот например

# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 sdc1[8] sde1[7] sdg1[5] sdf1[2] sdd1[6]
5860147200 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/5] [UUUUU]
[=================>...] resync = 88.6% (1732051884/1953382400) finish=38.6min speed=95562K/sec

unused devices:

если такого нет, то помечаем диск сбойным

mdadm --manage /dev/md0 --fail /dev/sda1

затем удаляем его из массива

mdadm --manage /dev/md0 --remove /dev/sda1

выключаем сервер, меняем диск, новый диск перед добавлением в массив надо подготовить
а именно, копируем на него таблицу разделов с уже имеющего в рейде диска

sfdisk -d /dev/sdb | sfdisk /dev/sda

И добавляем заменённый диск в массив

mdadm --manage /dev/md0 --add /dev/sda1

после чего автоматически начнётся пересборка массива.

Расширение массива
Так получилось, что у меня массив состоял из дисков по 1.5ТБ но потом их перестали выпускать, и я менял диски на 2ТБ, но они не использовались по полной…
в итоге остался один диск на 1.5ТБ, решено его заменить на 2ТБ и расширить массив.

также перед началом смотрим что массив наш исправен, если всё ок то начинаем

mdadm --grow /dev/md0 --size=max

Автоматически начинается пересборка массива, у меня началась с 75%

вот что было до команды

# mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon Mar 11 11:32:41 2013
Raid Level : raid6
Array Size : 4395018240 (4191.42 GiB 4500.50 GB)
Used Dev Size : 1465006080 (1397.14 GiB 1500.17 GB)
Raid Devices : 5
Total Devices : 5

вот что стало после

# mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon Mar 11 11:32:41 2013
Raid Level : raid6
Array Size : 5860147200 (5588.67 GiB 6000.79 GB)
Used Dev Size : 1953382400 (1862.89 GiB 2000.26 GB)
Raid Devices : 5
Total Devices : 5

После синхронизации дисков, нужно расширить Файловую систему
предварительно выполнив проверку текущей, но
перед проверкой надо отмонтировать фс

umount /dev/md0

и проверяем

e2fsck -f /dev/md0

если всё ок, то расширяем ФС

resize2fs /dev/md0

Следить за процессом пересборки массива удобно вот такой командой

watch cat /proc/mdstat

apache 2.4 не видит виртуальные хосты не выполняет php ( [authz_core:error] client denied by server configuration )

Сразу несколько проблем в раз.

Местами встречаясь с Debian 8 стал замечать? что мои прошлые наработки и конфиги перестают работать.

Например, Apache перестал видеть виртуальные хосты, которые я ему создаю, а причина оказалась проста, отныне вхосты теперь должны иметь расширение

.conf

остальные файлы игнорируются.

поэтому делаем так

 mv /etc/apache2/sites-available/example.com /etc/apache2/sites-available/example.com.conf

также обязательно добавить

Require all granted

в секцию

Directory

вашей конфигурации, а это без этого бутт ошибка

[authz_core:error] AH01630: client denied by server configuration:

Более подробно можно почитать вот тут

joomla остановить нескончаемые попытки подобрать пароль

Не очень я люблю когда сервер занимается фигнёй.. и уже давно как логи все как один выглядят вот так

logs1

 

А помню были времена, когда ничего лишнего в логах не было.

Поэтому всячески рекомендую поставить этот плагин
Brute Force Stop

Незабываем включить плагин

plagin1

ну и всё наслаждаемся, спокойствием, проверил как на 3.2 так и на 2.5.20 (хотя на 2.5.4 выдавало ошибку, upgrade до 2.5.20 решил беду)

Уязвимость в tiny_mce в старых версиях joomla

Всем хорошего дня, одолела меня недавно напасть, всё грузят и грузят в пару сайтов шеллы да удаляют сайт целиком…

решил разобраться по горячим следам, что же происходит.

Первым делом идём изучать логи.

а логах довольно быстро находится частые запросы вот по такой урле

POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&version=1576&cid=20 HTTP/1.1

дальше в логах есть набор запросов на такие файлы, это скорее всего загрузчик шелла

 - - [17/Sep/2013:01:45:08 -0700] "GET /images/stories/3xp.php HTTP/1.1" 404 2271 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"
- - [17/Sep/2013:01:45:08 -0700] "GET /images/stories/0day.php HTTP/1.1" 404 296 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"
 - - [17/Sep/2013:01:45:08 -0700] "GET /images/stories/jahat.php HTTP/1.1" 404 296 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"
- - [17/Sep/2013:01:45:08 -0700] "GET /images/stories/70bex.php HTTP/1.1" 404 296 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"
 - - [17/Sep/2013:01:45:08 -0700] "GET /images/stories/itil.php HTTP/1.1" 404 296 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"
 - - [17/Sep/2013:01:45:09 -0700] "GET /images/stories/0d4y.php HTTP/1.1" 404 296 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"
- - [17/Sep/2013:01:45:09 -0700] "GET /images/stories/iam.php HTTP/1.1" 404 296 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"

есть и удачные конечно, после чего уже идут запросы к самому шеллу.

ну а дальше стандартная ситуация.

вбивая первую урлу в гугл я нахожу ссылки на эксплойт

например вот один из таких
http://www.bugreport.ir/78/exploit.htm

В 2х словах, если руками обратиться по ссылке

/index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&version=1576&cid=20

то вас средиректит на index.php, но если у вас отключен JS то вам откроется JCE со всеми своими возможностями по заливке файла.
дальше берётся файл .php и загружается на сервер под видом gif файла, это указано и в заголовке файла и в расширении.
потом используется второй баг, и происходит переименование гиф файла в php

вот и всё, притом не важно обновлена ли ваша joomla 1.5 до последней, забыл уже какая там 1.5.26 вроде, этот пакет видимо не входит в стандартную поставку джумлы. поэтому его нужно обновить в ручную, например скачать новую версию вот тут
https://www.joomlacontenteditor.net/downloads/editor/joomla15x
и установить на свой сайт.

второй момент, это запретить запуск php файлов из каталога /images логично же вполне? зачем в картинках исполнять пхп файлы? (вообще по хорошему бы разделить те файлы которые могу исполняться и те файлы которые могу загружаться извне. именно выстраивать систему прав и доступа так, чтоб то, куда можно загружать не могло быть исполнено, и то где можно что-то исполнять было невозможно туда загрузить что-то. )

поэтому в /images создаём файл .htaccess с вот таким содержимом

<Files *.php>
Deny from all
</Files>

ну и обаятельно проверить, закинуть туда простенький файл и проверить его выполнением..

UnicodeDecodeError: ‘ascii’ codec can’t decode byte 0xc2 in position 0: ordinal not in range(128)

Капец, это вынос мозга, всегда разрабатывал под ubuntu, а тут приходится в Win это делать, и вылазят такие невероятные ошибки и грабли… вот сегодняшяя….

ctype = ctype.encode(default_encoding) # omit in 3.x!

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 0: ordinal not in range(128)

сразу же всё предельно и ясно, он нам прямым текстом говорит что надо топать в реестр
вот сюда

HKEY_CLASSES_ROOT\MIME\Database\Content Type

и тут находим в самом низу ветки с русскими символами, и переименовывает в транслит\латиницу.

аминь…

оказывается это давний баг, есть решение вот тут
http://softwaremaniacs.org/forum/django/31707/

А как вы боретесь с такими глюками?
чем заменяете cmd чтоб было удобно работать как в привычном terminal ?

Страница 3 из 3912345...102030...Последняя »