Re: systemd (sysvinit осиротел, галактико опасносте!)

[Sergey B Kirpichev]

On Sun, Nov 15, 2015 at 04:22:45PM +0300, Sergey B Kirpichev wrote:
> On Fri, Nov 13, 2015 at 11:54:25PM +0300, Dmitry E. Oboukhov wrote:
> > >> что сказать, да - голосовал в голосованиях, да спорил в IRC.
> > >> да в рассылке поддержал тех кто сказал что "когда в Debian нельзя
> > >> будет жить без systemd, я уйду из Debian", но этого всего недостаточно
> > >> разумеется.
> > 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6661
> > > весь вклад русскоязычных DD в дискуссию ctte.  Самое время
> > > премудрым пескарям удивляться итогам голосования.
> > 
> > в голосовании я не имел права принимать участие, но я в него таки
> > отправил свой голос.
> 
> Там шло обсуждение, я о нем.
> 
> > но у нас увы всего восемь DD в России
> 
> Вот и я об чем.  Где все эти люди?  Почему их
> хватило на огромный тред в рассылке только сейчас,
> а не когда шло обсуждение и можно было бы что-то
> реально изменить?

(Заранее извиняюсь за некропостинг, но повод есть).

Заведен RFA для sysvinit (18 Jan):
https://bugs.debian.org/811377
пока нашелся только один герой, предложивший помощь.

Желающие?

Re: Как переносить настройки / мигрировать на другой сервер?

[Oleksandr Gavenko]

On 2016-02-06, Sergey B Kirpichev wrote:

> On Sat, Feb 06, 2016 at 05:32:02PM +0200, Oleksandr Gavenko wrote:
>> VPS хостер выставил тариф с условиями лучше чем сейчас.
>> 
>> Виртуализация на KVM. Я не представляю водможна ли миграция. Думаю есть
>> автоматические инструменты у хостера, но нужно создавать тикет...
>
> Разумеется возможна.  Бежите от такого хостера, что нагло
> вам в глаза врет, что не.
>
Я не уточнил. Разница в конфигурации только в размере накопителя.

Если RAM / CPU / количество ethernet - ОС при загрузке распределит, то
накопитель размечен разделами и не совсем ясно в чии обязаности входит вызов:

  resize2fs

если тупо перенести по dd раздел.

Если resize будет делать хостер - ему ножно знать тип FS и проконтролировать
успешность процеса расширения.

Хотя размечал раздел хостер и тип FS хостеру известен, т.к. на VPS он подбирал
инсталяционные образы.

Т.е. средства обслуживания KVM - такое делают легко (например в клик через GUI)?

-- 
http://defun.work/

Re: Как переносить настройки / мигрировать на другой сервер?

[Eugene Berdnikov]

On Sun, Feb 07, 2016 at 02:22:13PM +0200, Oleksandr Gavenko wrote:
> накопитель размечен разделами и не совсем ясно в чии обязаности входит вызов:
> 
>   resize2fs
> 
> если тупо перенести по dd раздел.
> 
> Если resize будет делать хостер - ему ножно знать тип FS и проконтролировать
> успешность процеса расширения.

 Утилита resize2fs применима к ext2/3/4. Для других fs есть другие утилиты,
 например, для xfs утилита называется xfs_growfs. А подтвердить успешность
 процесса расширения может лишь пользователь, если у него ядро не грохнется.
 Потому что никакие fsck полной гарантии не дадут.
-- 
 Eugene Berdnikov

Re: Как переносить настройки / мигрировать на другой сервер?

[Sergey B Kirpichev]

On Sun, Feb 07, 2016 at 04:38:23PM +0200, Oleksandr Gavenko wrote:
> 
>   https://lists.debian.org/debian-russian/2012/11/msg00131.html
> Как реализован "in place upgrade" в Дебиан?
> 
> Если на рабочей системе менять /etc, то желательно:
> 
>  * к rsync НЕ добавлять ключик --inplace:

Вообще-то, если говорить о /etc - то открытыми там держат
файлы очень немногие.  Посмотрите lsof.

> Как то не очень сильно документация на утилиты осчещает вопрос извлечения
> файлов которые in-use.

Потому что это не дело данных утилит.  Универсальный прием - остановить
"use", затем синхронизировать, а затем вновь "use".  Если хотите чего-то
большего - это будет существенно зависеть от конкретного приложения.

