Veeam B&R восстанавливаем работу после критической ошибки.

И так, прошлая статья показала, что не стоит делать с ВМ, особенно если вы там организовали хранилище, пусть даже и бекапов (особенно). Далее я получил следующие ошибки:
"Error: Cannot proceed with the job: existing backup meta file 'Germany-Folder.vbm' on repository 'Germany' is not synchronized with the DB. To resolve this, run repository rescan"

Рескан естественно не проходил, потому что бекапы уже туда сложены (по базе данных), а файл .vbm старой версии. Можно было попробовать отредактировать базу данных, но я крайне не рекомендую этого делать. ПОэтому решаем делать так:
удаляем файлы *.vbm со всех папок на уроненом датасторе, затем заходим в репозитории, находим наш репозиторий, проходим рескан заново. После рескана пробуем запустить джоб - не получается, снова ошибка:

Processing SOME_VM_NAME Error: All instances of the storage metadata are corrupted. Failed to open storage for read access. Storage: [\\path\to\Jobe\name\JOB-NAME2020-08-16T011455_0F5C.vib]. Failed to download disk. Shared memory connection was closed. Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}.      01:42

Что бы решить эту пробелму идём в Home\Backups\Disk, ПКМ по нашему джобу и  Remove from configuration, длее перезапускаем джоб и радуемся уже успешному бекапу. По восстановлению более старых точек просто скажу так, есть копия, кототрая находится на другом хранилище, поэтому данными файлами я могу немного принебречь.

Vmware: почему ручные снэпшоты это плохо.

 Очень редко я пишу, особенно сюда. Но, надеюсь мне будет напоминалка или Вам руководство, ка кделать не надо. Предыстория: есть несколько нод, собранных одним vcentrom разнесены ноды по разным странам: Израиль и Германя. Бекап производится 1 бекап сервером на raid массив на самом бекап сервере (Израиль), копия на файловой windows шаре (Германия). Бекапы с серверов в Германии складываются на шару в Германии и копии летят в Израиль. В какой-то момент было необходимо по какой-то космической причине кому-то (возможно даже мне) сделать снимок на виртуалке с файловой шарой в Германии, которой под thin provision было выдано 4 Tb жёсткого диска из 5.5 возможных. Там же вертелось ещё пара виртуалок. Получив утром сообщение о том, что есть снапшот, который кто-то забыл удалить я решил попробовать это сделать по привычке, прямо из консоли, но не тут то было, удаяться он не особо хотел, ушло на это больше, чем планировалось (больше рабочего дня). На следующий день по понятным причинам не прошли некоторые бекапы и не удалился снепшот, зато появилось сообщение о том, что нужно консолидировать диски.
