По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В этой статье мы объясним, как узнать, кто использует тот или иной файл в 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.
img
CURL это мощный инструмент командной строки, который позволяет тестировать различные API интерфейсы, отправлять данные на URL методом POST/GET и прочее. Как минимум для разработчика это необходимый инструмент. Если вам нужно протестировать CURL, а вы не хотите устанавливать Postman, например, то из терминала (командной строки) на MacOS можно лего инициировать CURL. В статье мы покажем несколько полезных примеров cURL и терминала. Отправка POST запрос через cURL Сделать POST легко: можно с данными, а можно и без них. Смотрите какой синтаксис использования: CURL запрос без дополнительных данных curl -X POST http://URL/test.php CURL запрос с дополнительными параметрами curl -d "data=test1data2=test2" http://URL/test.php CURL с передаче полей curl -X POST -F "name=diman" -F "password=test" http://URL/example.php CURL с передачей файла curl -X POST -F "image=@/path/pic.png" http://URL/testform.php Отправка CURL с JSON Ловите пример отправки JSON curl -H "Content-Type: application/json" -X POST -d '{"user":"sanya","pass":"qwerty"}' http://test/myscript.php Вам мало примеров? Если так, то вы легко можете изучить все возможности CURL в консоли: curl --help curl --manual Профит!
img
Прямо сейчас, пока ты читаешь эту статью, в серверной комнате организации А под толстым слоем пыли, окруженная множеством переплетенных проводов мигает разноцветными лампочками офисная АТС. Но давайте будем тише - дежурный IT - специалист, скорее всего спит, поставив переадресацию на мобильный телефон - а вдруг что - то сломается? Вообще, облака, на своем старте - наделали шума. Все начали задаваться вопросом - а зачем нам сервер в офисе, когда можно арендовать VPS/VDS/SaaS в облаке и “не париться”? В статье мы ответим на вопрос - почему одни компании выносят свою телефонию в облако или покупают услугу виртуальной АТС, тем самым создавая возможность поставить вендинговую машину или настольный теннис в серверной комнате, а другие, продолжают перебирать провода, протирать пыль с серверов и наслаждаться мерцанием цветовых серверных индикаторов от офисной АТС. Бюджет: сравниваем облако и размещение в офисе Первое, что стоит спросить себя - а как мы будем платить за АТС? Что для нас важно, а что нет? Мы, как интегратор, все чаще сталкиваемся с тем, что в компаниях (SMB) идет сокращение бюджета на IT и соответствующие отделы находят выходы из этой ситуации. С точки зрения локальной (офисной) АТС - далее мы будем называть ее порой “on-premise” решение (говоря так, мы чувствуем себя немного круче), IT - отдел экономит деньги ежемесячной оплате хосту (SaaS платформе, которая дает вам услугу виртуальной АТС). Но эта экономия реальна только в том случае, если вы не меняете аппаратные компоненты сервера с АТС. В таком случае модель вы платите только за услуги провайдера, электричество и заработную плату IT’шнику. Модель “купил - запитал - работает, не трожь” работает, более чем. Однако, в случае выхода из строя того или иного компонента, компания несет определенного рода дополнительные расходы. Отметим, опять же, на нашем опыте - случается это редко. Современные сервера имеют высокое качество комплектующих, и если вы не планируете поливать сервера водой, обдавать из огнемета или выставлять на улице - скорее всего, данная неприятность вам не грозит. Не менее важный фактор - обновление ПО. Проблема в том, что если вы обновляете программное обеспечение офисной “on-premise” (да - да, мы же предупреждали) АТС, есть риск выхода из строя. Опять же, данная проблема решается простым резервированием, так называемой отказоустойчивостью, по принципу Active - Standby (один сервер активен, а второй в резерве и всегда готов выйти в активную роль). Этот нюанс требует дополнительной проработки, а следовательно, дополнительных денежных затрат. Теперь про масштабируемость. В случае, если проснувшись в один прекрасный день вы осознаете, что ваш бизнес вырос в разы (вы сходили на бизнес - тренинг, к шаману или проделали магический обряд), то офисные локально размещенные станции масштабируются несколько сложнее и затратнее, чем виртуальные. Это отражается на деньгах и стоимости масштабирования. Тут есть важный пункт - офисная АТС гораздо более гибка, чем виртуальная. Дело в том, что виртуальная АТС дается вам в неком готовом контейнере предустановок, где SaaS платформа редко дает возможность доработки станции. Да, признаем, некоторые облачные АТС имеют API, но когда вопрос заходит о масштабном изменении логики работы АТС (кастомизация скриптами, например) - тут происходит коллапс. В этом плане офисные АТС явно выигрывают перед облачными, несмотря на стоимость затрат на эту самую кастомизацию. Просто сам факт ее возможность при быстром росте бизнеса - это преимущество (поверьте, знаем о чем говорим на опыте разных проектов). Редкие, но некоторые IT - отделы предпочитают облачную телефонию. Это более предсказуемо и снимает с них часть ответственности. Например, когда директор компании задает вопрос ITшнику почему не работает телефония, тот может смело спихнуть ответственность на виртуального хостера. Модернизация и апгрейд: витаем в облаках или в офисе? Тут пальму первенства заслуженно забирают облака. Дело в том, что если у вас в офисе живет on-premise АТС, так или иначе, рано или поздно вам придётся обновлять аппаратные компоненты сервера (процессор, оперативная память, наращивать мощность RAID массивов, тем самым увеличивая пространство для хранения данных). Это происходит по двум причинам: растёт нагрузка на сервер и текущие мощности уже не справляются, или обновление программного обеспечения требует более производительных комплектующих. При облачном размещении таких проблем нет - ваш хост автоматически наращивает мощности виртуальной машины, внутри которой живет ваша АТС. Это, безусловно, сказывается на мощности, но выходит дешевле покупки комплектующих под локальных сервак. Кстати про обновление - в случае решения, размещённого в вашем офисе, обновление ПО производят ваши ITшники, тогда как при размещении в облаке, хост сам обновляет ПО и раскатывает их на боевую среду. Интеграция телефонии с внешними системами Любителям on-premise решений посвящается. Откиньтесь на диване поудобнее - в этой главе уже есть победитель. И это не облако. Дело в том, что с ростом компании, уровень технологичности неизбежно повышается. Новые направления деятельности и увеличение потока клиентов обязывают связать ИТ - узлы в единую экосистему: интеграция телефонии и CRM, справочниками, базами данных, звонки по нажатию, триггерный автоматический обзвон, предиктивный дайлер и прочие. Все эти “хотелки” так или иначе требуют доработки вашей станции, так как интеграцию со всем на свете разработчики облачный виртуальных АТС предусмотреть не могут, а открыть исходный код и раздвинув горизонт кастомизации до бесконечности, рискуют получить уязвимости в безопасности. Именно по этой причине, офисная коробка дает больше. Например: вы хотите сделать маршрутизацию на базе гороскопа клиента. В вашей CRM есть номер телефона клиента, имя и его дата рождения. При входящем звонке, телефония “смотрит” в вашу CRM и видит месяц рождения клиента (по номеру, с которого он звонит). Кастомная прослойка понимает - он рыба, а рыбам, сегодня не рекомендуется иметь деловых отношений. И на базе этого решения офисная телефонная станция терминирует вызов. Как вам? Пожалуй, надо признать, пример весьма спорный. Но посыл понятен - коробка в офисе даст больший пул возможностей, а облако, максимум, обрезанный API. Катастрофы: коробки или облако? В офисе над вами прорвало трубу и залило серверную (мы реально встречали такие кейсы). Сервера вышли из строя, не работает ничего. Есть две новости, начнем с хорошей: Сервер был на гарантии и имеется контракт на горячую замену от интегратора; Сервера больше нет. Несмотря на контракт горячей замены, просто в минимум 24 часа вам гарантирован (если не реализована схема отказоустойчивости с географически распределенными серверами по ЦОДам). В облаке, как правило, SaaS дает вам гарантию работоспособности от 90%. Облачная вычислительная мощность живет в разных ЦОДах, при отказе аппаратного сервера, виртуальная машина с вашей ВАТС переедет на другой аппаратный сервер за сотые доли секунды. Что неплохо. Тут, пожалуй, для SMB компании первенство мы отдадим облаку. Итоги Как облака, так и размещенные в офисе решения имеют свои преимущества. Если курс вашей компании на безграничную кастомизацию, интеграцию всех ИТ - систем между собой для создания экосистемы и амбициозные бизнес - процессы, у вас есть грамотный IT - специалист, то выбирайте коробку, которую вы разместите в офисе. Если вы не хотите проблем с сервером, обслуживанием, вы малый бизнес, у вас нет своего IT’шника в штате и хотите рабочую телефонию с минимумом головной боли - облако подойдет под ваши требования.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59