nightfly

ну почему же не реально 1. пробегаемся скриптом по табличке `users`, смотрим, что у нас там лежит в `login` 2. запоминаем какой был 3. придумываем какой хочем 4. синхронно меняем по всем связанным табличкам типа `phones`, `address` итд.. мне стоит начинать лекцию на тему вывезения в лес и вручения в руки лопаты? спиз...ть МАС - ровно настолько же трудоемко как и логин с паролем. Так что это чисто карательный вопрос, а не техногенный. Не заморачивайтесь - в 2013 году пользователю совершенно не обязательно вообще знать, что у него вообще есть какой-то логин или пароль.

Никак - такого функционала и в самом stargazer нету. Пользователь stargazer - является базовой сущностью со множественными связями. Единственное, что могу предположить - это тушить stargazer и колбасить по базе неким астральным скриптом, который будет менять логины в каких-то из 82 табличек Энивей - это довольно странное желание. На будущее - начиная с 0.3.4 есть опции генерации логинов. Если авторизация с авторизатором - то они и так свои адовые логины знают, а автозаполнение в браузерах/запоминание паролей никто не отменял. Если же для авторизации оконечных абонентов используетс

Значит вы сеть нарисовали начиная с .9 По умолчанию макро {ROUTERS} в шаблонах DHCP указывает на начальную айпишку ассоциированной сети+1.

бред сивой кобылы - максимум, что параметром к интерпретеру передавали, там да, только r требуется. Там не в чем быть правым либо не правым - это базовые вещи для понимания. Можно было бы и осилить.

это ничего, что 666 это ниразу не execute? на измене чего-то делать чревато.

natd - уже не просто юзерспейсный труп, он уже и попахивать начал. Как-то так: http://www.lissyara.su/articles/freebsd/tuning/ipfw_nat/

мсьє знають толк у збоченнях

Мои глаза говорят вам спасибо

Мда, его внезапно заколбасило в одну строку PS Кстати без зеленой подсветки выглядит лучше.

"Лучший ответ" своим стилем ломает работу как минимум тега "code". Выглядит это как-то так: http://www.piclod.com/s/460 И нет, пока пост не стал "лучшим" - он выглядел вполне себе нормально.

ну это понятно блин, ну нельзя же так - мну почти до истерики довели, уже собрался тестовую ферму собирать чтобы повторить "мистический" баг

Чисто из любопытства более-менее повторил вашу топологию на виртуалках. Поставился с нуля на 8.2 i386 offline KMOD. Все работает практически из коробки. В rc.conf никакой магии: gateway_enable="YES" hostname="test.loc" ifconfig_em0="DHCP" ifconfig_em1="inet 192.168.56.2 netmask 255.255.255.0" ifconfig_em2="inet 192.168.1.1 netmask 255.255.252.0" inetd_enable="YES" keymap="ua.koi8-u" sshd_enable="YES" # ====== added by UBinstaller ==== #all needed services mysql_enable="YES" apache22_enable="YES" dhcpd_enable="YES" dhcpd_flags="-q" dhcpd_conf="/usr/local/etc/multinet/dhcpd.conf" dhcpd_ifac

не-не-не, какое там переустановлю! Просто берете и делаете: cd /sys/amd64/conf/ && config UBNAS64 && cd ../compile/UBNAS64 && make cleandepend && make depend && make && make install && echo > /boot/loader.conf предварительно положив в /sys/amd64/conf/ файло UBNAS64 с содержанием см. выше.

Сдаюсь. Такого точно не бывает. Называется найдите 10 отличий. 06000 2326315286 886610211516 nat 1 ip from table(2) to not table(9) via igb1 06001 3378718348 3947554627589 nat 1 ip from any to x.x.x.x via igb1 12000 2337453327 891723818035 pipe tablearg ip from table(3) to any via igb0 in 12001 3293690279 3937711958522 pipe tablearg ip from any to table(4) via igb0 out 65533 16082980 2266951448 deny ip from table(2) to any via igb0 65534 21 1544 deny ip from any to table(2) via igb0 65535 11015356 4924658299 allow ip from any to any Судя по всему пакеты ваших пользователей успешно пр

Если посмотреть в ipfw show юзера вообще проходят по правилам 12002 и 12003? Я просто реально не вижу причины по которой юзера вообще могут попадать в конечный deny (без него все ведь работает, да?) Сравнил - конфиги практически идентичны моим рабочим. Единственное, что я не использую в продакшне на х64 подгрузку всего модулями - вот единственное отличие. NAS-ы конфигуряться штатным скриптом который перебирает ядро с таким вот конфигом: include GENERIC ident UBNAS64 options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE options

#ugly hack ${FwCMD} add 12002 allow ip from any to table\(4\) via em0 out ${FwCMD} add 12003 allow ip from table\(3\) to any via em0 in А если сделать попутно так? Хотя по факту pipe сам по себе должен отлично работать как allow при one.pass.

Мда. Все нормально. И так точно не бывает - пакеты прошедшие по рулесам 12000 и 12001, в принципе не могут попадать в 65533 и далее. 10.4.161.1 от юзера я так понимаю тоже не пингается?

Данунафиг, это нереально. Судя по всему у вас банально ничего не попадает в 6000 рулес. А rc.conf еще покажите и ipfw nat 1 show

да понял уже таки net.inet.ip.fw.one_pass: 1 сделайте. Я понятия не имею почему он у вас в 0 выставлен.

Если у вас самоцель использовать авторизатор для того, чтобы подымать пользователей (хотя нахрен он нужен, если прибивку по MAC используете?) думаю очевидно, что перед дефолтным полиси, должно быть что-то типа ${FwCMD} add 65530 allow all from table\(2\) to 192.168.0.1 via em0 ${FwCMD} add 65531 allow all from 192.168.0.1 to table\(2\) via em0 (допускаю, что stargazer крутиться на 192.168.0.1) у вас не net.inet.ip.fw.one_pass: 1 почему-то. Все должно работать "изкоробки" при включенном AlwaysOnline исходя только из наличия правильного MAC.

Да, они умеют

"c" кирилическая. Как-то так.

Нет. Не возникало. Думаю это потому, что остальные, удачно заполнили UBILLING_SERIAL в uhw.ini и позаботились, чтобы в alter.ini REMOTEAPI_ENABLED был включен, как это сделано по умолчанию.

Таки дослідили, для чого 47 табличку призначено? Як мало людям для щастя треба.

Посмотрите GetCF - минуты на две сделать из него "получалку телефона". Телефоны юзеров хранятся в табличке phones в виде: login => phone => mobile