How to unlock an user account in Linux?

Source

How to unlock a user account in Linux?

Some times on Linux boxes the user account will be locked due to issues such as wrong password entry, account expiry etc. In this post we will see how to unlock user account with different commands.
Example1: Check if the password is disabled by viewing /etc/shadow file for user entry.
grep ‘username’ /etc/shadow
if you are able to see ! in the second field starting that indicates that password is disabled, you have to enable it back by using passwd with -u option
passwd -u username
Example:
passwd -u surendra
Unlocking password for user temp.
passwd: Success
Example2: Check if the user expiry date is reached or not by using chage command
chage -l username
Example
chage -l surendra
Last password change : Jan 05, 2012
Password expires : never
Password inactive : never
Account expires : Jan 01, 2012
Minimum number of days between password change : 0
Maximum number of days between password change : 99999
Number of days of warning before password expires : 7


If you see that the account expires use usermod or chage command to extend the user expiry time.
usermod -e yyyy-mm-dd username
usermod -e 2012-05-10 surendra
or
chage -E yyyy-mm-dd username
chage -E 2012-05-10 surendra
this will extend user expiry time to 5 more months.
Example3: Check if the user shell is set to a valid shell or not, if it’s not set it to a valid one.
grep ‘username’ /etc/passwd
Example:
grep ‘surendra’ /etc/passwd
If the user shell in seventh feild is set to /sbin/nologin or /bin/false set it back to /bin/bash or /bin/ksh
usermod -s /bin/bash usrename
usermod -s /bin/bash surendra
Share your thoughts on this and let us know if you have other ideas to unlock user accounts in Linux.

Force unmount of NFS-mounted directory

source


If the NFS server disappeared and you can't get it back online, one trick that I use is to add an alias to the interface with the IP of the NFS server (in this example, 192.0.2.55).

Linux

The command for that is something roughly like:

ifconfig eth0:fakenfs 192.0.2.55 netmask 255.255.255.255

Where 192.0.2.55 is the IP of the NFS server that went away. You should then be able to ping the address, and you should also be able to unmount the filesystem (use unmount -f). You should then destroy the aliased interface so you no longer route traffic to the old NFS server to yourself with:

ifconfig eth0:fakenfs down 

 umount -f -l /my/mount/dir

Установка Bind 9 (named) в CentOS 7

Источник

Устанавливаем Bind 9 (named) в CentOS 7

Первым делом проверим, установлен ли у нас днс сервер в системе:

# rpm -qa bind*
 bind-libs-lite-9.9.4-14.el7.x86_64
 bind-license-9.9.4-14.el7.noarch

У меня не установлен, так как во время инсталляции centos выбрал минимальный пакет программ. Сервер имен у нас будет работать в chroot окружении, так что устанавливаем соответствующие пакеты:

# yum -y install bind bind-utils bind-chroot

Еще раз обращаю внимание, что мы будем использовать bind в chroot среде для увеличения безопасности. Это накладывает определенные особенности в настройке и управлении сервером. Нужно быть внимательным в этих мелочах. Итак, запускаем bind:

# systemctl start named-chroot
# systemctl enable named-chroot
ln -s '/usr/lib/systemd/system/named-chroot.service' '/etc/systemd/system/multi-user.target.wants/named-chroot.service'

Проверяем содержимое chroot каталога:

# ls -l /var/named/chroot/etc

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

Настраиваем DNS сервер в CentOS 7

Файл конфигурации нашего сервера располагается по адресу /var/named/chroot/etc/named.conf. Открываем его и приводим к следующему виду:

# mcedit /var/named/chroot/etc/named.conf