> Может показаться что на чистом Debian не буде сторонних польщователей/групп.
> Но даже у моей досашней машинки - пользователь mysql / tomcat7 - нестандартный
> и от порядка установки пакетов будет другой номер у пользователя ((

Вообще говоря, такая засада есть.  Но вы же _все_ файлы
синхронизируете, верно?  Значит вам либо на это должно быть
наплевать - либо вы хотите чего-то странного.

> Либо ковырять номерки в /etc/passwd и /etc/groups.

Так вам перенести _все_ надо, или ковырять?  Если перенести - то ничего
ковырять не надо.

> Конешно /etc/network.

И еще что-нить низкоуровневое, напр. /etc/lvm какой-нить.  Но слабо
представляю нафейхоа на vps он вам сдался.  По идее, кроме разных
IP - существенных различий у вас быть не должно.

> Понятно что /etc/shadow тоже будет другой. И возможно другие файлы с паролями.

Ну так сделаете его таким же, вот и все дела.

Re: Как переносить настройки / мигрировать на другой сервер?

[Oleksandr Gavenko]

On 2016-02-06, Sergey B Kirpichev wrote:

> On Sat, Feb 06, 2016 at 05:32:02PM +0200, Oleksandr Gavenko wrote:
>>  * Иерархию /srv/ можно было перенести rsync.
>>Проблему вижу в перенесении прав доступа. Некторых пользователей отдельно
>>создавал и давал каталог...
>
> В принципе, rsync, запущаемый (от рута) б-м стандартным образом (ключик -a,
> например) должен был перенести в точности все права доступа, uid/gid файлов.
>
>>А если делает - то он должен запускаться от root. Не ясно как пользоваться
>>от root.
>
> А что конкретно неясно?
>
>> При обновлении с Debian 7.0 до 8.0 - я выключил возможность ssh
>>для root:  rsync -e 'ssh -l root' user@vps/...
>
> А sudo вы тоже выключили?
>
> Как-то так вот:
> rsync -av --rsync-path="sudo rsync" ...
>
> Ну а если лень разбираться - просто включите временно "ssh для root" взад.
>
Итого вот рабочие команды:

  $ ssh user@vps "sudo tar cf - /etc" | sudo tar xf - -C ~/tmp

  $  sudo rsync -av --rsync-path="sudo rsync" --rsh=ssh user@vps:/etc/ 
~/tmp/etc/

С обоих концов :NOPASSWD для sudo. Без этого не представляю как ввести пароль
в sudo на удаленный хост.

Вспомнил, когда-то спрашивал:

  https://lists.debian.org/debian-russian/2012/11/msg00131.html
Как реализован "in place upgrade" в Дебиан?

Если на рабочей системе менять /etc, то желательно:

 * к rsync НЕ добавлять ключик --inplace:

 --inplace
 This option changes how rsync transfers a file when its data needs to
 be updated: instead of the default method of creating a new copy of
 the file and moving it into place when it is complete, rsync instead
 writes the updated data directly to the destination file.

 * к tar добавить опцию

-U, --unlink-first
 remove each file prior to extracting over it

Как то не очень сильно документация на утилиты осчещает вопрос извлечения
файлов которые in-use.

Стоит учесть также метаинформацию о правах:

 * Для rsync:
   -p, --perms
   -A, --acls
   -X, --xattrs

 * У GNU tar нет поддержки ACL, только:
 -p, --preserve-permissions, --same-permissions

   Потому нужно играться с bsdtar. Или до запаковки:

 sudo getfacl -R /srv > srv.acl

   и после распаковки:

 sudo setfacl --restore=srv.acl

>>rsync же не делает adduser?
>
> adduser можете ручками потом сделать.  Или тупо скопировать (sed/awk)
> нестандартные вещи из passwd, shadow - так легше не перепутать
> uid/gid'ы пользователей и групп.
>
На 2 разных хостах (чистая VPS и многолетняя домашняя):

  bash# sudo find /etc -type d -print0 | xargs -0 -n 100 sudo stat -c "%U" | 
sort -u
  postgres
  root

  bash# sudo find /etc -type d -print0 | xargs -0 -n 100 sudo stat -c "%G" | 
sort -u
  dip
  list
  lp
  postgres
  root
  ssl-cert
  tomcat7
  user

Согласно /usr/share/doc/debian-policy/policy.txt.gz:

 Some user ids (UIDs) and group ids (GIDs) are reserved globally for
 use by certain packages.  Because some packages need to include files
 which are owned by these users or groups, or need the ids compiled
 into binaries, these ids must be used on any Debian system only for
 the purpose for which they are allocated.
 The UID and GID numbers are divided into classes as follows:

 Packages other than `base-passwd' must not modify `/etc/passwd',
 `/etc/shadow', `/etc/group' or `/etc/gshadow'.

 0-99:
  Globally allocated by the Debian project, the same on every
  Debian system.  These ids will appear in the `passwd' and `group'
  files of all Debian systems, new ids in this range being added
  automatically as the `base-passwd' package is updated.

  Packages which need a single statically allocated uid or gid
  should use one of these; their maintainers should ask the
  `base-passwd' maintainer for ids.

"base-passwd" содержит предопределенные группы и пользователей:

  /usr/share/base-passwd/group.master
  /usr/share/base-passwd/passwd.master

Т.е. все системные группы и пользователи в Debian - будут иметь одинаковые
соответствия между номерами / именами.

Может показаться что на чистом Debian не буде сторонних польщователей/групп.
Но даже у моей досашней машинки - пользователь mysql / tomcat7 - нестандартный
и от порядка установки пакетов будет другой номер у пользователя ((

Аналогично можно пройтись по /srv

  bash# sudo find /srv/ -type d -print0 | xargs -0 -n 100 sudo stat -c "%U" | 
sort -u
  mysql
  user
  www-data

  bash# sudo find /etc/ -type d -print0 | xargs -0 -n 100 sudo stat -c "%G" | 
sort -u
  mysql
  user
  www-data

Потому на голую систему следует предварительно собрать нужные 
группы/пользователей и:

  $ addgroup --gid $ID $NAME
  $ adduser --uid $ID -gid $ID $NAME

А затем можно уже и rsync / tar. Иначе придется либо менять права на файлах:

  $ sudo find /srv -gid 110 -print0 | sudo xargs -0 -n 100 chgrp mysql

Либо ковырять номерки в /etc/passwd и /etc/groups.

>>  * Иерархию /etc/ стремно переносить по rsync.
>
> 

LSI MegaRAID SAS 8208ELP в Debian

[Sergey Kirpichev]

На всякий случай попробую поспрошать здесь.

Может кто-то из уважаемых имеет счастье иметь этот контроллер
в Debian, да еще в работоспособном виде?

# lspci |grep SAS
03:00.0 SCSI storage controller: LSI Logic / Symbios Logic MegaRAID SAS 
8208ELP/8208ELP (rev 08)

Задачи:
1) заставить его отдавать голые диски в систему (в наличии
при ем 3 шт. SAS разных размеров и разной степени убитости).
2) побить диски на разделы, сделать рейд средствами системы (md).
3) грузиться потом с этого самого контроллера.

C 1-2) худо-бедно получилось справиться, подсунув PCI ID
драйверу mptsas при инсталляции Debian Wheezy (см. напр.
http://forum.univention.de/viewtopic.php?f=48=1406
(В ядре из Jessie, вроде, этот idшник уже есть в драйвере.)
Загрузчик поставил на первый диск (sda), там же раздел для /boot,
далее на всех трех дисках выделил одинаковые разделы и
сделал raid5 массив.

А вот с 3) пока выяснилось следующее: контроллер позволяет
в своем биос пометить загрузочным только созданный там
райд-массив: в частности, raid0 из отдельного диска.  Именно
последний вариант я выбрал, сделав его из sda.

