AgR^ Live Blog

Проснулся утром и обнаружил что смартфон почему то начал отставать на час. Пошуршав в инете  понял, что это был день перевода часов на зимнее время. Но т.к. зимнее время отменили, то переводить время не надо.
Заодно решил проверить сервера. Что и как там со временем. Оказалось, что и они стали отставать на 1 час. А это совсем плохо. Т.к. там некоторые вещи привязаны ко времени.
Полазив по инету нашёл решение.
Лезем в порты и ставим тайм зону.
>cd /usr/ports/misc/zoneinfo
>make install clean
Далее:
>ln -sf /usr/share/zoneinfo/Etc/GMT-6 /etc/localtime — временная зона для Уфы
и смотрим
>date
vadim# date
воскресенье, 30 октября 2011 г. 22:20:27 (GMT-6)
теперь имеем то, что должны иметь 🙂

UPD: 03-01-2012
Кстати. Вот более правильный метод.
# make -C /usr/ports/misc/zoneinfo install clean
# tzsetup

После этого имеем более правильный формат времени:

# date
среда,  4 января 2012 г. 14:15:06 (YEKT)

После обновления консоли…..ой. После русификации консоли во freebsd, в monitorix перестал обновляться график загруженности системы. В /var/log/monitorix стали сыпаться сообщения:

Fri Jun 10 15:48:04 2011 - SIGTERM caught, exiting.
Died at /usr/local/sbin/monitorix line 58.
Fri Jun 10 15:48:05 2011 - Starting Monitorix version 2.1.2 (pid 23356).
ERROR: while updating /usr/local/share/monitorix/system.rrd: /usr/local/share/monitorix/system.rrd: conversion of '0,
ERROR: while updating /usr/local/share/monitorix/system.rrd: /usr/local/share/monitorix/system.rrd: conversion of '0,
ERROR: while updating /usr/local/share/monitorix/system.rrd: /usr/local/share/monitorix/system.rrd: conversion of '0,
ERROR: while updating /usr/local/share/monitorix/system.rrd: /usr/local/share/monitorix/system.rrd: conversion of '0,
ERROR: while updating /usr/local/share/monitorix/system.rrd: /usr/local/share/monitorix/system.rrd: conversion of '0,
ERROR: while updating /usr/local/share/monitorix/system.rrd: /usr/local/share/monitorix/system.rrd: conversion of '0,
ERROR: while updating /usr/local/share/monitorix/system.rrd: /usr/local/share/monitorix/system.rrd: conversion of '0,
ERROR: while updating /usr/local/share/monitorix/system.rrd: /usr/local/share/monitorix/system.rrd: conversion of '0,
ERROR: while updating /usr/local/share/monitorix/system.rrd: /usr/local/share/monitorix/system.rrd: conversion of '0,
Решил связаться с автором программы. После 3-х часового общения на английском языке(заодно вспомнил), решение было найдено. Всё оказалось ооочень просто. Оказывается в русской локализации, почему-то изменяется разделитель дробной части:
vadim# uptime
15:40 up 2 days, 3:42, 1 user, load averages: 0,01 0,02 0,00
vadim#
Вместо "точки" в инглиш локализации, стоит "запятая" в русском варианте.
Фикс заключается в следующем:
>ee /usr/local/sbin/monitorix
И исправляем следующим образом(добавляем строчку):
require 5.006;

no strict "vars";
no warnings "once";
#use warnings;
use LWP::UserAgent;
use IO::Socket;
use Getopt::Std;
use MIME::Lite;
use POSIX;
use RRDs;
use Cwd 'abs_path';
$ENV{LANG} = ""; <-----вот это добавили(обязательно здесь!!!)
И перезапускаем /usr/local/etc/rc.d/monitorix restart

Через 15 минут статистика стала нормально отображаться. А заодно отправил смал донэйшион автору в размере 3-х евров, ибо честно заработал 🙂

После какого-то очередного обновления, вдруг перестали запускаться php скрипты. Единственное что появлялось, так это одна единственная надпись:

Unknown: apc_fcntl_unlock failed: in Unknown on line 0

Немного покопавшись в инете, решение было найдено:
koms# cd /usr/ports/www/pecl-APC
koms# make config
и включаем! опцию - [X] - SEMAPHORES
koms# make install clean -D "FORCE_PKG_REGISTER"
koms# apachectl restart


Надеюсь это поможет кому-нибудь.:)

Вдруг в какой-то момент как «зачесалось», что хочу консоль в высоком разрешении и всё тут. Ну чтож…Гугл в руки и вперёд. Делать точь в точь по чужим записям — тоже хз чем может обернуться. Поэтому расскажу как есть, что бы избежать подводных камней на которые я наткнулся. Что за камни? Сейчас объясню.
Т.к. я решил не использовать подгружаемые модули, то естественно пришлось собирать новое ядро. А так как я несколько раз делал бинарное обновление!(быстро и просто чтоб не парица с пересборкой), то соответственно исходники остались от версии 7.х. И после сборки и установки ядра — как и полагается получил «кернел паник».
Пришлось взять ЦД с фрёй 8.2 и по новому установить бинарное ядро. Потом идём в /usr/src и удаляем всё!
Копируем с CD новые исходники (можно вручную, можно и через sysinstall установить, кому как нравится).

Это была моя первая попытка изменения разрешения консоли. А теперь вот вторая 🙂


Скопируем GENERIC во что то своё и откроем в редакторе:
cp /sys/i386/conf/GENERIC /sys/i386/conf/AGR
ee /sys/i386/conf/AGR

Добавим эти строчки в конфиг ядра:
options SC_PIXEL_MODE
options SC_NORM_ATTR=(FG_GREEN|BG_BLACK)
options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN)
options SC_KERNEL_CONS_ATTR=(FG_YELLOW|BG_BLACK)
options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED)
options VESA
options VGA_WIDTH90

И запустим сборку:
cd /sys/i386/conf && config AGR && cd ../compile/AGR && make cleandepend && make depend && make && make install

Перезагружаемся...
Проверяем режимы видяхи:
vidcontrol -i mode

Это значение по максисуму:
283 - 1280*1024*32

Добавим его в rc.conf
echo allscreens_flags="MODE_283">> /etc/rc.conf

Перезагружаемся ещё раз.
И радуемся новому виду консоли, в которой теперь приятно сидеть.

Недавно заметил, что на сайте перестали отображаться и создаваться png изображения. А случилось это видимо после какого-то очередного обновления.
Дооооолго вспоминал что же я делал чтобы вернуть работоспособность. И вот вспомнив и проделав нижеследующее, я получил положительный результат.

Итак вот волшебное слово:

>portupgrade -fr graphics/png

That’s all…

Здесь я просто выложу (как памятку) какие функции PHP  на что и как менять.


ereg():

0 - Оставить все без изменений.
1-4 Включить одну из функций.
7 - Включить сразу все функции.


Тем самым мы включаем поддержку старых функций, при этом новые будут отключены.

Ну вот и всё пока.

После месяца использования PHP5.3 , выяснилось что неправильно стала работать гвестбука и форум. Начнём с гостевой http://amigas.ru/webserverdata/gb/index.php . Стоит она (inDEV) у меня уже очень очень давно и хотелось бы её оставить на память но в рабочем варианте. Но при её открытии стало выдаваться следующее:

Deprecated: Function split() is deprecated in /data/sites/my-www/webserverdata/gb/engine/guest.php on line 29
Deprecated: Function split() is deprecated in /data/sites/my-www/webserverdata/gb/engine/guest.php on line 29
Deprecated: Function split() is deprecated in /data/sites/my-www/webserverdata/gb/engine/guest.php on line 29
Deprecated: Function split() is deprecated in /data/sites/my-www/webserverdata/gb/engine/guest.php on line 29
Deprecated: Function split() is deprecated in /data/sites/my-www/webserverdata/gb/engine/guest.php on line 29
Deprecated: Function split() is deprecated in /data/sites/my-www/webserverdata/gb/engine/guest.php on line 29
Deprecated: Function split() is deprecated in /data/sites/my-www/webserverdata/gb/engine/guest.php on line 29

Количество сообщений об ошибке как оказалось зависит от количества записей в гостевой. Ну что-же… Будем исправлять. На сайте пыхи советуют заменить устаревшую функцию split на preg_split. Идём в quest.php и находим строку 29. Вот она:

list($date,$ip,$name,$email,$site,$msg) = split(«@@@»,$ln[$stop]);

изменяем её так:

list($date,$ip,$name,$email,$site,$msg) = preg_split(«@@@»,$ln[$stop]);

При попытке захода в гостевую получаем следующую ошибку:

Warning: preg_split() [function.preg-split]: Unknown modifier ‘@’ in /data/sites/my-www/webserverdata/gb/engine/guest.php on line 29
Warning: preg_split() [function.preg-split]: Unknown modifier ‘@’ in /data/sites/my-www/webserverdata/gb/engine/guest.php on line 29
Warning: preg_split() [function.preg-split]: Unknown modifier ‘@’ in /data/sites/my-www/webserverdata/gb/engine/guest.php on line 29
Warning: preg_split() [function.preg-split]: Unknown modifier ‘@’ in /data/sites/my-www/webserverdata/gb/engine/guest.php on line 29
Warning: preg_split() [function.preg-split]: Unknown modifier ‘@’ in /data/sites/my-www/webserverdata/gb/engine/guest.php on line 29
Warning: preg_split() [function.preg-split]: Unknown modifier ‘@’ in /data/sites/my-www/webserverdata/gb/engine/guest.php on line 29
Warning: preg_split() [function.preg-split]: Unknown modifier ‘@’ in /data/sites/my-www/webserverdata/gb/engine/guest.php on line 29

