Задать вопрос
  • Может ли TCP соединение работать сразу с несколькими клиентами?

    @nirvimel
    TCP соединение - это сокет. Открытый сокет связывает конкретный порт на локальной машине с конкретным портом на конкретной удаленной машине (и никак иначе). Открытый сокет соединяет всегда две стороны. Не существует многосторонних сокетов. Но на одной машине может быть открыто сколько угодно сокетов.
    Ответ написан
    Комментировать
  • Как перехватить трафик одной программы?

    vvpoloskin
    @vvpoloskin Куратор тега Компьютерные сети
    Инженер связи
    Одна программа всегда обращается к конкретному узлу по конкретному порту также с конкретного узла и порта. Поставьте фильтры на порт и адрес.
    Ответ написан
    7 комментариев
  • Какой аналог Aircrack-ng для Ubuntu?

    sfi0zy
    @sfi0zy
    Creative frontend developer
    sudo apt install aircrack-ng
    Ответ написан
    3 комментария
  • Что такое LOA (letter of authorisation) при переносе блока ipv6 адресов хостеру?

    vvpoloskin
    @vvpoloskin Куратор тега Компьютерные сети
    Инженер связи
    Все же расписано, почему вы не руководствуетесь официальными документами? Вам нужно осуществить перевод своего блока в их AS, получить письмо подтрверждение от ARIN и отправить хостеру.

    Вы будете по каждому ответу ТП вашего хостинга задавать вопрос на тостере?
    Ответ написан
    Комментировать
  • Почему в уведомлении не выводятся данные из переменной?

    @shnicel Автор вопроса
    notify-send 'VK Friend' "`curl "lnk"`"
    Ответ написан
    Комментировать
  • Всем привет, промогите разобраться с скриптом для Linux?

    CityCat4
    @CityCat4
    //COPY01 EXEC PGM=IEBGENER
    Банальный синтаксис. После case нет esac, после do нет done. Или это неполный скрипт? Для проверки файла вот есть такая фигня - проверяет наличие, то, что это файл (а не каталог, например) и то, что он не нулевого размера:
    check_fileread()
    {
      if [ ${#1} -ne 0 ]; then
        if [ ! -r $1 ]; then
          echo "File $1 cannot read (does not exist, access denied)"
          exit 55
         elif [ ! -s $1 ]; then
           echo "File $1 is empty (has zero size)"
           exit 56
        fi
      fi
    }
    Ответ написан
    Комментировать
  • Реализация ping на bash?

    sanchomaster
    @sanchomaster
    deployment engineer
    Вот например, то же но проще, с использованием nmap:
    nmap -sP 192.168.1.0/24 | awk '$2=="scan" {print "Оборудование с IP:" $5 " находиться в сети."}'


    Адрес сети и маску можно подставить свою.
    Ответ написан
    Комментировать
  • Какие есть объективные причины для перехода на Linux вебразработчику?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Почему до сих пор считается, что основной ОС вебразработчика должна быть ОС на основе Linux?

    Как правило, это на порядок удобнее.

    Да, можно под виртуалкой запустить линуху, но зачем?)
    Да, можно эмулировать линушную консольку, но половина хоткеев у вас работать не будет.
    Да, можно докер в виртуалке поднять, но под линухой он будет нейтивно работать.
    Да, можно считать, что вагрант вас спасет, но тот же ансайбл придется таки вовнутри поднимать, а не использовать хостовой.
    Да, можно приблуды для виртуальных рабочих столов прикрутить, но зачем, это идет в коробке с большинством DE.
    Да, можно по полной программе обмазываться putty и понасохранять все ваши доступы, но проще настроить ~/.ssh/config.
    Да, можно понаустанавливать вот это ваше все с официальных сайтов, но проще натапть "apt install **", или "yum install **".
    Да, можно залезть в политики безопасности и сделать "зашибись", но для обычной dev тачки под nix чаще всего вам это и не нужно.
    Да, можно закачать крутых прог, которые вам скрытые процессы покажут, но проще ввести есть ps aux.
    Да, можно в .gitattributes понапрописывать text eol=lf, но опять же зачем, если только у винды принят crlf?
    Да, можно понаотключать BOM, но опять же зачем?
    Да, можно считать реестр - удобной штукой, но это не так))
    и т. д...

    Из таких мелочей и состоит пользование ОС.

    Чуть не забыл:
    Да, можно считать, что комп под виндой принадлежит вам...))
    Ответ написан
    12 комментариев
  • "The system is running in low-graphics mode", как исправить?

    Есть цепочка зависимостей A -> B -> C
    Вы удалили элемент B, вместе с ним вы удалили C, т.к. он не может работать без своей зависимости.
    Затем вы удалили неиспользуемые элементы (от которых никто не зависит), в нашем случае это A.
    Решили починить всё, и вернули обратно B. За ним подтянулся элемент A. Но C не поставился, т.к. он не нужен для работы B.

    Итого: скорее всего вы снесли части графического окружения и драйверы. Попробуйте поставить xubuntu-desktop и драйвер для вашей видеокарты (если используете пропиретарный).
    Ответ написан
    2 комментария
  • Как в BASH скрипте написать дату и время?

    @viiy
    Linux сисадмин \ DevOps
    git commit -a -m "комментарий `date +"%Y%m%d %H:%M"`"
    или
    git commit -a -m "комментарий $(date +"%Y%m%d %H:%M")"

    нужный формат даты подберите из "man date"
    Ответ написан
    Комментировать
  • Скрипт (или программа) для сравнения данных в двух каталогах?

    saboteur_kiev
    @saboteur_kiev Куратор тега Linux
    software engineer
    DU показывает не размер файлов и папок, а сколько они занимают на диске.
    Например, если на втором диске у вас размер блока больше, то du всегда будет показывать больше.

    В вашем случае, лучше синхронизируйте все по rsync с компрессией - надежнее. И вообще готовых решений по синхронизации двух каталогов, которые уже позаботились о всех детских болезнях, типа имен файлов с опасными символами, и другими штуками - множество.
    Можно и одностороннюю синхронизацию сделать.

    Или упростите скрипт, например до такого
    find DIR1/* -exec md5sum {} \; > file1.lst
    find DIR2/* -exec md5sum {} \; > file2lst
    diff file1.lst file2.lst
    Ответ написан
    1 комментарий
  • Непростая задача для vim?

    sim3x
    @sim3x
    $ for n in {101..125}; do echo -n 192.168.$n.0/24, ; done


    192.168.101.0/24,192.168.102.0/24,192.168.103.0/24,192.168.104.0/24,192.168.105.0/24,192.168.106.0/24,192.168.107.0/24,192.168.108.0/24,192.168.109.0/24,192.168.110.0/24,192.168.111.0/24,192.168.112.0/24,192.168.113.0/24,192.168.114.0/24,192.168.115.0/24,192.168.116.0/24,192.168.117.0/24,192.168.118.0/24,192.168.119.0/24,192.168.120.0/24,192.168.121.0/24,192.168.122.0/24,192.168.123.0/24,192.168.124.0/24,192.168.125.0/24,
    Ответ написан
    1 комментарий
  • Что сделать для безопасности в linux на домашней машине?

    @fpir
    Однажды к мастеру учения пришёл неофит и сказал:
    Учитель, меня терзают сомнения. Когда я исповедовал путь Windows, у меня были и антивирусы, и брандмаузеры, и чистильщики реестра, и другие утилиты, которые меня защищали. Сейчас-же, я чувствую себя беззащитным перед опасностями интернета.
    Тогда учитель связал ему шнурки и велел-Беги!
    Что-же это значит, Учитель?
    Когда дом изначально хорошо спроектирован, нет смысла в дополнительных подпорках.
    И тогда неофит познал дзен.
    Ответ написан
    Комментировать
  • Как выполнить файл в консоли с помощью bash?

    взято отсюда: https://github.com/jlevy/the-art-of-command-line
    In Bash scripts, subshells (written with parentheses) are convenient ways to group commands. A common example is to temporarily move to a different working directory, e.g.
    # do something in current dir
    (cd /some/other/dir && other-command)
    # continue in original dir

    Возможное решение:
    в ~/.bashrc можно добавить alias:
    alias my_command='(cd /path/to/dir && ./my_command)'
    Ответ написан
    Комментировать
  • Как правильно управлять парком серверов Unix?

    igortiunov
    @igortiunov
    Приветствую.
    Прежде всего, не стоит представлять себе решение задачи, как "большую кнопку", т.к. наши представления об управлении инфраструкурой несколько извращены опытом работы с продуктами MS. Интерфейс скрывает от нас стек ПО используемого для достижения цели. Например, WSUS. Под его капотом находится набор служб, каждая из которых играет определенную роль - bits для загрузки на сервер и доставки пакетов на клиента, веб-сервер для управляющих команд, база данных для хранения состояния клиентов и исправлений, .net приложение, обьединяющее все это. Для парка nix машин вам предстоит построить подобную архитектуру самому, выбирая каждый раз инструмент, который будет играть ту или иную роль.
    На втором шаге вам нужно посмотреть на задачу. Если у вас десяток инфраструктурных серверов, то Ansible действительно неплохой выбор. Но только не "скрипт". "Скрипт" - это язык, который говорит как достичь результата. Но инструменты управления конфигурацией избавляют вас от этого, с помощью декларативного языка вы описываете сам конечный результат(это ключевой момент) и не задумывайтесь о том, какой дистрибутив (читай менеджер пакетов, расположение конфигурационного файла) установлен на управляемой системе.
    Если вам нужно дать доступ большому количеству пользователей к большому количеству машин, то на первом шаге вам нужно выбрать два инструмента:
    1. управление конфигурацией.
    2. управление sudo.
    Первый инструмент с натяжкой может предоставить вам возможность решить пункт 2, т.к. в этом втором пункте вам нужно управлять теми самыми политиками: группе пользователей дать доступ на группу машин и разрешить выполнять группу команд. Здесь в игру вступает Identity Manager и этот вопрос для меня по крайней мере, открыт. Текущие тенденции ведут к развертыванию двух каталогов (MS AD и каталог для парка NIX), но не берусь сказать насколько это правильно. Обойтись без второго каталога можно и, если отбросить шелуху, то ключевой проблемой, в таком случае, является сопоставление идентификаторов безопасности пользователей в MS AD и в nix системах (просто когда один домен, сложнее когда лес, совсем не просто в случае созданных вручную доверительных отношений). Раньше этот вопрос решал winbind с набором библиотек, реализующих тот или иной алгоритм сопоставления, теперь это SSSD, реализующий два алгоритма. Опять же вопрос с выполнением привилегированных команд в такой конфигурации не решается. RedHat предлагает скомпанованные в единый продукт инструменты, которые, якобы эти задачи решают. Поддержкак от этого самого редахата стоит бешеных для нас денег, но вы посмотрите из чего состоят такие решения как Sattelit и IdM, это открытые продукты (FreeIPA, candlepin, pulp, katello, puppet и, наконец, foreman.) которые, возможно вам и нужны.
    Ответ написан
    8 комментариев
  • Расшифровка зашифрованного раздела, если взломать root?

    leahch
    @leahch Куратор тега Linux
    3D специалист. Dолго, Dорого, Dерьмово.
    Раздел пользователя обычно шифруется текущим паролем. Если точнее, то шифруется доступ к хранилищу ключей текущим паролем, а из хранилища достается длинный ключ шифрования. Другими словами, сбросив пароль, расшифровать не получится! При смене пароля пользователя хранилище ключей перешифровывается заново. Но можно подсмотреть уже замонтированный зашифрованный раздел.
    Ответ написан
    6 комментариев
  • Зависает при установке Ubuntu 14.10, 15.04 на Asus F80L. Что это?

    @polozad
    Перейти в консоль, посмотреть что с системой.
    Ответ написан
    1 комментарий
  • Что представляет собой тестирование ?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Вообще вики можно для начала, а потом уже углубляться в литературу. Вот вам кратенькое описание, цель которого больше предоставить ключевые слова для поиска.

    Модульные, они же юнит тесты, предназначены для тестирования отдельных модулей/классов. Суть их в том, что мы тестируем поведение только одного класса за раз. Если класс ссылается на инстансы других классов - мы их мокаем. То есть подсовываем им фэйковый класс, который имеет тот же интерфейс, но внутри не реализациа методов, а проверка, вызывали ли метод, с каким аргументами, сколько раз вызывали и т.д. Так же методы мока могут возвращать стабы (заглушки), какие-то захардкоженные под какой-то кейс данные. То есть если мы пишем класс по работе с базой данных, сокет-сервер и т.д., нам стоит соединение с базой, сокеты и т.д. оборачивать в классы, что бы можно было потом подменить на моки это добро. Если у вас в юнит тестах идет реальная работа с файловой системой или что-либо в этом духе, то это уже попахивает интеграционными тестами. Подробнее можно почитать в документации к phpunit. Так же есть такая методология разработки как TDD, советую почитать "Экстримальное программирование" Кента Бэка в этом ключе.

    Сразу хочу отметить что юнит тесты это хорошо, но вот только рядовой разработчик на PHP редко пишет что-то, что стоит покрывать юнит тестами. Времени на их поддержку нужно не мало, а требования у заказчиков частенько меняются. В итоге тесты начинают комментить и толку от них становится ноль. А вот если вы пишите компонент/библиотеку, то тут юнит тесты обязательны (ну... не то что бы, но желательны). Так что я бы на вашем месте сконцентрировал внимание на первом этапе на интеграционных и приемочных тестах.

    Интеграционное тестирование - тестирование нескольких модулей в связке. То есть мы тестируем наш компонент или его самодостаточный кусок в реальных условиях. Если этот компонент для работы с файлами - разрешаем ему доступ к файлам. Если база данных - то даем реальное соединение с базой. А можем что-то и замокать. Это как говорится, зависит от задачи. Скажем обращение к сторонним апишкам стоит мокать и стабить. Главная цель этих тестов, удостовериться что модули вместе работают хорошо. Особенно важно это когда модули пишут разные люди.

    Функциональное тестирование - это тестирования всего приложения в сборе. Если это REST API, то у нас через curl дергаются реальные методы, отправляются более менее реальные запросы и валидируются ответы. Если web-страничка, то это UI тесты с силениумом/phantom.js/zombi.js или, если нам не нужно еще и js тестить, просто curl + какой виртуальный браузер на том же php. Вообще по хорошему функциональные тесты не допускают никаких моков и т.д. но опять же если очень хочется то можно (опять же обращение к сторонним сервисам, контроля за которыми у нас нету).

    Но реалии таковы, что UI тестами покрывать проект не слишком удобно. Вопервых UI может меняться, а поддерживать их так же нужно. Во вторых это скучно. В третьих тесты могут просто падать... вот взяли и упали. И потом начинается, так, тесты опять упали... что там упало? А, не страшно, можно релизить. Так же на больших проектах UI тесты отрабатывают долго, очень долго, некоторых их просто ночью гоняют. Толку от тестов при таком подходе не слишком много, ибо разработчику стоит знать о том что что-то сломалось как можно быстрее. А так он приходит, видит что тесты опять красные, чинит эти красные тесты, и запускает... ждет... проходит пол часа к примеру, и где-то в другом месте отвалилось... Короче сами понимаете.

    Приемочное тестирование - по сути те же функциональные тесты, но подаются в контексте фича-спеков. Если вы работали когда-нибудь с QA отделом, то возможно слышали про такие штуки как acceptance criteria. То есть это тот чек лист, который должен проверить тестировщик что бы удостовериться что все хорошо. На основе этого чек листа можно написать функциональные тесты. Так же есть инструменты вроде Cucumber/Behat, которые позволяют писать спецификации в виде стэпов. В этом случае спецификации для этих инструментов могут писать QA а вы просто имплементите для них степы. То есть уменьшается прослойка между "acceptance criteria" и готовыми к выполнению тестов. Более того, стэпы можно реюзать, комбинировать, масса стэпов есть готовых, вам же необходимо только предоставить стэпы подготвалливающие систему (загрузка/генерация фикстур и т.д.). Короче лепота и удобно. Но медленнее интеграционных, зато не такие жесткие как функциональные, за счет этого их проще поддерживать. QA пишут спеку, реализуем тесты под эту спеку, пишем код под тесты, тесты зеленые - функционал готов.

    Ну и есть еще всякие термины типа пирамида тестов и т.д. Мол лучше много юнит тестов, чуть поменьше интеграционных и мало функциональных. Тогда тесты выполняются быстрее, а покрывать все и вся функциональными тестами обычно перебор.

    Ну и опять же, есть такая вещь как здравый смысл. Некоторые вещи скажем можно вообще забить и не покрывать тестами, некоторые стоит покрыть. Некоторые не полностью, некоторые с как можно большим покрытием.... Скажем тестить UI (именно как выглядит, где какой элемент) вообще бессмысленно. На это нужно куча ресурсов. Хотя может и есть проекты где это оправдано.

    Короче почитайте про TDD и ATDD (можно и BDD затронуть, но тут не только от программиста зависит, менеджеры, заказчик или продукт-оунер тоже должны быть вовлечены, по сути этот подход хорошо работает в рамках продукта какого-то, на фрилансе и в аутсорсе редко можно встретить) , Continious Integration и Continious Delivery.
    Ответ написан
    Комментировать