Система загружается, видит диски и разделы на них, за
исключением разделов на том самом первом диске.  Соответственно,
программный raid5 сразу разваливается.  Помимо дисков и созданных
мной mdadm массивов - виден также /dev/md127 (metadata:ddf), видимо
это то, что добавлено через BIOS контроллера.  Если сказать
mdadm --stop /dev/md127 && partprobe /dev/sda - появляются созданные
ранее разделы на первом диске, доступные для записи и после добавления
руками /dev/sda5 в развалившийся ранее raid5 массив - начинается
синхронизация данных на него (покуда массив не разваливается из-за
проблем с уже другим диском).

Подозреваю, что если сказать ядру md.ddf=0 - оно не будет стартовать
/dev/md127.  Будет ли этого достаточно, чтобы после загрузки корректно
определялись _все_ разделы и можно было обновлять загрузчик на /dev/sda
без риска повредить метаданные, что добавил контроллер?

PS: В аттаче прикрепил вывод mdadm с созданных массивов (уже после
убития raid5, увы, покуда еще там что-то шевелилось), --examine с sda.
$ sudo mdadm --detail /dev/md0
/dev/md0:
Version : 0.90
  Creation Time : Fri Feb  5 11:46:13 2016
 Raid Level : raid1
 Array Size : 248896 (243.10 MiB 254.87 MB)
  Used Dev Size : 248896 (243.10 MiB 254.87 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Fri Feb  5 22:15:29 2016
  State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

   UUID : 80bd2915:f9f84736:2e3043bf:80ad74ee (local to host debian)
 Events : 0.21

Number   Major   Minor   RaidDevice State
   0   8   170  active sync   /dev/sdb1
   1   8   331  active sync   /dev/sdc1

$ sudo mdadm --detail /dev/md1
/dev/md1:
Version : 1.2
  Creation Time : Fri Feb  5 11:47:01 2016
 Raid Level : raid5
 Array Size : 285988864 (272.74 GiB 292.85 GB)
  Used Dev Size : 142994432 (136.37 GiB 146.43 GB)
   Raid Devices : 3
  Total Devices : 3
Persistence : Superblock is persistent

Update Time : Fri Feb  5 23:59:24 2016
  State : clean, FAILED 
 Active Devices : 1
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 1

 Layout : left-symmetric
 Chunk Size : 512K

   Name : debian:1  (local to host debian)
   UUID : 4b854156:7a4d61e6:aba2c6bc:836bc8c5
 Events : 2080

Number   Major   Minor   RaidDevice State
   0   000  removed
   1   001  removed
   2   8   372  active sync   /dev/sdc5

   1   8   21-  faulty spare   /dev/sdb5
   3   85-  spare   /dev/sda5


$ sudo mdadm --examine /dev/sda
/dev/sda:
  Magic : de11de11
Version : 01.00.00
Controller GUID : 4C534920:20202020::::
  (LSI )
 Container GUID : 4C534920:20202020:1055:::1424
  (LSI  01/01/80 03:00:00)
Seq : 000f
  Redundant hdr : yes
  Virtual Disks : 1

  VD GUID[0] : 4C534920:20202020:1055::43E64F20:0A28
  (LSI  02/05/16 22:16:48)
 unit[0] : 0
state[0] : Optimal, Consistent
   init state[0] : Not Initialised
   access[0] : Read/Write
 Name[0] : 
 Raid Devices[0] : 1 (0)
   Chunk Size[0] : 128 sectors
   Raid Level[0] : RAID0
  Device Size[0] : 438475776
   Array Size[0] : 438475776

 Physical Disks : 1
  NumberRefNo  Size   Device  Type/State
 0998e4942  438475776K /dev/sdaactive/Online


$ uname -a
Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u2 x86_64 GNU/Linux

$ sudo mdadm --version
mdadm - v3.2.5 - 18th May 2012

$ sudo smartctl -a /dev/sdb
smartctl 5.41 

[DONE] wml://{security/2016/dsa-3468.wml}

[Lev Lamberov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- english/security/2016/dsa-3468.wml2016-02-07 16:39:32.0 
+0500
+++ russian/security/2016/dsa-3468.wml  2016-02-07 18:00:53.254019832 +0500
@@ -1,17 +1,18 @@
- -security update
+#use wml::debian::translation-check translation="1.1" maintainer="Lev Lamberov"
+обновление 
безопасности
 
- -It was discovered that polarssl, a library providing SSL and TLS
- -support, contained two heap-based buffer overflows that could allow a
- -remote attacker to trigger denial of service (via application crash)
- -or arbitrary code execution.
+Было обнаружено, что polarssl, библиотека для 
предоставления поддержки
+SSL и TLS, содержит два переполнения 
динамической памяти, которые могут 
позволить
+удалённому злоумышленнику вызвать отказ в 
обслуживании (через аварийное завершение 
работы
+приложений) или выполнить произвольный 
код.
 
- -For the oldstable distribution (wheezy), these problems have been fixed
- -in version 1.2.9-1~deb7u6.
+В предыдущем стабильном выпуске (wheezy) эти 
проблемы были исправлены
+в версии 1.2.9-1~deb7u6.
 
- -For the stable distribution (jessie), these problems have been fixed in
- -version 1.3.9-2.1+deb8u1.
+В стабильном выпуске (jessie) эти проблемы 
были исправлены в
+версии 1.3.9-2.1+deb8u1.
 
- -We recommend that you upgrade your polarssl packages.
+Рекомендуется обновить пакеты polarssl.
 
 
 # do not modify the following line
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJWt0AfAAoJEF7nbuICFtKlRHsP/2VMa5WMWZ37m8TOyZNEjql0
ji03a/3X3MvOQ9XMbLLqgSf0O7k6+LvtWP6B8yKSrXmIil5/K62rK4rrvc1r6Cga
mnSLoYk1GYwML7NPJn9dODJzfTlIE0a2CrCviOQ/R5j1lVE4yj4cwZTpFvVkH5xn
XNHIxLa2zOYsS/aIGspp+9xbHt1ydMjQuqpdnsibNA20u7BLog3gVjQ7BpKv89b+
K1bPkRPQ4NCKzeID50Y9/ynSjv3F4cHNmcGuOy4uMndkw4vQH1YoKaOWPQRtFq/q
3xuDevcrJCoSJaC7JxeXXwy0mQkOg+xcJIx74ClNeDJVMMldvnBQy3hKe30pH4Oz
uCnoOF2jEqafKygoeU+dA+GMRLs111xe+QK6GKxdYI45y/G1+1Rypjwz+fibYjMZ
CTequfPndgVmmfzcML8ZqrZQID9cf2io3Nhkg2xFGiNI08OFu8KxcbPvKE1maR8d
y3AQbLppHL+LnApg5YZZpsMD754aOHOmzv07hGNofxNdXqPwtPuYO2Lhz1B6LomX
fe9P2Ha2KprBqTGecsM6zefHAyBv9XJTm2r015yly2diCsaRjOsSH6DN17978aXd
cgAvLcd2ZLX1xwxdTsqCjS2rsmPYJb6jCkuuArUCS+Td7sP979BcxX9jWYJiOmhG
eDxjJWIBokwP9AbGD09I
=EAo0
-END PGP SIGNATURE-

Re: Как переносить настройки / мигрировать на другой сервер?

[Sergey B Kirpichev]

On Sun, Feb 07, 2016 at 02:22:13PM +0200, Oleksandr Gavenko wrote:
> Я не уточнил. Разница в конфигурации только в размере накопителя.

Тем более.

> Т.е. средства обслуживания KVM - такое делают легко (например в клик через 
> GUI)?

"Такое" - нет.  А перезапустить ваш VPS, предоставив вам
внутре диск большего размера - легко.  Изменять размеры партиций
и проч. - это уже на вас, конечно.

Re: Как переносить настройки / мигрировать на другой сервер?

[Oleksandr Gavenko]

On 2016-02-07, Oleksandr Gavenko wrote:

> Пока такой инфой располагаю.

Я много натеоретизировал и смотрю что задача переноса системы с одного хоста
на другой сходна с задачей создания бекапа + восстановления.

По бекапам есть несколько книжек. Нужно будет почитать.

-- 
http://defun.work/

Re: Как переносить настройки / мигрировать на другой сервер?

[Stanislav Vlasov]

7 февраля 2016 г., 19:13 пользователь Sergey B Kirpichev
 написал:
> On Sun, Feb 07, 2016 at 02:22:13PM +0200, Oleksandr Gavenko wrote:
>> Я не уточнил. Разница в конфигурации только в размере накопителя.
>
> Тем более.
>
>> Т.е. средства обслуживания KVM - такое делают легко (например в клик через 
>> GUI)?
>
> "Такое" - нет.  А перезапустить ваш VPS, предоставив вам
> внутре диск большего размера - легко.  Изменять размеры партиций
> и проч. - это уже на вас, конечно.

Иногда и без перезапуска можно.
У нас виртуалки на дебиане и убунте с ядрами новей 3.2 - отлично
ресайзятся без ребута.
А если кроме ядер ещё в udev добавили файлик - и внутрь не надо
лазить, чтоб resize2fs сказать.

-- 
Stanislav