По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой статье мы объясним, как узнать, кто использует тот или иной файл в Linux. Это поможет вам узнать системного пользователя или процесс, который использует открытый файл.
Как узнать, кто использует файл в Linux?
Мы можем использовать команду lsof (которая является аббревиатурой от List Of Opened Files), чтобы узнать, использует ли кто-то файл, и если да, то кто. Он читает память ядра в поиске открытых файлов и перечисляет все открытые файлы. В этом случае открытый файл может быть обычным файлом, каталогом, специальным файлом блока, специальным файлом символов, потоком, сетевым файлом и многими другими, поскольку в Linux все является файлом.
Lsof используется в файловой системе, чтобы определить, кто использует какие-либо файлы в этой файловой системе. Вы можете запустить команду lsof в файловой системе Linux, и выходные данные идентифицируют владельца и информацию о процессах для процессов, использующих файл, как показано в следующих выходных данных.
$ lsof /dev/null
Список всех открытых файлов в Linux
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd 1480 merionet 0r CHR 1,3 0t0 6 /dev/null
sh 1501 merionet 0r CHR 1,3 0t0 6 /dev/null
sh 1501 merionet 1w CHR 1,3 0t0 6 /dev/null
dbus-daem 1530 merionet 0u CHR 1,3 0t0 6 /dev/null
xfce4-ses 1603 merionet 0r CHR 1,3 0t0 6 /dev/null
xfce4-ses 1603 merionet 1w CHR 1,3 0t0 6 /dev/null
at-spi-bu 1604 merionet 0r CHR 1,3 0t0 6 /dev/null
dbus-daem 1609 merionet 0u CHR 1,3 0t0 6 /dev/null
at-spi2-r 1611 merionet 0u CHR 1,3 0t0 6 /dev/null
xfconfd 1615 merionet 0u CHR 1,3 0t0 6 /dev/null
xfwm4 1624 merionet 0r CHR 1,3 0t0 6 /dev/null
xfwm4 1624 merionet 1w CHR 1,3 0t0 6 /dev/null
xfce4-pan 1628 merionet 0r CHR 1,3 0t0 6 /dev/null
xfce4-pan 1628 merionet 1w CHR 1,3 0t0 6 /dev/null
Thunar 1630 merionet 0r CHR 1,3 0t0 6 /dev/null
Thunar 1630 merionet 1w CHR 1,3 0t0 6 /dev/null
xfdesktop 1632 merionet 0r CHR 1,3 0t0 6 /dev/null
xfdesktop 1632 merionet 1w CHR 1,3 0t0 6 /dev/null
....
Чтобы вывести список файлов, открытых для конкретного пользователя, выполните следующую команду: замените merionet вашим именем пользователя.
$ lsof -u merionet
Список файлов, открытых пользователем:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd 1480 merionet cwd DIR 8,3 4096 2 /
systemd 1480 merionet rtd DIR 8,3 4096 2 /
systemd 1480 merionet txt REG 8,3 1595792 3147496 /lib/systemd/systemd
systemd 1480 merionet mem REG 8,3 1700792 3150525 /lib/x86_64-linux-gnu/libm-2.27.so
systemd 1480 merionet mem REG 8,3 121016 3146329 /lib/x86_64-linux-gnu/libudev.so.1.6.9
systemd 1480 merionet mem REG 8,3 84032 3150503 /lib/x86_64-linux-gnu/libgpg-error.so.0.22.0
systemd 1480 merionet mem REG 8,3 43304 3150514 /lib/x86_64-linux-gnu/libjson-c.so.3.0.1
systemd 1480 merionet mem REG 8,3 34872 2497970 /usr/lib/x86_64-linux-gnu/libargon2.so.0
systemd 1480 merionet mem REG 8,3 432640 3150484 /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
systemd 1480 merionet mem REG 8,3 18680 3150450 /lib/x86_64-linux-gnu/libattr.so.1.1.0
systemd 1480 merionet mem REG 8,3 18712 3150465 /lib/x86_64-linux-gnu/libcap-ng.so.0.0.0
systemd 1480 merionet mem REG 8,3 27112 3150489 /lib/x86_64-linux-gnu/libuuid.so.1.3.0
systemd 1480 merionet mem REG 8,3 14560 3150485 /lib/x86_64-linux-gnu/libdl-2.27.so
...
Еще одно важное использование lsof - выяснение процесса прослушивания определенного порта. Например, определите процесс, прослушивающий порт 80, с помощью следующей команды.
$ sudo lsof -i TCP:80
Процессы, прослушивающие порт:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
httpd 903 root 4u IPv6 20222 0t0 TCP *:http (LISTEN)
httpd 1320 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN)
httpd 1481 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN)
httpd 1482 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN)
httpd 1493 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN)
httpd 1763 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN)
httpd 2027 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN)
httpd 2029 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN)
httpd 2044 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN)
httpd 3199 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN)
httpd 3201 apache 4u IPv6 20222 0t0 TCP *:http (LISTEN)
Примечание: поскольку lsof читает память ядра при поиске открытых файлов, быстрые изменения в памяти ядра могут привести к непредсказуемым результатам. Это один из основных недостатков использования команды lsof.
Для получения дополнительной информации, смотрите справку lsof:
$ man lsof
На этом все! В этой статье мы объяснили, как узнать, кто использует тот или иной файл в Linux.
Предыдущий материал из цикла про ARP в IPv4. Ждет вас по ссылке.
Как хост может узнать, следует ли пытаться отправить пакет хосту через сегмент, к которому он подключен, или отправить пакет на маршрутизатор для дальнейшей обработки? Если хост должен отправлять пакеты на маршрутизатор для дальнейшей обработки, как он может узнать, на какой маршрутизатор (если их несколько) отправлять трафик? Эти две проблемы вместе составляют проблему шлюза по умолчанию.
Для IPv4 проблему довольно легко решить, используя префикс и длину префикса. Рисунок ниже демонстрирует нам это.
Реализации IPv4 предполагают, что любой хост в пределах одной подсети IPv4 должен быть физически подключен к одному проводу. Как реализация может определить разницу? Маска подсети - это еще одна форма длины префикса, которая указывает, где заканчивается сетевой адрес и начинается адрес хоста. В этом случае предположим, что длина префикса равна 24 битам, или сетевой адрес равен /24. 24 указывает вам, сколько битов задано в маске подсети: 24 bits = 11111111.11111111.11111111.0000000
Поскольку в IPv4 используется десятичная запись маски, это также можно записать как 255.255.255.0. Чтобы определить, находится ли C на том же проводе, что и A, A будет:
Логическое умножение маски подсети с адресом локального интерфейса
Логическое умножение маски подсети с адресом назначения
Сравните два результата; если они совпадают, целевой хост находится на том же канале связи, что и локальный интерфейс
На рисунке ниже это продемонстрировано.
На рисунке выше показано четыре IPv4-адреса; предположим, что A должен отправлять пакеты в C, D и E. Если A знает, что длина префикса локального сегмента составляет 24 бита либо с помощью ручной настройки, либо с помощью DHCPv4, то он может просто посмотреть на 24 наиболее значимых бита каждого адреса, сравнить его с 24 наиболее значимыми битами своего собственного адреса и определить, находится ли пункт назначения на сегменте или нет. Двадцать четыре бита IPv4-адреса создают хороший разрыв между третьей и четвертой секциями адреса (каждая секция IPv4-адреса представляет собой 8 бит адресного пространства, в общей сложности 32 бита адресного пространства).
Любые два адреса с такими же левыми тремя секциями, что и у A, называемые сетевым адресом, находятся в одном сегменте; любой адрес, которого нет в сегменте. В этом случае сетевой адрес для A и C совпадает, поэтому A будет считать, что C находится в одном сегменте, и, следовательно, будет отправлять пакеты C напрямую, а не отправлять их на маршрутизатор. Для любого пункта назначения, который A считает вне сегмента, он будет отправлять пакеты на IPv4-адрес конечного пункта назначения, но на MAC-адрес шлюза по умолчанию. Это означает, что маршрутизатор, выступающий в качестве шлюза по умолчанию, примет пакет и переключит его на основе IPv4-адреса назначения. Как выбирается шлюз по умолчанию? Он либо настраивается вручную, либо включается в параметр DHCPv4.
А что насчет D? Поскольку сетевые части адресов не совпадают, A будет считать, что D находится вне сегмента. В этом случае A отправит любой трафик для D на свой шлюз по умолчанию, которым является B. Когда B получит эти пакеты, он поймет, что A и D достижимы через один и тот же интерфейс (на основе своей таблицы маршрутизации), поэтому он будет отправлять ICMP-перенаправление на A, говоря ему, что нужно отправлять трафик на D напрямую, а не через B.
IPv6 представляет собой более сложный набор проблем, которые необходимо решить при выборе шлюза по умолчанию, потому что IPv6 предполагает, что одно устройство может иметь много адресов IPv6, назначенных конкретному интерфейсу. Рисунок ниже демонстрирует это.
На рисунке выше предположим, что администратор сети настроил следующие политики:
Ни один хост не может подключаться к A, если у него нет адреса в диапазоне адресов 2001: db8: 3e8: 110 ::/64.
Ни один хост не может подключиться к D, если у него нет адреса в диапазоне адресов 2001: db8: 3e8: 112 ::/64.
Примечание: В реальном мире вы никогда не построили бы такую политику; это надуманная ситуация, чтобы проиллюстрировать проблему, поставленную в сети минимального размера. Гораздо более реальной проблемой такого же типа была бы одноадресная переадресация обратного пути (uRPF).
Чтобы эти политики работали, администратор назначил 110::3 и 112::12 хосту C и 111::120 хосту F. Это может показаться странным, но совершенно законно для одного сегмента иметь несколько подсетей IPv6, назначенных в IPv6; также совершенно законно иметь одно устройство с несколькими адресами. На самом деле, в IPv6 существует множество ситуаций, когда одному устройству может быть назначен диапазон адресов.
Однако с точки зрения длины префикса нет двух адресов, назначенных C или F, в одной подсети. Из-за этого IPv6 не полагается на длину префикса, чтобы определить, что находится в сегменте, а что нет. Вместо этого реализации IPv6 ведут таблицу всех подключенных хостов, используя запросы соседей, чтобы определить, что находится в сегменте, а что нет. Когда хост хочет отправить трафик из локального сегмента, он отправляет трафик на один из маршрутизаторов, о котором он узнал из объявлений маршрутизатора. Если маршрутизатор получает пакет, к которому, как он знает, другой маршрутизатор в сегменте имеет лучший маршрут (поскольку у маршрутизаторов есть таблицы маршрутизации, которые говорят им, какой путь выбрать к какому-либо конкретному месту назначения), маршрутизатор отправит сообщение перенаправления ICMPv6, сообщающее хосту использовать какой-либо другой маршрутизатор первого перехода для достижения пункта назначения.
В следующей статьей мы поговорим про пакетную коммутацию.
Cisco IOS-XE - операционная система на базе Linux, которую Cisco представила в 2008 коду в продуктах ASR и Catalyst. Является усовершенствованной версией более старой IOS и имеет ряд функциональных изменений.
Cisco IOS-XE добавляет поддержку симметриченой многопроцесорной архитектуры и отдельных пространств памяти. Все функции системы теперь выполняются как отдельные процессы, и это дает много преимуществ. Теперь мы можем использовать многопроцессорность – это означает, что рабочая нагрузка процессов может быть разделена между несколькими процессорами. Когда один процесс выходит из строя, он не положит вам всю систему. Звучит хорошо, не так ли? :) Программное обеспечение IOS-XE больше не является «большим» файлом, в котором есть все – у него есть отдельные подпакеты. Можно обновить отдельный подпакет, а не обновлять все. Однако, помимо своих Linux-подходов, где IOS работает как отдельный процесс, Cisco IOS-XE в основном похожа на традиционную Cisco IOS.
Какие продукты поддерживают IOS-XE?
Enterprise switches:
Catalyst 9500
Catalyst 9400
Catalyst 9300
Catalyst 3850
Catalyst 3650
Aggregation/edge routers:
ASR 1013
ASR 1009-X
ASR 1006-X
ASR 1006
ASR 1004
ASR 1002-HX
ASR 1001-HX
ASR 1002-X
ASR 1001-X
ASR 900
NCS 4200
Branch routers:
4451 ISR
4431 ISR
4351 ISR
4331 ISR
4321 ISR
4221 ISR
1000 ISR
Virtual Routing ISRv:
ISRv
CSR1000v
Converged Broadband Routers:
CBR Series
IOS XE это еще одна операционная система от Cisco?
Нет, Cisco IOS XE представляет собой непрерывную эволюцию программного обеспечения Cisco IOS для поддержки платформ следующего поколения. Сама Cisco IOS XE устанавливается на ASR-1000 с 2008 года, а Cisco IOS XE 3 SG устанавливается на Catalyst 4500-E Series с октября 2010 года. Он обеспечивает улучшенную архитектурную стратегию программного обеспечения, сохраняя при этом все преимущества и привычный интерфейс управления IOS.
Какие преимущества IOS XE над IOS
Существует несколько преимуществ перехода от IOS к IOS XE, которым будут пользоваться конечные пользователи. IOS XE поможет снизить общую стоимость владения многими решениями Cisco, предлагая расширенную интеграцию служб для повышения функциональности в сети. Кроме того, она поддерживает несколько ядер процессора, плоскость управления и разделение плоскости данных, и абстракцию платформы. Cisco IOS XE содержит Cisco IOS Release 15 внутри себя. Программное обеспечение Cisco IOS работает как процесс в Cisco IOS XE в так называемых демонах (daemon) IOS или IOSd.
Нужно ли заново обучаться работе с IOS XE?
Нет, Cisco IOS XE выглядит так же, как и традиционное программное обеспечение Cisco IOS. Изменены только несколько команд, такие как «show processor» и «show memory», которые были расширены для учета многоядерных процессоров, которые теперь поддерживает Cisco IOS XE. В целом, если вы знаете, как управлять программным обеспечением Cisco IOS, то вы знаете, как управлять Cisco IOS XE.
Каковы долгосрочные перспективы Cisco IOS XE?
Большинство платформ следующего поколения будут переноситься на Cisco IOS XE в ближайшие годы.
Могут ли мои текущие коммутаторы и маршрутизаторы быть обновлены до Cisco IOS XE?
Нет. Чтобы упростить переход, Cisco IOS XE будет представлена только после выхода новых поколений аппаратных платформ. Обновление существующей платформы без обслуживания не будет обеспечено. Аналогично, любая платформа, на которой работает Cisco IOS XE, не будет поддерживать работу с Cisco IOS.
Каким образом функции распределяются между IOS и IOS XE?
Так как Cisco IOS XE содержит IOSd в Cisco IOS, все функции, созданные в IOS, также появятся в IOS XE и наоборот. Только новые интегрированные сервисы и функции, созданные за пределами IOSd, не будут использоваться совместно с выпуском Cisco IOS. Однако эти интегрированные сервисы могут быть внедрены на платформе Cisco IOS с использованием дочерних карт Integrated Services, которые будут доступны на основе “платформа – платформа”
Какие сервисы будут представлены в Cisco IOS XE и насколько открытой будет эта платформа для интегрированных сторонних служб и приложений?
Службы, которые традиционно управляются standalone приложениями или серверами, теперь будут интегрированы в среду Cisco IOS XE. На сегодняшний день примеры включают в себя Сisco Unified Border Element (CUBE) и Session Border Controller (SBC), но этот список со временем будет пополняться.