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

   Во FreeBSD разработчики отреагировали на проблемы в течение недели, но исправили в репозитории лишь часть проблем и выпустили лишь несколько отчётов об уязвимостях. Статус исправления остальных ошибок находится в неопределённом состоянии, так как разработчики посчитали, что для них отсутствуют практические пути эксплуатации и перенесли из категории проблем с безопасностью в область обычных ошибок.

   Хуже всего обстоит дело с ОС NetBSD, качество кода которой очень разнородно, а время доставки исправлений слишком велико. Ошибки были исправлены за ночь, но были доведены до пользователей только через 6 месяцев из-за редкого формирования обновлений.

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

Источник

P. S. Интересный комментарий анонима:

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

P. P. S. Ну и шутка «в тему».

Делал так. От рута:

echo "nameserver 8.8.8.8" > /etc/resolv.conf
useradd -b /export/home soul
passwd soul

Под юзером soul создал файл bootstrap.sh со следующим содержимым:

BOOTSTRAP_TAR="bootstrap-2017Q3-x86_64.tar.gz"
BOOTSTRAP_SHA="10bb81b100e03791a976fb61f15f7ff95cad4930"
# Download the bootstrap kit to the current directory.
curl -O https://pkgsrc.joyent.com/packages/SmartOS/bootstrap/${BOOTSTRAP_TAR}
# Verify the SHA1 checksum.
[ "${BOOTSTRAP_SHA}" = "$(/bin/digest -a sha1 ${BOOTSTRAP_TAR})" ] || echo "ERROR: checksum failure"
# Verify PGP signature.  This step is optional, and requires gpg.
#curl -O https://pkgsrc.joyent.com/packages/SmartOS/bootstrap/${BOOTSTRAP_TAR}.asc
#curl -sS https://pkgsrc.joyent.com/pgp/DE817B8E.asc | gpg --import
#gpg --verify ${BOOTSTRAP_TAR}{.asc,}
# Install bootstrap kit to /opt/local
tar -zxpf ${BOOTSTRAP_TAR} -C /
# Add to PATH/MANPATH.
PATH=/opt/local/sbin:/opt/local/bin:$PATH
MANPATH=/opt/local/man:$MANPATH

Затем делаю его исполняемым и запускаю:

sudo chmod +x bootstrap.sh && sudo ./bootstrap.sh

Поставив pkgin, в файле ~/.profile добавил:

PKGSRC_BIN=/opt/local/bin
PKGSRC_SBIN=/opt/local/sbin
PKGSRC_MAN=/opt/local/man
PATH=${PKGSRC_SBIN}:${PKGSRC_BIN}:${PATH}
MANPATH=${PKGSRC_MAN}:${MANPATH}

После этого проверяю работу pkgin:

export PATH
export MANPATH
source ~/.profile
pkgin help

Если вывод команды pkgin корректный (она установлена и функционирует), то:

sudo pkg install xsvc
sudo pkgin install modular-xorg
sudo pkgin install modular-xorg-server modular-xorg-apps modular-xorg-fonts xf86-input-keyboard xf86-input-mouse
sudo pkgin install xf86-video-FOO
sudo pkgin install gnome
touch ~/.xinitrc && echo "exec gnome-session" > ~/.xinitrc
startx

Всё.

(бОльшую) часть подсмотрел тут.

Задача решена

Поставить  nginx и  PHP.

sudo apt-get install nginx php-fpm

В файле */etc/nginx/nginx.conf* убрать коментарий в строке

multi_accept on

и дописать index.php в определении индексных файлов

index index.php index.html index.htm index.nginx-debian.html;

В файле */etc/nginx/sites-available/default* изменить путь к индексному файлу

root /var/www/html/site1

и разрешить FPM, убрав коментарий

location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
}

Также запретить доступ к файлам, имя которых начинается с префикса .ht

location ~ /\.ht {
deny all;
}

Создать индексный файл сайта

sudo mkdir -p /var/www/html/site1
sudo touch /var/www/html/site1/index.php
sudo echo "<?php phpinfo(); ?>" > /var/www/html/site1/index.php

В файле */etc/php/7.0/fpm/php.ini* исправить значения в строках

memory_limit = 256M
default_socket_timeout = 360

и раскомментировать строки