Ну что же опять топаем на сайт php.net  и читаем вдумчиво и ещё раз 5 также. А потом долго думаем. И о эврика!!!!! Пробуем так:

list($date,$ip,$name,$email,$site,$msg) = preg_split(«/@@@/»,$ln[$stop]);

И наконец то всё заработало как надо! Что изменилось? Да просто добавили пару слэшей «/» в функцию preg_split.

Ну вот и всё пока. Надеюсь мой опыт хоть кому-то поможет.

Понадобилось както опять поднять NTP сервер (сервер синхронизации времени) чтобы на всех машинках в конторе было одинаковое время и народ бы не сваливал раньше времени на обед или домой. Но по прошествии времени всё уже позабылось. И вот решил написать как памятку себе, т.к единственное что помню — только то что были какие-то «грабли» с обновлением времени с интернетовских серверов.


rc.conf

restrict default ignore                              # Запрещаем всем сверяться с нашим сервером
restrict 127.0.0.1
# restrict 10.0.0.233
restrict 194.149.67.130 noquery notrap             # Разрешаем этим машинкам исправлять наше время
restrict 212.82.32.26 noquery notrap
restrict 132.239.1.6 noquery notrap
restrict 192.43.244.18 noquery notrap
restrict 10.0.0.0 mask 255.0.0.0 nomodify notrap       # А этим (т.е. локалке) можно сверяться с нами


Вот и вспомнил из-за чего была проблема! При указании в ntp.conf доменного адреса вместо IP адреса — сервер просто не находит сервера откуда обновлять время. Как один из вариантов это указание IP адреса или же (этот вариант не пробовал) указать в /etc/hosts пару <IP-доменное имя> всех серверов откуда пытаемся синхронизировать время.

Итак встала задача в конторе переехать с ворованного ххххххпрокси на бесплатный со всеми текущими настройками каждого пользователя. Перебрав варианта 3-4 различных прокси серверов, мой выбор пал на 3PROXY (http://3proxy.ru). Синтаксис у oops, squid,etc почти что одинаков, а вот у 3proxy со своим оригинальным синтаксисом и возможностями известными только автору — пришлось курить маны, факи и хауту, чтобы написать работоспособный конфиг под своих юзеров. Кстати. У 3proxy мне очень понравилось — быстрая установка и запуск, а также переносимость конфига с минимальными изменениями UNIX <-> Windows.

Итак задача. Пустить в инет 25 юзеров — авторизация по IP и по логину с пассвордом. Каждому юзеру канал определённой «толщины «, или же один канал на несколько пользователей(например для бухгалтеров). Ограничение времени работы (только в рабочее время). В выходные скорость в рабочее время для всех по минимуму (2-3кб/сек). Несколько фильтров ресурсов (список запрещённых ресурсов и список разрешённых ресурсов). Весь трафик идёт через вышестоящий прокси в другом филиале. TCP и UDP портмаппинг(можно через вышестоящий прокси(если такое возможно) а можно и напрямую).

Далее…

Ну вот и пришло время когда появился PHP5.3.x в портах FREEBSD. Ну и раз появилось то и появилось желание обновиться и опробовать. До этого пробовал на винде версию 5.3 и как оказалось многие скрипты просто стали неработоспособными, что и пугает. Но мы то эти самые матёрые , которые нихера не боятся трудностей. Да и с прогрессом стараюсь идти в ногу )наступая на грабли и оказываясь в полной жопе(
Итак начнём:

1. Для начала обновим порты:
>portsnap fetch update
2. Идём в /usr/ports/UPDATING и видим что там предлагают сделать с пыхой. Удалить
- php5-dbase
- php5-ncurses
- php5-pcre
- php5-spl
- php5-ming
- php5-mhash
и пересобрать php5.
Что собственно и делаем:
>pkg_delete -f php5-dbase php5-ncurses php5-pcre php5-spl php5-ming php5-mhash
>portupgrade -u php5
>apachectl restart - чтобы апач подцепил пыху5.3.2
Вот и всё по первому пункту.
3. Ну вот и начались проблемы. Первое что бросилось в глаза так это ругань на дату. После поиска и прочтения описания изменений - наступает просветление.
Идём в
>ee /usr/local/etc/php.ini
и добавляем строчку - date.timezone = "Asia/Yekaterinburg".
Свою таймзону найти можно на сайте PHP.

И о чудо. 70% скриптов ожило. А 30% всё ещё выёживается. Для меня были важны фотогалерея на coppermine, блог на wordpress, и wr-scripts(форум,доска объявлений,итд). И они как ни странно заработали. Ну а с остальными будем разбираться потихоньку.