options {
listen-on port 53 { any; };
listen-on-v6 port 53 { none; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
allow-query { 127.0.0.1; 192.168.7.0/24; };
recursion yes;
allow-recursion { 127.0.0.1; 192.168.7.0/24; };
forwarders { 8.8.8.8; };
version "DNS Server";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};

zone "." IN {
type hint;
file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

logging {
channel default_file {
file "/var/log/named/default.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
category default { default_file; };
};

Эта конфигурация обеспечит работу обычного кэширующего сервера в локальной сети. Комментарии к некоторым параметрам:

listen-on-v6 port 53 { none; };	Отключили работу на интерфейсе ipv6.
allow-query { 127.0.0.1; 192.168.7.0/24; };	Разрешаем обычные запросы только из локальной сети.
allow-recursion { 127.0.0.1; 192.168.7.0/24; };	Разрешаем рекурсивные запросы только из локальной сети.
forwarders { 8.8.8.8; };	Перенаправляем запросы, которые сами не резолвим, на днс сервер гугла. У меня указан он просто для примера. Тут лучше всего указать сначала ДНС серверы провайдера.
version «DNS Server»;	Скрываем версию бинда, вместо этого выводим указанную строку.

Не забудьте отредактировать правила фаервола для корректной работы DNS сервера — открыть 53 порт UDP для работы кэширующего сервера, который мы сейчас настроили, и 53 порт TCP для пересылки зон, о которых речь пойдет дальше

Поддержка собственной зоны

Допустим, нам необходимо в нашем named разместить собственную зону site1.ru. Первым делом создаем файл зоны, которую будет обслуживать dns сервер:

# mcedit /var/named/chroot/var/named/site1.ru.zone

$TTL 86400
@        IN     SOA     site1.ru. site1.ru.local. (
                        2015092502
                        43200
                        3600
                        3600000
                        2592000 )

        IN NS ns1.site1.ru.
        IN NS ns2.site1.ru.
        IN A 192.168.7.254
        IN MX 10 mx.site1.ru.

gate    IN A 192.168.7.254
mx      IN A 192.168.7.250
ns1     IN A 192.168.7.235
ns2     IN A 192.168.7.231

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

Выставляем необходимые права:

# chown root:named /var/named/chroot/var/named/site1.ru.zone
# chmod 0640 /var/named/chroot/var/named/site1.ru.zone

Дальше подключаем файл зоны в конфигурационном файле bind — /var/named/chroot/etc/named.conf:

zone "site1.ru" {
 type master;
 file "site1.ru.zone";
};

Перечитываем конфигурацию named с помощью rndc:

# rndc reconfig

Настройка логов в bind (named)

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

Bind дает широкие возможности для ведения логов. Можно фиксировать практически все, что связано с работой сервера. Я сейчас на простых примерах покажу, как это работает.

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

channel general {
file "/var/log/named/general.log" versions 3 size 5m;
severity dynamic;
print-time yes;

Здесь указано название канала, которые мы придумываем сами — general, указан путь до файла, сказано, что хранить будем 3 версии лога размером не более 5 мегабайт. Параметр severity может принимать следующие значения:

Описание параметров severity

critical	Только критические ошибки.
error	Обычные ошибки и все что выше.
warning	Предупреждения и все, что выше.
notice	Уведомления и все, что выше.
info	Информационные сообщения и все что выше.
debug	Сообщения уровня debug и все, что выше. Уровни debug  регулируются значениями 0, 1, 2, 3.
dynamic	То же, что и debug, только его уровень регулируется глобальной настройкой сервера.

Параметр print-time указывает на то, что в лог необходимо записывать время события. Помимо указанных мной настроек, в конфигурации канала могут быть добавлены следующие параметры:

• print-severity yes | no — указывает, писать или нет параметр severity в лог
• print-category yes | no — указывает писать или нет название категории логов

Я эти параметры не указал, так как по-умолчанию устанавливается значение no, которое лично меня устраивает.
Дальше необходимо указать категорию логов и в какой канал мы будем ее записывать:

category general { general; };

Категорий у днс сервера bind достаточно много. Вот мой перевод полного списка с описаниями:

Описание категорий логов в bind (named)

default	Сюда будут попадать события всех категорий из этой таблицы, если они не определены отдельно, за исключением категории queries, которую нужно включать специально. То есть если обозначить только категорию default, то в нее будут сыпаться события всех категорий.
general	Эта категория для всех логов, которые не включены ни в одну из перечисленных категорий.
database	Сообщения, относящиеся к хранению зон и кэшированию.
security	Подтверждение и отказ в выполнении запросов.
config	Все, что относится к чтению и выполнению файла конфигурация.
resolver	Разрешение имен, включая информацию о рекурсивных запросах, выполняемых от имени клиента кэширующим сервером.
xfer-in	Информация о получении зон.
xfer-out	Информация о передаче зон.
notify	Логирование операций протокола NOTIFY.
client	Выполнение клиентских запросов.
unmatched	Сообщения, которые named не смог отнести ни к одному классу или для которых не определено отображение.
network	Логирование сетевых операций.
update	Динамические апдейты.
update-security	Подтверждение или отклонение запросов на апдейт.
queries	Логирование запросов к ДНС серверу. Для включения этой категории необходимо отдельно задать параметр в конфигурации сервера. Это связано с тем, что эта категория генерирует очень много записей в лог файл, что может сказаться на производительности сервера.
query-errors	Ошибки запросов к серверу.
dispatch	Перенаправление входящих пакетов модулям сервера на обработку.
dnssec	Работа протоколов DNSSEC и TSIG.
lame-servers	Фиксируются ошибки, которые получает bind при обращении к удаленным серверам в попытке выполнить запрос на разрешение имени.
delegation-only	Логирование запросов, вернувших NXDOMAIN.
edns-disabled	Запросы, которые вынуждены использовать plain DNS из-за превышения timeouts.
RPZ	Все операции, связанные с выполнение Response Policy Zone (RPZ).
rate-limit	Операции связанные с одним или несколькими rate-limit statements в options или view.

Таким образом, чтобы вывести все категории логов в отдельные файлы, необходимо в конфиг named добавить следующую конструкцию:

logging {

channel default {
file "/var/log/named/default.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel general {
file "/var/log/named/general.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel database {
file "/var/log/named/database.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel security {
file "/var/log/named/security.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel config {
file "/var/log/named/config.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel resolver {
file "/var/log/named/resolver.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel xfer-in {
file "/var/log/named/xfer-in.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel xfer-out {
file "/var/log/named/xfer-out.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel notify {
file "/var/log/named/notify.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel client {
file "/var/log/named/client.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel unmatched {
file "/var/log/named/unmatched.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel network {
file "/var/log/named/network.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel update {
file "/var/log/named/update.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel update-security {
file "/var/log/named/update-security.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel queries {
file "/var/log/named/queries.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel query-errors {
file "/var/log/named/query-errors.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel dispatch {
file "/var/log/named/dispatch.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel dnssec {
file "/var/log/named/dnssec.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel lame-servers {
file "/var/log/named/lame-servers.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel delegation-only {
file "/var/log/named/delegation-only.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel edns-disabled {
file "/var/log/named/edns-disabled.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel rpz {
file "/var/log/named/rpz.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel rate-limit {
file "/var/log/named/rate-limit.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel cname {
file "/var/log/named/cname.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

category default { default; };
category general { general; };
category database { database; };
category security { security; };
category config { config; };
category resolver { resolver; };
category xfer-in { xfer-in; };
category xfer-out { xfer-out; };
category notify { notify; };
category client { client; };
category unmatched { unmatched; };
category network { network; };
category update { update; };
category update-security { update-security; };
category queries { queries; };
category query-errors { query-errors; };
category dispatch { dispatch; };
category dnssec { dnssec; };
category lame-servers { lame-servers; };
category delegation-only { delegation-only; };
category edns-disabled { edns-disabled; };
category rpz { rpz; };
category rate-limit { rate-limit; };
category cname { cname; };
};

Теперь создадим папку для логов. Не забываем, что мы работаем в chroot окружении:

# cd /var/named/chroot/var/log && mkdir named && chown named. named

Если мы хотим собирать все логи запросов из категории queries, то в раздел options файла конфигурации необходимо добавить параметр, который это разрешает:

querylog yes;

Перезапускаем bind:

# systemctl reload named-chroot.service

Проверка работы DNS Server

Первым делом пойдем в каталог с логами и проверим, что там у нас:

# cd /var/named/chroot/var/log/named
# ls -l

Все файлы журнала созданы и начали наполняться. Можно проверить один из них. Например, посмотрим, как наш сервер centos (192.168.7.246) логирует запросы пользователей. Попробуем с компьютера 192.168.7.254 (windows) выполнить nslookup yandex.ru и посмотрим как это отразится в лог файле:

26-Sep-2015 19:25:30.923 client 192.168.7.254#56374 (yandex.ru): query: yandex.ru IN A + (192.168.7.246)
26-Sep-2015 19:25:31.013 client 192.168.7.254#56375 (yandex.ru): query: yandex.ru IN AAAA + (192.168.7.246)

Теперь выполним ping site1.ru, чтобы проверить, как сервер поддерживает нашу зону:

Смотрим, что в логах:

26-Sep-2015 19:28:01.660 client 192.168.7.254#49816 (site1.ru): query: site1.ru IN A + (192.168.7.246)

Таким образом очень удобно отследить, куда лезет компьютер. Например, можно поднять временно dns сервер, включить лог запросов. В клиенте указать единственный днс сервер, который мы настроили. Дальше можно отслеживать, к примеру, куда лезет винда после загрузки без нашего ведома. Или откуда грузится реклама в скайпе.

Setup multipath in CentOS OS

yum -y install device-mapper-multipath.x86_64
mpathconf --enable --find_multipaths y --with_multipathd y --with_chkconfig y
reboot if needed
multipath -ll

How to identify the HBA cards/ports and WWN in Linux

Source

There are several commands to determine the WWN of a Fibre Channel (FC) HBA and their status (online/offline). The post discusses few of the most commonly used methods.
Method 1
To find the HBA cards installed on your system use :

# lspci -nn | grep -i hba
07:00.0 Fibre Channel [0c04]: QLogic Corp. ISP2532-based 8Gb Fibre Channel to PCI Express HBA [1077:2532] (rev 02)
07:00.1 Fibre Channel [0c04]: QLogic Corp. ISP2532-based 8Gb Fibre Channel to PCI Express HBA [1077:2532] (rev 02)

To check the available HBA ports :

# ls -l /sys/class/fc_host
total 0
drwxr-xr-x 3 root root 0 Feb  3  2015 host2
drwxr-xr-x 3 root root 0 Feb  3  2015 host3

To find the state of HBA ports (online/offline) :

# more /sys/class/fc_host/host?/port_state
::::::::::::::
/sys/class/fc_host/host2/port_state
::::::::::::::
Online
::::::::::::::
/sys/class/fc_host/host3/port_state
::::::::::::::
Online

To find the WWN numbers of the above ports :

# more /sys/class/fc_host/host?/port_name
::::::::::::::
/sys/class/fc_host/host2/port_name
::::::::::::::
0x500143802426baf4
::::::::::::::
/sys/class/fc_host/host3/port_name
::::::::::::::
0x500143802426baf6

Method 2 : Using systool
Another useful command to find the information about HBAs is systool. If not already install, you may need to install the sysfsutils package.

# yum install sysfsutils

To check the available HBA ports :

# systool -c fc_host
Class = "fc_host"

  Class Device = "host2"
    Device = "host2"

  Class Device = "host3"
    Device = "host3"

To find the WWNs for the HBA ports :

# systool -c fc_host -v | grep port_name
    port_name           = "0x500143802426baf4"
    port_name           = "0x500143802426baf6"

To check the state of the HBA ports (online/offline) :

# systool -c fc_host -v | grep port_state
    port_state          = "Online"
    port_state          = "Online"

Восстановление MySQL репликации

Источник

# Остановить работу slave

mysql> stop slave;

# заставить slave забыть позицию его репликации в файле лога master'а
mysql> reset slave;

# Заставить slave читать начиная с той позиции на которой остановился


mysql> change master to master_log_file='mysql-bin.000048', master_log_pos=283932126;

# Запустить slave

mysql> start slave;

How To resolve “Database Mail is stopped” error

Source

You try to send Test mail from Database mail but it throws below message-
Msg 14641, Sev 16, State 1, Line 81 : Mail not queued. Database Mail is stopped. Use sysmail_start_sp to start Database Mail. [SQLSTATE 42000]
1. To investigate this issue, firstly confirm whether Database Mail is enabled or not by executing below queries in SQL Server Management Studio-

       sp_configure 'show advanced', 1; 
       GO
       RECONFIGURE;
       GO
       sp_configure;
       GO

If the resultset show run_value as 1 then Database Mail is enabled.
2. If the Database Mail option is disabled then run the below queries to enable it-

       sp_configure 'Database Mail XPs', 1; 
       GO
       RECONFIGURE;
       GO

       sp_configure 'show advanced', 0; 
       GO
       RECONFIGURE;
       GO

3. Once the Database Mail is enabled then start it using below query on msdb database-

       USE msdb ;       
       EXEC msdb.dbo.sysmail_start_sp;

4. To confirm that Database Mail External Program is started, run the below query-

       EXEC msdb.dbo.sysmail_help_status_sp;

5. If the Database Mail external program is started then check the status of mail queue using below statement-

       EXEC msdb.dbo.sysmail_help_queue_sp @queue_type = 'mail';

For more details please check the link http://technet.microsoft.com/en-us/library/ms187540.aspx

Create a read only account

Script to Create Read-Only user:

CREATE ROLE Read_Only_User WITH LOGIN PASSWORD 'Test1234' 
NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION VALID UNTIL 'infinity';

Assign permission to this read only user:

GRANT CONNECT ON DATABASE YourDatabaseName TO Read_Only_User;
GRANT USAGE ON SCHEMA public TO Read_Only_User;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO Read_Only_User;
GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO Read_Only_User;

Create super user and database user in Mongo 2.6

source

# Create your superuser

$ mongo

> use admin

> db.createUser({user:"someadmin",pwd:"secret", roles:[{role:"root",db:"admin"}]})

> exit

# Alias for convenience (optional and at your own risk)

$ echo 'alias mongo="mongo --port 27017 -u someadmin -p secret --authenticationDatabase admin"' >> ~/.bash_profile

$ source ~/.bash_profile

# Add user to your DB

$ mongo

> use some_db

> db.createUser(

{

user: "mongouser",

pwd: "someothersecret",

roles: ["readWrite"]

}

)

# If you get locked out, start over

sudo service mongod stop

sudo mv /data/admin.* . # for backup

sudo service mongod start

Шпаргалка по deadlock в MSSQL

Источник

Включить трассировку

DBCC TRACEON (1222,-1)

1	DBCC TRACEON (1222,-1)

-1 = сбор информации изо всех сессий.
Проверить трассировку

DBCC TRACESTATUS (-1)

1	DBCC TRACESTATUS (-1)

или

DBCC TRACEON(1204) DBCC TRACEON(3604) DBCC TRACEON(3605)

1 2 3

DBCC TRACEON(1204) DBCC TRACEON(3604) DBCC TRACEON(3605)

логи о дедлоках будут писаться в errorlog сервера
Рекомендации:
1.Перед включением трассировки настроить сохранение логов сервера, скажем, не 6, а 24 и более. Это делается в EM, Management / SQL Server logs / Right mouse click / Configure / [X] Limit… Maximem number of поставить, скажем, в 30.
2.Настроить на планировщике ежедневный вызов sp_cycle_errorlog — эта процедура вызывает сброс текущего лога.
После того, как будут пойманы 1 — 2 — 3 дедлока выключить трассировку:

DBCC TRACEOFF(1204) DBCC TRACEOFF(3604) DBCC TRACEOFF(3605)

1 2 3

DBCC TRACEOFF(1204) DBCC TRACEOFF(3604) DBCC TRACEOFF(3605)

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

• 1204 – сбор расширенной информации о взаимоблокировке.
• 3605 – выдача информации в EventLog.
• 3406 – выдача информации в файл errorlog.
• 1206 – сбор информации не только о блокировках, участвующих во тупиковой ситуации (что делает флаг 1204), но и об остальных блокировках, наложенных заблокированными транзакциями.
• 1200 – сбор информации о порядке наложения блокировок (недокументированный).

Сейчас нас интересует флаг под номером 1204 – выдача расширенной информации о взаимоблокировке, получить же информацию при выставленном флаге можно двумя способами.
1. Запустить SQL Profiler, специальную программу для отслеживания работы сервера, и настроить в ней перехват ошибок (event class Errors and Warnings: Exception and Error Log), а затем выставить флаг трассировки 3605. В этом случае вся дополнительная информация о работе SQL-сервера будет сбрасываться в Event Log и перехватываться профайлером, где ее в последствии можно будет посмотреть.
2. Выставить флаг отладки 3406. В этом случае вся дополнительная информация будет сбрасываться в файл errorlog, который по умолчанию находится в каталоге LOG директории SQL сервера.
PAG: 7:1:845557
DBCC PAGE ({dbid | dbname}, filenum, pagenum[, printopt]) в результатах вывода которой можно увидеть object_id (а по нему уже и мя объекта получить)
Полезные ссылки
http://www.sql.ru/articles/mssql/2007/011005DeadlockTroubleshootingPart1.shtml
http://rsdn.ru/article/db/deadlocks.xml

Оптимизируем базу на MSSQL: определяем фрагментацию индексов

Источник

Основным инструментом в процессе управления фрагментацией индексов выступает функция sys.dm_db_index_physical_stats (подробнее)
Для определения списка индексов с уровнем фрагментарности выше оптимальных 10% :

DECLARE @db_name varchar(50) = N'db_name',
                @table_name varchar(250) = N'db_name.dbo.tbl_name'

SELECT  IndStat.database_id,
                IndStat.object_id,
                QUOTENAME(s.name) + '.' + QUOTENAME(o.name) AS [object_name],
                IndStat.index_id,
                QUOTENAME(i.name) AS index_name,
                IndStat.avg_fragmentation_in_percent,
                IndStat.partition_number,
                (SELECT count (*) FROM sys.partitions p
                        WHERE p.object_id = IndStat.object_id AND p.index_id = IndStat.index_id) AS partition_count
FROM sys.dm_db_index_physical_stats
    (DB_ID(@db_name), OBJECT_ID(@table_name), NULL, NULL , 'LIMITED') AS IndStat
        INNER JOIN sys.objects AS o ON (IndStat.object_id = o.object_id)
        INNER JOIN sys.schemas AS s ON s.schema_id = o.schema_id
        INNER JOIN sys.indexes i ON (i.object_id = IndStat.object_id AND i.index_id = IndStat.index_id)
WHERE IndStat.avg_fragmentation_in_percent > 10 AND IndStat.index_id > 0

Если указать @table_name = NULL, тогда мы получим данные по всем таблицам указанной базы.
Если указать и @db_name = NULL - получим информацию по всем таблицам всех баз. Естественно, для выполнения этого запроса нужно обладать некоторыми правами:

• CONTROL на специфический объект БД.
• VIEW DATABASE STATE для получения информации обо всех объектах определенной БД (@object_id = NULL).
• VIEW SERVER STATE - для получения информации обо всех базах сервера (@database_id = NULL).
• 
  

Так же перед использованием желательно обновить статистику БД.
Вышеприведенный запрос дает только справочную информацию. Но на основании функции sys.dm_db_index_physical_stats можно построить скрипт или хранимую процедуру, которая будет не только определять список индексов, нуждающихся в перестройке, но и будет сама проводить эту операцию.
Один из вариантов такого скрипта приведен ниже (проводит реорганизацию или перестройку(оффлайн) индексов таблиц текущей базы в зависимости от степени фрагментации):

USE [DATABASE];
GO

SET NOCOUNT ON;
DECLARE @objectid int;
DECLARE @indexid int;
DECLARE @partitioncount bigint;
DECLARE @schemaname nvarchar(130);
DECLARE @objectname nvarchar(130);
DECLARE @indexname nvarchar(130);
DECLARE @partitionnum bigint;
DECLARE @partitions bigint;
DECLARE @frag float;
DECLARE @command nvarchar(4000);
DECLARE @dbid smallint;

-- Выбираем индексы с уровнем фрагментации выше 10%
-- Определяем текущую БД

SET @dbid = DB_ID();
SELECT
    [object_id] AS objectid,
    index_id AS indexid,
    partition_number AS partitionnum,
    avg_fragmentation_in_percent AS frag, page_count
INTO #work_to_do
FROM sys.dm_db_index_physical_stats (@dbid, NULL, NULL , NULL, N'LIMITED')
WHERE avg_fragmentation_in_percent > 10.0
AND index_id > 0 -- игнорируем heap
AND page_count > 25; -- игнорируем маленькие таблицы

-- объявляем курсор для списка обрабатываемых partition
DECLARE partitions CURSOR FOR SELECT objectid,indexid, partitionnum,frag FROM #work_to_do;

OPEN partitions;

-- цикл по partition
WHILE (1=1)
BEGIN
FETCH NEXT
FROM partitions
INTO @objectid, @indexid, @partitionnum, @frag;
IF @@FETCH_STATUS < 0 BREAK;
SELECT @objectname = QUOTENAME(o.name), @schemaname = QUOTENAME(s.name)
FROM sys.objects AS o
JOIN sys.schemas AS s ON s.schema_id = o.schema_id
WHERE o.object_id = @objectid;

SELECT @indexname = QUOTENAME(name)
FROM sys.indexes
WHERE object_id = @objectid AND index_id = @indexid;
SELECT @partitioncount = count (*)
FROM sys.partitions
WHERE object_id = @objectid AND index_id = @indexid;

-- 30% считаем пределом для определения типа обновления индекса.
IF @frag < 30.0
    SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REORGANIZE';
IF @frag >= 30.0
    SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD';
IF @partitioncount > 1
    SET @command = @command + N' PARTITION=' + CAST(@partitionnum AS nvarchar(10));

EXEC (@command);
PRINT N'Выполнено: ' + @command;
END;

CLOSE partitions;
DEALLOCATE partitions;

-- удаляем временную таблицу
DROP TABLE #work_to_do;
GO

Еще посмотреть примеры скриптов/хранимок можно тут или вот тут.

Windows и сброс прав доступа и владельца файлов

Источник

icacls.exe "E:\Inaccessible Folder" /reset /T

Вместо E:\Inaccessible Folder следует указать путь к каталогу, где необходимо сбросить старые разрешения.
В отдельных случаях перед запуском icacls может потребоваться утилита takeown:

takeown.exe /f "E:\" /r /d y
icacls.exe "E:\" /reset /T

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

Замена контроллера домена. Перенос контроллера домена на новый компьютер.

Источник, спасибо автору.


UPD: Микрософт традиционно меняет привычный синаксис в командной строке, поэтому роли в кажлый версии Windows Server могут звучать по-разному. Они вообще теперь не fsmo называются а operation masters. Так вот, для корректных команд в консоли после fsmo maintenance напишите просто ? и он вам покажет доступные команды.

Подготовка серверов к повышению/понижению роли

Сама процедура создания резервного контроллера домена элементарна – мы просто запускаем на любом сервере сети мастер dcpromo. При помощи мастера dcpromo создаём контроллер домена в существующем домене. В результате проделанных манипуляций мы получаем развернутую службу каталогов AD на нашем дополнительном сервере (я буду называть его pserver, а основной контроллер - dcserver).
Дальше, если dcpromo сам не предложил – запускаем установку DNS сервера. Никаких настроек изменять не надо, зону создавать также не надо – она хранится в AD, и все записи автоматически реплицируются на резервный контроллер. Внимание – основная зона в DNS появится только после репликации, для ускорения которой сервер можно перезагрузить. В настройках TCP/IP сетевой карты резервного контроллера домена адресом первичного DNS сервера должен быть указан ip-адрес основного контроллер домена.
Теперь можно легко проверить работоспособность резервного контроллера домена pserver. Мы можем создать пользователя домена как на основном так и на резервном контроллере домена. Сразу после создания он появляется на дублирующем сервере, но где-то в течении минуты (пока происходит репликация) – он показан как отключенный, после чего начинает отображаться одинаково на обоих контроллерах.
На первый взгляд все действия по созданию исправной схемы взаимодействия нескольких контроллеров домена выполнены, и теперь, в случае выхода из строя «основного» контроллера домена, «резервные» контроллеры будут автоматически выполнять его функции. Однако, хотя разница между «основным» и «резервным» контроллерами домена чисто номинальная, «основной» контроллер домена имеет ряд особенностей (роли FSMO), о которых не стоит забывать. Таким образом, вышеприведенных операций для нормального функционирования службы каталогов при отказе «основного» контроллера домена не достаточно, и действия, которые надо произвести для грамотной передачи/захвата роли основного контроллера домена будут описаны ниже.

Немного теории

Нужно знать, что контроллеры домена Active Directory исполняют несколько видов ролей. Эти роли называются FSMO (Flexible single-master operations):
- Schema Master (Хозяин схемы) – роль отвечает за возможность изменения схемы – например разворачивания Exchange server или ISA server. Если владелец роли будет недоступен – схему существующего домена вы изменить не сможете;
- Domain Naming Master (Хозяин операции именования доменов) – роль необходима в том случае, если в вашем доменном лесу есть несколько доменов или поддоменов. Без неё не получится создавать и удалять домены в едином доменном лесу;
- Relative ID Master (Хозяин относительных идентификаторов) – отвечает за создание уникального ID для каждого объекта AD;
- Primary Domain Controller Emulator (Эмулятор основного контроллера домена) – именно он отвечает за работу с учётными записями пользователей и политику безопасности. Отсутствие связи с ним позволяет входить на рабочие станции со старым паролем, который нельзя сменить, если контроллер домена «упал»;
- Infrastructure Master (Хозяин Инфраструктуры) – роль отвечает за передачу информации об объектах AD прочим контроллерам домена в рамках всего леса.
Об этих ролях достаточно подробно написано во многих базах знаний, но основную роль практически всегда забывают – это роль Global Catalog (Глобального Каталога). По факту этот каталог просто запускает LDAP сервис на порту 3268, но именно его недоступность не позволит доменным пользователям входить в систему. Что примечательно – роль глобального каталога могут иметь все контроллеры домена одновременно.

Фактически можно сделать вывод – если у вас примитивный домен на 30-50 машин, без расширенной инфраструктуры, не включающий в себя поддомены - то отсутствие доступа к владельцу/владельцам первых двух ролей вы можете не заметить. Кроме того, мне несколько раз попадались организации, работающие больше года вообще без контроллера домена, но в доменной инфраструктуре. То есть все права были розданы давно, при работающем контроллере домена, и не нуждались в изменении, пароли пользователи себе не меняли и спокойно работали.


Определение текущих владельцев ролей fsmo.

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

dsquery server –hasfsmo schema
dsquery server – hasfsmo name
dsquery server – hasfsmo rid
dsquery server – hasfsmo pdc
dsquery server – hasfsmo infr
dsquery server –forest -isgc

Каждая из команд выводит нам информацию о том, кто является владельцем запрашиваемой роли (рис.1). В нашем случае владелец всех ролей – основной контроллер домена dcserver.


Добровольная передача ролей fsmo при помощи консолей Active Directory.

Вся информация, необходимая для передачи роли основного контроллера домена у нас есть. Приступаем: для начала нужно убедиться в том, что наша учётная запись входит в группы «Администраторы домена», «Администраторы схемы» и «Администраторы предприятия», а затем приступить к традиционному методу передачи ролей fsmo – управлением доменом через консоли Active Directory.

Для передачи роли “хозяина именования домена” выполняем следующие шаги:
- открываем «Active Directory Домены и Доверие» на том контроллере домена, с которого мы хотим передать роль. Если мы работаем с AD на том контроллере домена, которому мы хотим передать роль, то следующий пункт пропускаем;
- щёлкаем правой кнопкой мыши на значке Active Directory — домены и доверие и выбираем команду Подключение к контроллеру домена. Выбираем тот контроллер домена, которому хотим передать роль;
- щелкаем правой кнопкой мыши компонент Active Directory — домены и доверие и выбираем команду Хозяева операций;
- в диалоговом окне Изменение хозяина операций нажимаем кнопку Изменить (рис. 2).
- после утвердительного ответа на всплывающий запрос получаем успешно переданную роль.

Аналогичным образом, при помощи консоли «Active Directory — пользователи и компьютеры» можно передать роли «хозяин RID», «основной контроллер домена» и «хозяин инфраструктуры».

Для передачи роли «хозяина схемы» необходимо предварительно зарегистрировать в системе библиотеку управления схемой Active Directory:

regsvr32 schmmgmt.dll

Далее в консоль mmc необходимо добавить оснастку «Схема Active Directory», в которой, аналогично предыдущим пунктам, можно изменить владельца роли.

После того как все роли переданы остаётся разобраться с оставшейся опцией – хранителем глобального каталога. Заходим в Active Directory: «Сайты и Службы», сайт по умолчанию, сервера, находим контроллер домена, ставший основным, и в свойствах его NTDS settings ставим галочку напротив global catalog. (рис. 3)

Итог – мы поменяли хозяев ролей для нашего домена. Кому нужно окончательно избавиться от старого контроллера домена – понижаем его до рядового сервера. Однако простота проделанных действий окупается тем, что их выполнение в ряде ситуаций невозможно, или оканчивается ошибкой. В этих случаях нам поможет ntdsutil.exe.


Добровольная передача ролей fsmo при помощи консолей ntdsutil.exe.

На случай, если передача ролей fsmo при помощи консолей AD не удалась, Microsoft создал очень удобную утилиту – ntdsutil.exe – программа обслуживания каталога Active Directory. Этот инструмент позволяет выполнять чрезвычайно полезные действия – вплоть до восстановления всей базы данных AD из резервной копии, которую эта утилита сама создала во время последнего изменения в AD. Со всеми её возможностями можно ознакомиться в базе знаний Microsoft (Код статьи: 255504). В данном случае мы говорим о том, что утилита ntdsutil.exe позволяет как передавать роли, так и «отбирать» их.
Если мы хотим передать роль от существующего «основного» контроллера домена к «резервному» – мы заходим в систему на «основной» контроллер и начинаем передавать роли (команда transfer).
Если у нас по каким-то причинам отсутствует основной контролер домена, или мы не можем войти под административной учетной записью – мы входим в систему на резервный контроллер домена и начинаем «отбирать» роли (команда seize).

Итак первый случай – основной контроллер домена существует и функционирует нормально. Тогда мы заходим на основной контроллер домена и набираем следующие команды:

ntdsutil.exe
roles
connections
connect to server имя_сервера (того кому хотим отдать роль)
q

Если выскакивают ошибки – нужно проверить связь с тем контроллером домена, к которому мы пытаемся подключиться. Если ошибок нет – значит мы успешно подключились к указанному контроллеру домена с правами того пользователя, от имени которого вводим команды.
Полный список команд доступен после запроса fsmo maintenance стандартным знаком ? . Пришла пора передавать роли. Я сходу, не задумываясь, решил передавать роли в том порядке, в каком они указаны в инструкции к ntdsutil и пришёл к тому, что не смог передать роль хозяина инфраструктуры. Мне, в ответ на запрос о передаче роли, возвращалась ошибка: «невозможно связаться с текущим владельцем роли fsmo». Я долго искал информацию в сети и обнаружил, что большинство людей дошедших до этапа передачи ролей сталкиваются с этой ошибкой. Часть из них пытается отобрать эту роль принудительно (не выходит), часть оставляет всё как есть – и благополучно живёт без этой роли.
Я же путём проб и ошибок выяснил, что при передаче ролей в данном порядке гарантируется корректное завершение всех шагов:
- хозяин идентификаторов;
- хозяин схемы;
- хозяин именования;
- хозяин инфраструктуры;
- контроллер домена;

После успешного подключения к серверу мы получаем приглашение к управлению ролями (fsmo maintenance), и можем начать передавать роли :
- transfer domain naming master
- transfer infrastructure master
- transfer rid master
- transfer schema master
- transfer pdc master

После выполнения каждой команды должен выходить запрос о том – действительно ли мы хотим передать указанную роль указанному серверу. Результат удачного выполнения команды показан на рис.4.

Роль хранителя глобального каталога передаётся способом, описанным в предыдущем разделе.


Принудительное присваивание ролей fsmo при помощи ntdsutil.exe.

Второй случай – мы хотим присвоить нашему резервному контроллеру домена роль основного. В этом случае ничего не меняется – единственная разница в том, что мы проводим все операции, с использованием команды seize, но уже на том сервере, которому хотим передать роли для присвоения роли.

seize domain naming master
seize infrastructure master
seize rid master
seize schema master
seize pdc

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


Работа над ошибками.

Самое главное, о чём не следует забывать – новый основной контроллер домена сам себе настройки TCP/IP не исправит: ему адресом первичного DNS сервера теперь желательно (а если старый контроллер домена + DNS сервер будут отсутствовать, то обязательно) указать 127.0.0.1 .
При этом если у вас в сети есть DHCP сервер, то нужно заставить его выдавать адресом первичного DNS сервера ip вашего нового сервера, если DHCP нет – пройтись по всем машинам и прописать им этот первичный DNS вручную. Как вариант, можно назначить новому контроллеру домена тот же ip что был у старого.

Теперь необходимо проверить как всё работает и избавиться от основных ошибок. Для этого я предлагаю на обоих контроллерах стереть все события с сохранением журналов в папку с прочими резервными копиями и перезагрузить все сервера.
После их включения внимательно анализируем все журналы событий на факт появления предупреждений и ошибок.

Самым распространённым предупреждением, после передачи ролей fsmo, является сообщение о том, что «msdtc не может корректно обработать произошедшее повышение/понижение роли контроллера домена».
Исправляется просто: в меню «Администрирование» находим «Службы
компонентов». Там раскрываем «Службы компонентов», «Компьютеры», открываем свойства раздела "Мой компьютер", ищем там "MS DTC" и жмем там "Настройки безопасности". Там разрешаем "Доступ к сети DTC" и давим ОК. Служба будет перезапущена и предупреждение исчезнет.

Примером ошибки может служить сообщение о том, что основная DNS зона не может быть загружена, либо DNS сервер не видит контроллер домена.
Разобраться в проблемах функционирования домена можно при помощи утилиты (рис. 5):

dcdiag

Установить эту утилиту можно с оригинального диска Windows 2003 из папки /support/tools. Утилита позволяет проверить работоспособность всех служб контроллера домена, каждый её этап должен оканчиваться словами successfully passed. Если у вас выходит failed (чаще всего это тесты connection или systemlog) то ошибку можно попробовать вылечить в автоматическом режиме:

dcdiag /v /fix

Как правило, все ошибки, связанные с DNS должны пропасть. Если нет – пользуемся утилитой проверки состояния всех сетевых служб:

netdiag

И её полезным инструментом устранения ошибок:

netdiag /v /fix

Если и после этого остаются ошибки связанные с DNS – проще всего удалить из него все зоны и создать вручную. Это довольно просто – главное создать основную зону по имени домена, хранящуюся в Active Directory и реплицируемую на все контроллеры домена в сети.
Более подробную информацию об ошибках DNS даст ещё одна команда:

dcdiag /test:dns

По окончанию проделанных работ у меня ушло ещё где-то 30 минут на выяснение причины появления ряда предупреждений – я разобрался с синхронизацией времени, архивацией глобального каталога и прочими вещами, до которых раньше не доходили руки. Теперь всё работает как часы – самое главное не забудьте завести резервный контроллер домена, если вы хотите удалить старый контроллер домена из сети.




Указанные ресурсы:

[1] http://technet.microsoft.com
[2] http://www.petri.co.il/
[3] http://support.microsoft.com

Упал контроллер домена — Практикум по устранению неполадок.

Источник, спасибо автору.

В данной статье описана последовательность действий системного администратора в случае выхода из строя одного из контроллеров домена. Однако необходимо учесть специфику подачи материала — предлагается сначала поднять домен с двумя контроллерам, а потом  «вручную» переустановить винду на одном из контроллеров. Итак цитирую прямо из учебного руководства:
Вы — сетевой администратор в компании Contoso Pharmaceuticals. Вследствие недавнего аппаратного сбоя вышел из строя один из контроллеров домена — Server2. Ремонт контроллера не представляется возможным, а свежей копии нет. Одновременно в журнале службы каталогов в утутите Просмотр событий (Event Viewer) на другом контроллере регистрируется множество ошибок репликации. Ваша задача — установить новый сервер взамен Server2. Попытка настроить новый контроллер домена под именем Server2 не приносит успеха — появляется сообщение о том, что Server2 уже существует. Эту проблему вам предстоит разрешить.
Для начала настройте Server2 в роли контроллера домена. Затем, допустив, что на сервере Server2  произошла неисправимая ошибка, переустановите на нем операционную систему, но не понижайте его статус до рядового сервера.

1. Установите на сервере Server2 службу Active Directory. Сделать это можно вручную или с помощью файла ответов. Чтобы провести установку с привлечением файла ответов, запустите команду dcpromo /answer:d:\answerdc2.txt (путь и имя файла ответов измените на своё).
2. Обеспечте возможность завершения установки  Active Directory на Server2. Теперь с помощью установочного диска Windows 2003 Enterprise Server вам предстоит переустановить Server2. При этом можно обратиться к файлу необслуживаемой установки.
3. Теперь поместите в дисковод установочный диск и дискету в флоппик (если используете файл необслуживаемой установки Winnt.sif). Если не используете файл отвтеов, то переходите к ручной установке, в ходе которой вам предстоит выставить  подходящие в условиях вашей сети настройки.
   

   ---

   Примечание: Вне зависимости от  выбранного метода, завершать установку Server2 пока не нужно. Вы должны запустить процесс, дойти до этапа ввода ключа продукта, а затем перейти к решению задач, касающихся Server1 (именно на это направленны следующие шаги). Перед повторным присоединением к домену нужно будет удалить из Active Directory все без исключения  ссылки на Server2.

   ---

4. Зарегистрируйтесь на Server1, указав имя ил пароль администратора домена.
5. Откройте командную строку. Введите ntdsutil и нажмите ввод. На экране появится коммандная строка утилиты Ntdsutil.
6. Введите metadata cleanup и нажмите Энтер. Появится приглашение на очистку метаданных.
7. Введите connections и нажмите ввод. В результате будет выведено приглашение на подключение к серверу.
8. Введите connect to server server1 и нажмите ввод (вместо server1 в вашем случае может быть другое имя исправного контроллера домена).
9. Введите quit и нажмите ввод. Вновь появится приглашение на очистку метаданных.
10. Введите select operation target.
11. Введите list domains. В выведенном списке должен присутствовать всего один домен под нулевым номером (0). В противном случае запомните, каким объектом и числом представлен домен contoso.com (или ваш домен), и во время выполнения следующего действия введите это число.
12. Введите select domain 0 (или ваше число, см. пп.11) и нажмите ввод.
13. Введите list sites и нажмите ввод. В списке должен быть только один сайт под нулевым номером. В противном случае запомните номер и объект, которым представлен ваш сайт, и при выполнении следующего шага введите это число.
14. Введите select site 0 и нажмите ввод.
15. Введите list servers in sites и нажмите ввод. Серверов в списке должно быть два. Запомните, каким числом представлен сервер Server2 — скорее всего, единицей (1). В противном случае во время выполнения следующего шага вам придется заменить единицу (1) фактическим числом Server2 (вышедшего из строя контроллера домена).
16. Введите select server 1 (или другой номер) и нажмите ввод.
17. Введите quit и нажмите ввод.  В результате на экране в очередной раз появится приглашение на очистку метаданных.
18. Введите  remove selected server и нажмите клавишу ввод. При появлении следующего приглашения вы должны тщательно  ознакомиться с его содержанием и подтвердить свое намеренье удалить Server2. Щелкните Да.
19. Введите quit и дважды нажмите ввод. В результате  приглашения на очистку метаданных и ввод команд утилиты Ntdsutil будут закрыты. Чтобы закрыть командную строку, введите quit еще раз.
20. Итак вы удалили объект параметров NTDS. Тем не менее, свидетельства существования Server2 в базе данных еще остаются. Удалить их можно  с помощью консоли DNS и редактора ADSIEdit.
21. Откройте консоль DNS. Последовательно раскрывая элементы иерархической структуры, найдите объект домена contoso.com (или вашего домена) и щелкните на нем.
22. В правой секции окна найдите запись хоста (А; она должна совпадать с родительской папкой) с IP-адресом сервера Server2. Щелкнув на ней правой кнопкой мыши, выберите пункт Удалить. При появлении окна подтверждения  щелкните кнопку ДА.
23. В той же секции окна щелкните левой кнопкой на записи хоста Server2 и выберите пункт Удалить. Нажатием кнопки ДА подтвердите  намерение удалить запись. Теперь запись DNS, соответствующая серверу Server2, удалена. Закройте консоль DNS.
24. Выберите Пуск\Выполнить, введите ADSIEdit.msc и нажмите клавишу ввод. На экране появится консоль ADSIEdit.
25. Раскройте структуру Domain\DC=contoso,DC=com\OU=Domain Controllers. Щелкнув на записи объекта CN=Server2, нажмите клавишу Delete. В окне подтверждения щелкните ДА. Таким образом, объекта Server2 в контексте именования домена на Active Directory больше нет.
26. Раскройте структуру Configuration\CN=Configuration,DC=contoso, DC=com\CN=Sites\CN=Default-First-Site-Name\CN=Servers. Щелкнув на записи объекта  CN=Server2, нажмите Delete. В окне подтверждение нажмите ДА. Теперь в контексте именования для конфигураций нет объекта Server2. Закройте консоль ADSIEdit.

Итак, вы удалили с домена Active Directory, размещенного на сервере Server1, все ссылки на Server2. Именно так следует  чистить Active Directory после потери любого контроллера домена. Теперь нужно завершить установку Server2, а в последвствии — присоединить его в качестве рядового домена или контроллера домена  к своему домену.

How to drop a PostgreSQL database if there are active connections to it?

SELECT pg_terminate_backend(pg_stat_activity.pid)
FROM pg_stat_activity
WHERE pg_stat_activity.datname = 'TARGET_DB' -- ← change this to your DB
  AND pid <> pg_backend_pid();

Включаем Overlay2 в Docker для CentOS 6 и 7

Источник, спасибо автору.

Docker взаимодействует с файловой системой хост-машины через определенный драйвер. Попробуем переключиться на overlay2.
Для Ubuntu систем это aufs, что в целом достаточно хорошо по производительности. Но вот для систем основанных на RHEL это devicemapper в режиме loop, производительность которого подойдет для тестовых манипуляций, но для полноценного использования уже будет существенно проигрывать.
Выход? Переключить драйвер на что-то более приемлемое. Например overlay, а еще лучше overlay2. Последний вариант доступен только в Docker начиная с версии 1.12+. Обязательное условие для активации overlay(2) это kernel версии 4+.
Переходим к действиям.
Добавляем репозиторий (для CentOS7):

rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm

Добавляем репозиторий (для CentOS6):

rpm -Uvh http://www.elrepo.org/elrepo-release-6-6.el6.elrepo.noarch.rpm

Обновляем ядро:

yum --enablerepo=elrepo-kernel install kernel-ml

Выставляем загрузку со свежеустановленного ядра:

grub2-set-default 0

В /etc/systemd/system/multi-user.target.wants/docker.service для строки ExecStart= добавляем параметр --storage-driver=overlay2
Чтобы получилось примерно так:

ExecStart=/usr/bin/docker daemon -H fd:// --storage-driver=overlay2

Теперь можно делать reboot, система загрузит новое ядро, а docker info покажет что используется overlay2.
Основано на https://adminswerk.de/overlayfs-docker-storage-driver-centos-7/

Linux Изменение системных меню (desktop-файлы)

Источник, спасибо автору

Немного раскрою тему создания и редактирования пунктов системного меню.
Проще всего, конечно, использовать для этого стандартные графические утилиты. Например, подобная в среде Gnome называется alacarte, запускается такой же командой или из меню по пункту Главное меню из раздела Параметры.

В KDE есть аналогичная по функционалу программа — kmenuedit.Но могут возникнуть ситуации, где использование подобных инструментов будет невозможно. Например, лично я столкнулась с этой проблемой, когда установила среду LXDE. В ней есть панель (lxpanel) с меню. И в идеале меню там формируется автоматически на основе списка установленных программ, но в моём случае, видимо, что-то пошло не так, и в имевшемся меню не хватало приличного количества пунктов. А графической утилиты для редактирования не предоставляется, более того: почти везде написано, что мол меню само формируется и все установленные программы будут помещены в него. Но ведь оно формируется на основе чего-то, а следовательно, это что-то должно быть можно править как-то напрямую и таким образом влиять на это самое меню.
В ходе подобных изысканий, натолкнулась на информацию о desktop-файлах. Собственно, они-то мне и оказались нужны и именно на их основе в lxde и других средах формируется меню.
Полный охват вопроса не гарантирую, посколько только начала ковырять эту тему, но самые основы тут изложу.
Итак, системное меню формируется на основе всех существующих desktop-файлов. Как несложно догадаться, это файлы с расширением *.desktop.
Лежат все эти файлы в директории /usr/share/applications/. Появлется такой файл там при установке соответствующей программы. Варианты для определённого пользователя хранятся внутри его домашней директории по адресу ~/.local/share/applications/.
Соответственно, прежде всего используются файлы из домашней директории, а всё остальное из общей. И если нужно что-то исправить, то лучше всего это делать именно в файлах из домашней папки.
Хотя тут зависит и от задачи. Может понадобиться, например, создать пункт меню для всех пользователей системы. Тогда, конечно, надо работать с общей папкой с правами суперпользователя. Но нужно учитывать, что файлы из домашней директории точно не будут затронуты при обновлениях, а вот насчёт директории /usr/share/ я не поручусь.
Проще всего понять, как работать с desktop-файлами, просто посмотрев содержание одного из них. Щелчком на таком файле в файловом менеджере не всегда получится его открыть — у меня из наутилуса заупускается соответствующая программа (на которую ссылается сам файл) и через контекстное меню выбрать нужную программу для открытия тоже нельзя, но файл открывается из текстового редактора (через меню «Открыть») или из консоли.
Вот, например, содержание файла baobab.desktop:

[Desktop Entry] Encoding=UTF-8 Type=Application Name=Disk Usage Analyzer Comment=Check folder sizes and available disk space Exec=baobab Icon=baobab Terminal=false Categories=GTK;GNOME;Utility; NotShowIn=KDE;

Строки не обязательно должны быть только эти и не обязательно все эти, но для начала сгодятся. Все строки, кроме первой, имеют вид Ключ=Значение. Соответственно количество возможных ключей ограничено и они описаны спецификацией. А значения могут быть различными, общие требования — в них не должны использоваться зарезервированные символы ;, #, \, а если используются, то должны быть экранированы символом \. Значений у одного ключа может быть несколько и они должны быть разделены точкой с запятой. Игнорируются пустые строки и начинающиеся с решётки (закомментированные). Порядок строк может быть любым, кроме первой, которая всегда должна быть первой.
Теперь разберём по строкам:

• [Desktop Entry] — такая строка должна быть в начале любого desktop-файла по спецификации формата
• Encoding= — указывает кодировку файла; практически всегда это UTF-8
• Type= — тип пункта, описываемого файлом; почти всегда это Application — приложение, но может быть ещё Link или Directory (ссылка или директория)
• Name= —
— название приложение, которое будет отображаться в меню, если не настроена локализация интерфейса или не указано при этом название на языке локализации

• Comment= — описание пункта (появляется, например, при наведении на пункт меню в Gnome)
• Exeс= — команда запуска приложения; пишется либо полный пусть к исполняемому файлу, либо просто название — тогда файл с таким названием система сама будет искать по путям, указанным в системной переменной PATH (обычно туда входят, например, /bin/ и /usr/bin/)
• Icon= — иконка приложения; можно указывать или полный путь к файлу иконки, или просто название — тогда иконка будет браться из текущей темы иконок системы, если такая там есть (темы лежат в /usr/share/icons/ или в ~/.icons/)
• Terminal= — задаёт, будет ли приложение запускаться в терминале или нет; в данном случае приложение не консольное, поэтому значение false, иначе было бы true
• Categories= — группа в меню, где будет находится приложение; в данном примере — группа Utility (в русском варианте интерфейса — Стандартные), остальные группы имеют отношение к создаваемым меню в различных средах, отличных от Gnome (подробно рассматривать эту тему слишком долго)
• NotShowIn= — определяет, в каких средах данного пункта меню не будет видно; в данном случае анализатор диска — стандартная утилита Gnome, поэтому её не видно в KDE, что, впрочем, можно исправить как раз редактированием этого desktop-файла

Другие возможные строки:

• Name[ru]= — название приложения на русском языке (понятно, что для других языков ключ выглядит похоже, но с другими значениями в квадратных скобках)
• Comment[ru]= — то же самое, что выше, только для описания пункта меню
• NoDisplay= — если значение true, пукт меню будет скрыт
• Hidden= — если значение true, пукт меню будет скрыт и невозможно будет открыть этим приложением какой-либо файл из файлового менеджера
• OnlyShowIn= — при использовании нескольких сред, определяет в какой среде исключительно будет видно данный пункт в меню

Есть и ещё несколько ключей, о которых можно прочитать в спецификации данного формата.
Для начала, я воспользовалась данной информацией, чтобы поместить значок запуска программы ДубльГис в системное меню гнома. Программа идёт под вайном и сама ярлык не создаёт, поэтому нужно создать файл ~/.local/share/applications/2gis.desktop следующего содержания:

[Desktop Entry] Encoding=UTF-8 Type=Application Categories= Exec="/home/opossum/.wine/drive_c/Program Files/2gis/3.0/grym.exe" Icon="/home/opossum/.icons/2gis" Terminal=false Name=2gis Name[ru]=ДубльГис

Если категория не определена, как тут, то приложение будет помещено в подпункт меню «Прочие». Иконка, естественно, должна быть помещена по тому пути, что прописан в файле.
Ещё, пожалуй, стоит сказать о строке запуска. В значении ключа Exec после команды запуска программы могут находиться некоторые аргументы. Впервые я с ними столкнулась, когда просто редактировала пункты меню Gnome через программу alacarte и никто не смог ответить, что же это такое. Поиск тогда тоже результата не дал, а сейчас как-то нашлось само.
Так вот эти аргументы имеют отношение больше не к пункту, отображаемому в меню, а к контекстному меню файлового менеджера.

• %f — один файл
• %F — список файлов
• %u — одна ссылка (URL)
• %U — список ссылок

То есть из контекстного меню файлового менеджера можно будет открыть только один файл какой-либо программой, если в строке Exec её desktop-файла проставлен аргумент %f, и можно будет открыть сразу несколько файлов (если программа это позволяет), выделив их и выбрав соответствующий пункт контекстного меню, если в desktop-файле прописан аргумент %F.
Это тоже можно найти в спецификации. Аргументов есть ещё несколько.