;user_agent="PHP"
;cgi.fix_pathinfo=1

Отключить уязвимость, поставив значение 0:

cgi.fix_pathinfo=0

Затем перегружаем nginx (любым способом)

systemctl reload nginx
nginx -s reload

Задача решена

Следует иметь в виду, что у свежеперепрошитого устройства на LAN-интерфейсе настроен IP-адрес 192.168.1.1/24. Если используются другие сети, то правим сетевые настройки (возможно, сеанс удалённого входа отвалится, если изменился IP-адрес). Для этого необходимо удалить /etc/network/interfaces (это симлинк на /etc/network/interfaces.firstboot), создать его с необходимым содержимым и перегрузить службу networking:

rm /etc/network/interfaces
touch /etc/network/interfaces
cat << EOF > /etc/network/interfaces
auto lo eth0
iface lo inet loopback

iface eth0 inet dhcp

iface wlan0 inet dhcp
wpa-ssid <имя WiFi-сети>
wpa-psk <ключ WiFi-сети>
EOF
service networking restart
echo "<DNS-сервер>" > /etc/resolv.conf

Изначально настроен только один пользователь — root с паролём debwrt. Из-за того, что при старте таймер времени равен нулю, то есть системные время и дата установлены на полночь 1 января 1970 года (Thu Jan 1 00:00:00 UTC 1970),то при входе ssh’ем (или telnet’ом) система потребует смену пароля. Необходимо выставить правильное время.

date --set="<дата> <месяц> <год> <часы>:<минуты>:<секунды>"
date --set="<номер месяца>/<дата>/<год> <часы>:<минуты>:<секунды>"

Например, на дату опубликования этой заметки актуальной была команда:

date --set="16 January 2018 17:57:00"
date --set="01/16/2018 17:57:00"

service ntp stop
ntpdate time.nist.gov
service ntp start

hwclock -w
hwclock --hctosys

не сработают, так как у системы нет аппаратных часов.

echo "deb http://archive.debian.org/debian squeeze main" > /etc/apt/sources.list
apt-get update
apt-get upgrade

Донастраиваем систему и устанавливаем нужные пакеты:

passwd
hostname <имя узла>
echo "<имя узла>" > /etc/hostname
echo -e "127.0.0.2\t<имя узла>" > /etc/hosts
apt-get install mc sudo most locales bash-completion nload htop ccze telnet wpasupplicant
dpkg-reconfigure locales
dpkg-reconfigure tzdata
adduser <пользователь>
echo -e "<пользователь>\tALL=(ALL:ALL) NOPASSWD: ALL" > /etc/sudoers
apt-get install apache2 php7 mysql-server

При установке в  Virtualbox (как с UEFI, так и без) в самом конце, после заливки всех файлов, когда возникает надпись "Извлеките установочный диски и затем нажмите ENTER" — нажатие этой клавиши (да и любой другой) не даёт эффекта. А в  VMware всё работает.

Неплохой современный дистр, похож на  Deepin чем-то, хотя их сейчас много лепят с однотипными инсталляшками.

Уже делал скрин версии 8.0.4:

Установщик без режима UEFI глючил, при двух гигабайтах памяти система тормозила, пришлось настроить выделение её четырёх гигов. Без заранее созданных разделов на винте программа установки выхватывает ошибки, пришлось запускать GParted перед процессом инсталляции. В /var/log/syslog ничего не пишет, хотя инсталлятор при сообщении об ошибке рекомендует ознакомиться с деталями сей досадной неприятности именно в нём
Ну и хостится проект на не вызывающей большого доверия площадке SourceForge.

Интересно, чем руководствовался разработчик дистра, заставляя пользователя при загрузке с инсталляционного LiveCD входить в систему под именем юзера backslash с пустым паролём (причём пароль могут спросить несколько раз) и запускать руками иксы командой startx, чтобы начать установку?

P. S. Блин, инсталляционный образ весит 4 (четыре) гига! ЧЕТЫРЕ, Карл!.. Распаковывается/скачивается это счастье в 12 гигабайт места.

P. P. S. А, да, при выборе русского языка установщик тоже ошибки генерит.