Пфф, думал я. А зря, консолидация не проходила, т.к. место закончилось, мало того, из-за thin provision ушатался ещё и виртуальный роутер, благодаря которому была построена часть инфраструктуры, вертелся он там же на том же разделе. Ок, если мы не можем совместить данные, давайте попробуем их вырезать (удалить, потерять, как хотите). Тушим машину, удаляем из инвентаря диск на машине (не физически), далее идём по ссх на хост и пробуем переименовать VM_Name_2-000001-sesparse.vmdk, запустить машину, (если удалить или переименовать его не удаляя диска с ВМ - ВМ не запустится!). Машина стартонула, диска вроде нет, ок, теперь вручную добавляем существующий диск - получилось. Заходим в машине в диск менеджмент и делаем снова диск онлайн - получилось. Теперь проверяем диск (можно даже онлайн) - прошло успешно за пару сек - прекрасно. Теперь смотрим на дату измененя файлов .vmdk, интересует наш (в конкретном случае VM_Name_2-flat.vmdk - дата стоит сегодня и время почти актуальное, только теперь можно удалить переименованный VM_Name_2-000001-sesparse.vmdk.bak, освободив при этом достаточно места что бы жить дальше. А дальше предстояло восттановить работу бекапов...

Автоматичекий перезапуск службы очереди печати

Предистория.
Имеется удалённый сервер с принтерами подключёнными по айпи из офиса по айписеку/тунелю или прочьей дичи.

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

if ( (Get-WMIObject -Class Win32_Printer -Computer $env:computername | Where-Object {($_.PortName -like '*`.*`.*`.*') -and ($_.PrinterStatus -eq '1')} | Select PrinterStatus).count > 4 ) { Restart-Service -Name Spooler }

Итак разберём однострочник:
Get-WMIObject -Class Win32_Printer -Computer $env:computername - получаем список принтеров на текущем хосте
Where-Object {($_.PortName -like '*`.*`.*`.*') -and ($_.PrinterStatus -eq '1')} - выбираем те принтеры, где в названии порта присутствует подобие ip адреса (на мой взгляд в этом кейсе вполне достаточно такой конструкции дабы не уложнять)  и статус с ошибкой (равен 1, обычная работа статус 3)
.count > 4 данная конструкция берёт количество наших принтеров и сравнивает с числом 4, в вашем же случае может быть вообще другие числа.
Restart-Service -Name Spooler ну и если условие выполняется - перезапускаем сервис спуллера.
Для удобства можно разбить эту конструкцию для удобства и понимания:

# Threshold offline printers
$PrintersCount = 4
# Get offline printers count
$OfflinePrinters = (Get-WMIObject -Class Win32_Printer -Computer $env:computername | Where-Object {($_.PortName -like '*`.*`.*`.*') -and ($_.PrinterStatus -eq '1')} | Select PrinterStatus).count
# If offline printers more than threshold restart spooler
if ( $OfflinePrinters  > $PrintersCount ) { Restart-Service -Name Spooler }

Лентяй №1 или как заставить компьютеры в домене находиться в правильной OU

Задача:

При добавлении компьютера в домен пользователем с соответствующими правами, необходимо перемещать компьютер в нужную OU.

Отступление: перемещение удобно для нарезания правильных политик, да и сортировать по департаментам весьма удобней, нежели все компютеры в одной папке. Действия производим на контроллере домена. Структура:

DC=CONSTOTO,DC=COM

OU=Departments,DC=CONSTOTO,DC=COM

OU=SomeDepartment,OU=Departments,DC=CONSTOTO,DC=COM

OU=Computers, OU=SomeDepartment,OU=Departments,DC=CONSTOTO,DC=COM

OU=Groups, OU=SomeDepartment,OU=Departments,DC=CONSTOTO,DC=COM

OU=Users, OU=SomeDepartment,OU=Departments,DC=CONSTOTO,DC=COM

И так, приступим. План действий:

1. Пользователь (адммин участка/отдела) сам может (и должен) ввести компьютер (сервер) в домен.
2. В любом объекте типа компьютер есть акой парметр, как ms-ds-creatorsid, его мы и будем использовать для автоматизации.
3. Пишем скрипт.
4. Добавляем скрипт в планировщик заданий.

$Clients = Get-ADComputer -SearchBase "CN=Computers,DC=constoto,DC=com" -Properties ms-ds-CreatorSid, WhenCreated -Filter {ms-ds-creatorsid -ne "$Null"}
$Users = Get-ADUser -Filter * -SearchBase "OU=Departments,DC=constoto,DC=com"
ForEach ($C in $Clients) {
    ForEach ($U in $Users) {
        If ($U.Sid -eq $C.'ms-ds-creatorsid') {
            $Target = $U.distinguishedName -replace 'CN=.*,OU=Users',"OU=Computers"
            $Source = $C.objectGUID
            Write-Host (Get-Date -Format g) "- Object '$Source' going to '$Target'"
            Move-ADObject -Identity $Source -TargetPath $Target
        }
    }
}

Планировщик:

1. создал простое задание начало в 7 утра, повторять каждые 5 минут, запускать независимо залогинен пользователь или нет
2. программа/скрипт PowerShell.exe, аргуманты: -ExecutionPolicy Bypass C:\kostyli\CompToOU.ps1
3. юзер с правами на всю эту красоту (админ, как например)

Теперь осталось заставить админов департаментов делать своё чёрное дело.

Админка для почты Sendmail+Cyrus-imap (webmin)

В общем проблемы как у всех на 7-й осе, стандартные:

# cat /var/webmin/miniserv.error
[04/May/2016:16:13:55 +0300] miniserv.pl started
[04/May/2016:16:13:55 +0300] Perl module Authen::PAM needed for PAM is not installed : Can't locate Authen/PAM.pm in @INC (@INC contains: /usr/libexec/webmin /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at (eval 12) line 1.
BEGIN failed--compilation aborted at (eval 12) line 1.

Лечил так:

yum install cpan pam-devel

 yum group install "Development Tools"

далее пытался установить модуль через консоль:

# perl -MCPAN -e shell
> install Authen::PAM

НО - не помогло, ошибка не пропала, поразмыслив - решил сделать так:

yum install perl-Authen-PAM

[04/May/2016:16:32:45 +0300] miniserv.pl started
[04/May/2016:16:32:45 +0300] PAM authentication enabled

Всем Удачи :)

