Следует иметь в виду, что у свежеперепрошитого устройства на 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>');

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

POSIX-совместимые системы имеют специальный стандарт (RFC 3066) определения локали — идентификатора, определяющего региональные настройки пользовательского интерфейса, такие как язык, страна, часовой пояс, набор символов и т. п. Он имеет следующий вид:

[language[_territory][.codeset][@modifier]]

Например — ru_RU.CP1251, el_GR.UTF-8 или en_US.iso88591. Существует особое имя для региональных настроек POSIX: C — нейтральное значение по умолчанию, C.UTF-8 — для новых POSIX-систем с поддержкой UTF-8.

Многие системные программы для определения языка сообщений и вида кодировки используют установленные переменные окружения. По умолчанию переменные LC_ALL и LANG имеют пустые значения, а все остальные — значение «POSIX». В русифицированных системах при настройке локали указывается определенная кириллическая кодировка, например, UTF-8 (Unicode) или реже CP1251 (русскоязычная кодировка Microsoft Windows) или KOI-8 (русскоязычная кодировка UNIX).

Из командной строки управление переменными осуществляется с помощью команд export и env. Чтобы увидеть, какие переменные из вышеописанных и как установлены, можно использовать программу locale. Посмотреть, какие файлы для локализации имеются в системе можно в каталоге /usr/share/locale/, а также выполнив команду locale -a.

[soul@etcetera:~]$ locale
LANG="ru_RU.UTF-8"
LANGUAGE="ru_RU.UTF-8"
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL="ru_RU.UTF-8"
[soul@etcetera:~]$ locale -a
C
C.UTF-8
POSIX
ru_RU.utf8
[soul@etcetera:~]

Разработка объединённого проекта будет вестись под именем OpenWrt, но в соответствии с правилами LEDE, подразумевающими открытый процесс принятия решений с привлечением сообщества, прозрачность взаимодействия разработчиков, регулярный предсказуемый цикл подготовки релизов, первоочередное внимание стабильности дистрибутива, более либеральные правила приёма изменений и получения права коммита. Деятельность, связанная с решением юридических вопросов, сбором пожертвований и распоряжением активами (например, доменом и торговой маркой) нового совместного проекта OpenWrt делегирована некоммерческой организации SPI (Software in the Public Interest), которая также курирует такие проекты, как Debian, Arch Linux, X.Org, 0.A.D, FFmpeg, freedesktop.org и OpenEmbedded.

Старое содержимое репозитория OpenWrt перемещено в архив, но отсутствующие в LEDE патчи, отвечающие требованиям к качеству кода LEDE, будут перенесены в новый репозиторий. Сервисы и элементы инфраструктуры, запущенные в рамках домена lede-project.org, теперь доступны и через домен openwrt.org. Форумы и wiki пока остаются как есть, решение по ним ещё не утверждено.

Поддержка старых выпусков OpenWrt (до 15.05) будет прекращена, а для OpenWrt 15.05 будут предоставляться обновления с исправлением уязвимостей и серьёзных проблем. Поддержка LEDE 17.01 будет обеспечена в полном объёме. В ближайшие несколько месяцев ожидается формирование нового значительного релиза, который выйдет уже под именем OpenWrt.

Выбор в пользу кода LEDE сделан, так как последнее время все новшества и изменения создавались в данном проекте, а разработка OpenWrt практически остановилась после создания форка в 2016 году, когда из проекта ушла группа активных разработчиков, желающих поднять стабильность дистрибутива на новый уровень и избавиться от организационных проблем. Создатели ответвления, которое получило название LEDE, попытались воплотить в жизнь предсказуемый цикл разработки, более либеральные правила приёма изменений и прозрачный процесс принятия решений с привлечением сообщества и проведением публичных обсуждений. Весной 2017 года состоялся первый значительный релиз LEDE, который показал состоятельность проекта.

Новость с Опёнка