Возможно, что из-за кривоватых настроек моего сервера Эгея из старого бэкапа сразу работать отказалась (нет баз, не известен пароль к базам и т. д.). Это было, вероятно, тяжкое наследие старой системы, я обновлял её через aptitude dist-upgrade.

Пришлось бэкапить MySQL-базы с наполнением блога, затем переустанавливать заново движок (скачал релиз 2.7, версию 3249), инсталлятор создал новые базы, поверх которых я вытащил из бэкапа мои блоговые статьи, комменты и прочее. Причём начальные таблицы в базе создаются с префиксом ’e2Blog’, нужно не забыть поменять на используемый мной префикс в файле system/defaut/config.php, строка

$_config['db_table_prefix'] = 'e2Blog';

Да, и user/settings.json желательно привести к такому виду

{  "db": {"server": "<узел>","user_name": "<имя>","passw": "<пароль>","name": "<база>"},
    "timezone": {"offset": 10800,"is_dst": false},
    "template": "plain",
    "language": "ru",
    "appearance": {"notes_per_page": 10},
    "comments": {"default_on": true},
    "site_title": "Блог ни о чём",
    "description": "Мысли, факты, цитаты, заметки.",
    "author": "Павел Гладилов",
    "user": {"email": "pavel@gladilov.org.ru"},
    "notifications": {"new_comments": true}  }

Затем выяснилось, что вместо статей открывается страница с ошибкой

Fatal error: Uncaught Error: Call to undefined function dl() in <файл> line <строка>

Пришлось погружать свои ручки в код движка... В результате просмотра кода было найдено решение — замена части кода в ядре движка system/core.php с

if (!extension_loaded('gd')) { if (!dl('gd.so')) { header('Content-type: image/gif'); return false; } }

на

if (!extension_loaded('gd')) { header('Content-type: image/gif'); return false; }

После этого блог заработал, но теперь пропала возможность быстрого сохранения в редакторе по комбинации клавиш Ctrl + Enter (в старых версиях — Ctrl + S) и при попытке движка сформировать или вызвать на редактирование страницу, на которой есть ссылки на несуществующие файлы картинок — открывалась страница с серым фоном и маленьким пустым квадратом посередине. Причём, если такая «кривая» страница открылась — то даже при устранении всех причин всё равно отображается ошибочная страница. Я думаю (но не проверял), что это связано с хранением сгенереных страниц (или их частей) в user/caches/*.psa. Возможно, мне повезло, что со временем истёк срок хранения кешированных «кривых» страниц, и они стали отображаться нормально. Или возникновение такой проблемы как-то связано с разными форматами таблиц старой и новой версии движка. А вообще эту проблему я обошёл с помощью прямой правки заметок в записях таблицы <префикс>Notes, затем там-же стал выставлять атрибут ’Null’ в поле «Uploads» и использовать полный путь к файлам картинок от корня.

В файле user/extras/header-pre.tmpl.php прописываю заголовок для блога — кнопки и .

В файле themes/<имя используемой темы>/templates/layout.tmpl.php рисую верхнее меню:

<?php if ($content['class'] == 'frontpage') { ?>
          <div id="e2-blog-description"><?= $content['blog']['description'] ?></div>
        <?php } ?>
<br />
<table width="650">
<tbody>
<tr>
<td><a href="<ссылка1>"><img src="<картинка1>" style="vertical-align:middle!important" />&amp;&nbsp;<пункт1></a></td>
<td width="15"></td>
<td><a href="<ссылка2>"><img src="<картинка2>" style="vertical-align:middle!important" />&amp;&nbsp;<пункт2></a></td>
<td width="15"></td>
...
<td><a href="<ссылкаN>"><img src="<картинкаN>" style="vertical-align:middle!important" />&amp;&nbsp;<пунктN></a></td>
</tr>
</tbody>
</table>
      </div>
    </div>

Ну и тоже выплывшую при правке system/core.php проблему с невозможностью определить новую картинку для юзера решаю изменением в этом же файле определений DEFAULT_USERPIC_FILENAME и DEFAULT_USERPIC_PLACEHOLDER_FILENAME на путь к моей картинке.

define('DEFAULT_USERPIC_FILENAME','<soul.png>'); define('DEFAULT_USERPIC_PLACEHOLDER_FILENAME','<soul.png>');

Теперь мой блог выглядит приблизительно так: