if DirectoryExists('/home/'+Memo_users.Lines[i]+'/Рабочий стол/') then
Вроде как unicode-строки надо конвертировать в системную кодировку (к примеру, KOI8-R)
И еще я заметил, что вы вместо системных вызовов используете вызовы сторонних программ (для записи в файл, удаления файлов), имхо, код получится намного стройнее и аккуратнее с системными вызовами.
Работа по оптимизации кода еще не проводилась. Так было написано в изначальном коде - я лишь продолжил в том же духе. Естественно, эта работа будет потом проведена постепенно. Про временные файлы полностью согласен. К следующему релизу поправим.
Вроде как unicode-строки надо конвертировать в системную кодировку (к примеру, KOI8-R). Это как и зачем?
Всех с релизом 0.0.2!
Вроде как unicode-строки надо конвертировать в системную кодировку (к примеру, KOI8-R). Это как и зачем?
На системах с кодировкой, отличной от той на которой осществлялась сборка приложения, вместо 'Рабочий стол' вы рискуете получить мусор.
Тут проблем нету - приложение onli Russian Mandriva и проживет до тех пор, пока нормально нет портируют NetworkManager. Так что я лично нужды поддержки non-UTF8 не вижу.
Тут проблем нету - приложение onli Russian Mandriva и проживет до тех пор, пока нормально нет портируют NetworkManager. Так что я лично нужды поддержки non-UTF8 не вижу.
А разве при установке пользователь Russian Mandriva не может указать кодировкой KOI8-R, или, не дай бог, CP-1251?
Тут проблем нету - приложение onli Russian Mandriva и проживет до тех пор, пока нормально нет портируют NetworkManager. Так что я лично нужды поддержки non-UTF8 не вижу.
А разве при установке пользователь Russian Mandriva не может указать кодировкой KOI8-R, или, не дай бог, CP-1251?
Может, но я пока не встречал большого процента таких "отклонений".
Может, но я пока не встречал большого процента таких "отклонений".
Тоже не вижу особой необходимости суетиться. Так как программа написана для новичков, которые про кодировку слыхом не слышали. У таких пользователей utf8 - 99%. А та группа пользователей, у которых кодировка отлична от utf8, этой программой пользоваться не будут, а сами ручками все настроят, потому что умные, раз догадались как кодировку менять. Вот как-то так.
http://wiki.edumandriva.ru/wiki/index.php/...D0%B8%D1%8F/Lab
подвел итог работы проекта за период с 1 апреля 2009 года по сегодняшний день и поставил задачи для дальнейшего развития проекта.
здесь на форуме также принимаются замечания и предложения.
grival64, попробуйте тест с отсутствующим пакетом pptp-linux, но дождитесь все же первого запущенного vpnpptp, не запуская второго еще.
и вывод команды urpmi --auto pptp-linux с отсутствующим пакетом pptp-linux выложите здесь для анализа.
urpmi --auto pptp-linux >> /opt/vpnpptp/tmp - выполните эту команду и файл /opt/vpnpptp/tmp выложите тоже сюда для анализа (только не пустой).
Запуск vpnpptp при отсутствующем pptp-linux:
- запрос авторизации
- сообщение "Запуск конфигуратора VPN PPTP может занять некоторое время если в системе не установлен паке pptp-linux"
- нажатие ОК
- сообщение "Невозможно настроить VPN PPTP в связи с отсутствием пакета pptp-linux и невозможностью его автоматической установкой"
- нажатие ОК
- завершение работы vpnpptp
[user1@localhost ~]$ sudo urpmi --auto pptp-linux >> /home/user1/pptp_tmp.txt
Установка не удалась, отсутствуют некоторые файлы:
ftp://mirror.yandex.ru/mandriva/official/2010.0/i586/media/main/release/pptp-linux-1.7.2-3mdv2010.0.i586.rpm
Возможно, необходимо обновить базу данных urpmi
Непонятно зачем запускать установку urpmi --auto pptp-linux если Интернета еще нет,
да и источники еще могут быть не настроены. А пакет, при его наличии, устанавливается простым запуском
из файлового менеджера.
В релиз 0.0.2 добавлено:
- директорией для временных файлов является /tmp,
- теперь каждый процесс использует только свой временной файл,
- vpnpptp и ponoff теперь сами проверяют под каким пользователем они запущены и откажутся работать не под root или не под live (раньше лишь в gui был такой запрет) - это усилило безопасность проекта в целом, а также исключило ошибки падений программы при запуске от простых пользователей, связанных с отсутствием у них прав на то или иное действие, выполняемое алгоритмом программы.
Тест в live-режиме прошел успешно - никогда еще выход в интернет через vpn без установки операционки не был таким простым.
Но есть одно но: из 10 тестов в live-режиме лишь в одном случае ponoff и vpnpptp через пакет vpnpptp-0.0.1-4edm2010.0.i586.rpm появился в Меню. При сборке пакетов учтите это. Скорее всего дело в несрабатывании автообновления Меню и Рабочего стола. На рабочем столе ярлыки появлялись лишь при нажатии на F5.
Непонятно зачем запускать установку urpmi --auto pptp-linux если Интернета еще нет,
да и источники еще могут быть не настроены. А пакет, при его наличии, устанавливается простым запуском
из файлового менеджера.
тем не менее так правильнее, а пакет может быть получен и при ненастроенном через пакет vpnpptp интернете, к примеру, через модем или как у меня, через другого провайдера.
к тому же отсутствие пакета pptp-linux в последних версиях мандривы не наблюдается, поэтому vpn поднимется легко и без задержки на его поиск и установку.
у кого мандрива 2009 - потестируйте тоже релиз 0.0.2 - теоретически должно работать. права же на запуск vpnpptp и ponoff проверит теперь сама программа.
Результаты теста релиза 0.0.2 на двух сетевых картах и двух провайдерах: на одной сетевой карте vpn, а на другой только вводится ип, маска, шлюз, днс.
На eth0 настроен провайдер с vpn, а на eth1 - провайдер без vpn. Дополнительные маршруты в конфигураторе прописал сразу для обоих провайдеров.
При работе программы не выявлено чтобы каким-либо образом страдал провайдер, привязанный к eth1. Особенно при работе в штатном режиме.
При аварии vpn быстро поднимается, но это никак не влияет на другого провайдера. Ifconfig всегда сообщает о том, что провайдер на eth1 нормально функционирует. Но вот NetApplet при работе в нештатном режиме (имеет место хотя бы одна авария) нагло врет, показывая, что провайдер на eth1 отключен.
Поэтому можно сказать, что модуль ponoff предположительно не задевает другие сетевые карты, однако индикация NetApplet не всегда соответствует действительности.
Результаты теста релиза 0.0.2 на двух сетевых картах и двух провайдерах: на одной сетевой карте vpn, а на другой только вводится ип, маска, шлюз, днс.
На eth0 настроен провайдер с vpn, а на eth1 - провайдер без vpn. Дополнительные маршруты в конфигураторе прописал сразу для обоих провайдеров.
При работе программы не выявлено чтобы каким-либо образом страдал провайдер, привязанный к eth1. Особенно при работе в штатном режиме.
При аварии vpn быстро поднимается, но это никак не влияет на другого провайдера. Ifconfig всегда сообщает о том, что провайдер на eth1 нормально функционирует. Но вот NetApplet при работе в нештатном режиме (имеет место хотя бы одна авария) нагло врет, показывая, что провайдер на eth1 отключен.
Поэтому можно сказать, что модуль ponoff предположительно не задевает другие сетевые карты, однако индикация NetApplet не всегда соответствует действительности.
Давай тогда до завтра подождем и я пускаю пакет в релиз - svn я сам обновлю сегодня (там с trunk проблема)
Забыли иконки on.ico и off.ico положить в /opt/vpnpptp и сделать бы ярлык для конфигуратора на рабочем столе - было бы вообще здорово.
Comment[ru]=Настройка соединения VPN PPTP - добавить такую строку для vpnpptp в spec-файл, а то подсказка неруссифицирована.
Иконки и подсказку поправил. На рабочий стол можно добавить, но это достаточно сложно сделать из-за разных принципов в рабочих столах (нуи не приветствуется это) - так что пока без нее.
Иконки и подсказку поправил. На рабочий стол можно добавить, но это достаточно сложно сделать из-за разных принципов в рабочих столах (нуи не приветствуется это) - так что пока без нее.
сделайте хотя бы такой ярлык на рабочем столе только для live-пользователя. в остальном все ок.
Иконки и подсказку поправил. На рабочий стол можно добавить, но это достаточно сложно сделать из-за разных принципов в рабочих столах (нуи не приветствуется это) - так что пока без нее.
сделайте хотя бы такой ярлык на рабочем столе только для live-пользователя. в остальном все ок.
Для релиза 0.0.3 уже написал:
- проверка корректности вводимых пользователем в конфигураторе данных,
- разрешено пользователям самим задавать время дозвона (максимальное время ожидания ответа провайдера на звонок) в пределах от 5 до 255 сек,
- разрешено пользователям самим задавать время реконнекта (время реакции на пропадание соединения) в пределах от 1 до 255 сек,
- разрешены 10 сетевых карт от eth0 до eth9.
Вопрос: ограничиться ли для MTU только лишь табличкой http://ru.wikipedia.org/wiki/MTU :576,1500, 1492, 2272, 4464, 4500 ? Каких значений не хватает и какие явно лишние? Или разрешить диапазон какой-нибудь?
romkaromka не хватает 1460. А разве более 1500 через pptp пойдёт?
дайте ссылку на офиц. источник какие mtu пойдут раз в википедии не то.
мне надо определить разрешенные для пользователей, чтобы они ввели их сами, значения mtu.
добавил (версия 0.0.3 beta1):
- теперь для mtu разрешен диапазон [576..1460..1492..1500], рекомендуется 1460.
- поправлен недочет автоматического определения сетевого интерфейса и шлюза локальной сети в конфигураторе, если пытаться настроить vpn на ethN, где 0<N>10 (то есть если сетевой интерфейс отличен от eth0, то есть имеет меньший приоритет).
в разработке:
- реконнект будет опционален, на выбор пользователя будет предложено 2 варианта:
1) при пропадании vpn выйти из программы и при выходе падать до тех пор, пока какой-нибудь следующий по приоритету интерфейс самостоятельно не примет на себя задачу дефолтного интерфейса (в том числе и тот интерфейс, на котором упало vpn, также будет участвовать в конкурсе на роль дефолтного интерфейса опционально), то есть делается попытка вернуть состояние системы в состояние до момента запуска vpn, а при неудаче - на ближайшем по приоритету интерфейсе, при отсутствии же последнего сеть будет считаться опущенной на всех интерфейсах.
2) при пропадании vpn, как и в предыдущих версиях программы, ждать появления технической возможности поднятия vpn, но пока происходит такое ожидание - временно поднять сеть на каком-нибудь следующем по приоритету интерфейсу, который самостоятельно примет на себя задачу дефолтного интерфейса (в том числе и тот интерфейс, на котором упало vpn, также будет участвовать в конкурсе на роль дефолтного интерфейса опционально), то есть делается попытка вернуть состояние системы в состояние до момента запуска vpn, а при неудаче - на ближайшем по приоритету интерфейсе, при отсутствии же последнего сеть будет считаться опущенной на всех интерфейсах. Однако, в отличии от первого варианта реконнекта программа будет ждать появления технической возможности поднятия vpn, на том интерфейсе, на котором он был сконфигурирован, и при ее появлении поднимать vpn, покидая временный интерфейс, если он был активирован.
- теперь сколько бы в системе не было сетевых интерфейсов, программа будет бережно обращаться с ними со всеми, сама их не задевать, а если их задевает сам процесс pppd (а именно он их и задевает, так как самостоятельно выполняет скрипты ip-up, ip-down), то программа исправит за ним его ошибки, поэтому в любой момент времени сеть на чем-нибудь будет поднята (если только реально есть на чем поднять сеть).
- появляется возможность автоматического переключения на другого провайдера, идущего в порядке очередности по приоритету сетевого устройства, на котором он был закреплен.
Оба варианта реконнекта удобны тем, что при падении vpn, если авария не критическая, то локальная сеть на сет. устройстве, где упало vpn, должна продолжить свою работу (планирую опцию возможности отключения для этого случая и локальной сети), но если критическая, то прекратят работать и vpn, и локальная сеть, при этом начнут работать другие сетевые интерфейсы, а значит в этом случае появляется возможность автоматического переключения на другого провайдера.
Один сетевой интерфейс - это лишь частный случай для программы. В современном мире это уже редкость.
Аксиома1: сетевые интерфейсы (ethN) eth0-eth9 различаются по приоритету. Чем больше N, тем меньше приоритет у сетевого устройства. Система самостоятельно решает в какой момент времени какой сет. интерфейс будет дефолтным исходя из его приоритета и его state. Это правило одного дефолтного интерфейса (в системе может быть лишь один дефолтный шлюз).
Имеется состояние системы А. Мы переводим его из состояния А в состояние Б посредством демона pppd. При переводе из А в Б демон pppd самостоятельно использует инструкцию АБ, а при переводе из Б в А – самостоятельно инструкцию БА. Демон pppd также самостоятельно обнаруживает падение поднятого им же vpn и при этом переводит состояние системы из Б в А через инструкцию БА. Но а что если теперь состояние интерфейса А изменилось? В этом случае демон pppd сделает грубые ошибки – это критический баг демона pppd – походу он не умеет отслеживать state.
Решение: подсунуть демону pppd такую инструкцию БА, при выполнении которой никаких изменений не произойдет (обычную пустышку) и самостоятельно в программе обработать корректный перевод из Б в А с учетом state интерфейса А. Система же, потеряв интерфейс ppp, самостоятельно найдет ближайший подходящий интерфейс, учитывая аксиому1. От нас лишь требуется запомнить и бережно хранить инструкцию БА.
Пока это лишь теория.