Sendmail + Cyrus + saslauthd + Active Directory

Не так давно стала задачка перевести почтовик на авторизацию через AD, прочитано куча форумов и вариантов как это сделать, в итоге всё получилось довольно-таки изящно.
начнём, пожалуй с нашей "прослойки" - с сасла (saslauthd):

# cat /etc/sysconfig/saslauthd
SOCKETDIR=/run/saslauthd
MECH=ldap
FLAGS="-O /etc/saslauthd.conf"

В сам  /etc/saslauthd.conf

# cat /etc/saslauthd.conf
ldap_servers:ldap://dc.constoto.com/ ldap://dc1.constoto.com/ ldap://dc2.constoto.com/
ldap_bind_dn:CN=mail,CN=Users,DC=CONSTOTO,DC=COM
ldap_password:$tr0ngP@$$w0rd
ldap_search_base:DC=CONSTOTO,DC=COM
ldap_filter:(sAMAccountName=%u)
ldap_auth_method:bind
ldap_deref: never
ldap_restart: yes
ldap_scope: sub
ldap_use_sasl: yes
ldap_mech: DIGEST-MD5
ldap_start_tls: no
ldap_version: 3
ldap_timeout: 10
ldap_cache_ttl: 30
ldap_cache_mem: 32768

Далее в /etc/sasl2/Sendmail.conf

# cat /etc/sasl2/Sendmail.conf
pwcheck_method:saslauthd

Теперь Cyrus-imapd, он же цайрус, он же в узких кругах цероз (есть за что):

# cat /etc/imapd
configdirectory: /var/lib/imap
partition-default: /var/spool/imap
partition-1: /var/spool/imap
defaultpartition: 1
admins:cyrus
sievedir: /var/spool/imap/sieve
sendmail:/usr/sbin/sendmail
hashimapspool: true
sasl_pwcheck_method: saslauthdsasl_mech_list: PLAIN LOGIN DIGEST-MD5
altnamespace: yes
lmtp_downcase_rcpt: 1
lmtp_over_quota_perm_failure: 1
lmtp_strict_quota: 1
poptimeout: 10
expunge_mode: delayed
delete_mode: delayed
allowusermoves: 1
tls_cert_file: /etc/pki/cyrus-imapd/mail.crt
tls_key_file: /etc/pki/cyrus-imapd/mail.key
tls_ca_file: /etc/pki/cyrus-imapd/mail.ca-bundle

Далее часть сендмыла (для авторизации) будет выглядеть следующим образом:

define(`confLDAP_CLUSTER', `gates')
define(`confLDAP_DEFAULT_SPEC', `-h constoto.com -b dc=constoto,dc=com -d uid=mail,dc=constoto,dc=com -M simple -P /etc/mail/ldap.conf')
FEATURE(`ldap_routing',`null',`ldap -1 -T -v mail -k (&(|(objectclass=user)(objectclass=group))(mail=%0))',`bounce')dnl

TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL DIGEST-MD5 LOGIN PLAIN')dnl

Проверяя авторизацию и аутентификацию был немного разочарован, т.к. CRAM-MD5 не получится уже использовать.

Файл /etc/mail/ldap.conf принимает вид:

dn: uid=mail,dc=constoto,dc=com
uid: mail
homeDirectory: /etc/mail
userPassword:$tr0ngP@$$w0rd

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

Как я восстанавливал TP-Link 841nd из состояния полного кирпича

Предыстория:  жил у меня и не тужил домашний бюджетный роутер 841-й со съёмными антеннами (nd) на стоковой прошивке ровно до того момента, как прошла хорошая гроза и сгорел wan порт на нём, я не отчаился и поставил поверх старой прошивки openwrt через обновление, настроил vlan'ы, работало нормально, но мне показалось мало и я решил по-ковырять эти самые вланы... в итоге получил кирпич, на который нельзя зайти через сеть (никак, вообще никак), по статьям из тырнетика я нашёл способ подключиться через uart, но на тот далёкий 2013 год, я мало хотел понимать, и при неудаче просто забросил железку в долгий угол... и вот я её достал.

В общем история не нова, надо прошить при помощи uart роутер, НО, если Вы игрались с openwrt и vlan - это будет тщетно, т.к. пакетики не ходят так как надо, НО как было обнаружено, при подключении по uart, после загрузки проши, нажимаем банальный энтер и попадаем в консоль OpenWrt под рутом(!). Этого вполне достаточно, что бы нам вернуть прошу к жизни:

#mount_root

#mtd -r erase rootfs_data

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