from:"Igor Chumak"

26.06.2012 23:26, Артём Н. пишет:

26.06.2012 23:26, Dmitrii Kashin пишет:

Артём Н.artio...@yandex.ru writes:

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

Не надо переобределять глобальные переменные в теле программы.
Один раз установили при старте сценария - и больше не трогаете.

Ну так, это не переменные, а константы.

Если поведение функций зависит исключительно от этих переменных - Вы тем
самым обеспечите их чистоту. Чем не вариант?

Не очень хорошо, что интерфейс функции разбит на две части.

К тому же, функция их использующая, не совсем рентабельна: её не
всегда возможно вызвать без лишних движений из самой себя или из
внешней функции, если та пользуется теми же переменными (например,
придётся использовать стек или локальные переменные для сохранения
глобальных перед вызовом).
Для констант, хотя, это не актуально..? O.o
Но, тем не менее, получается, что интерфейс функции не сосредоточен
в одном месте, а в какой-то степени разбросан, что не есть хорошо (и
естественно, связность между функцией и внешним окружением
повышается).

Не понял ничего. Снизойдите.

o.O Что непонятного? Если про переменные говорить?
1. Есть функция, которая вызывает другую функцию. В обеих используется одна и та
же переменная (не для связи между ними). Если внутренняя функция её
переопределяет, внешняя должна сохранять.
С архитектурой совсем плохо. Зачем переопределять глобальную переменную,
если ее же переопределять нельзя, потому что если переопределили - надо
восстановить?

В bash есть и локальные переменные ;)

В общем случае (к башу неприменимо)
ещё с многопоточностью проблемы будут. Вообще-то, это везде написано... Надо
объяснять? Для констант неприменимо.
2. Глобальная переменная может быть случайно переопределена где угодно. Кстати,
даже непреднамеренно (ну eval какой-нибудь неправильно использовал или что ещё).
Поиск ошибки затянется. В случае с readonly - проблема отпадает.
Задавайте значения глобальных переменных таким образом , чем не аналог
read-only переменных?

#!/bin/bash
SET()
{
var=$1
val=$2
echo set $var to $val
eval $var=$val
}

SET ZZ_aa abc
echo $ZZ_aa

Попытки сдуру переопределить переменную ловятся grep'ом

3. Ещё раз про интерфейс. Касается и констант. Он разбит на две части. Это
значит, что одна переменная может влиять на несколько функций сразу, что может
привести к побочным эффектам и трудноуловимым ошибкам (в общем случае). Когда, с
параметром функции всё понятно (если функция чистая, т.е. без побочных
эффектов): изменил, сдохла, - проблема в ней или вызываемых с этими параметрами.
Здесь: изменил, сдохла, проблема может быть в нескольких функциях, использующих
переменную, или в их взаимодействии. Это первое.
Второе из первого. Не сразу очевидно какая функция, какую переменную использует.
Без глобальных констант, если есть иерархия вызовов, понятно какая функция, что
использует ещё на верхнем уровне. В случае использования глобальных констант -
непонятно. Значит, нужно использовать поиск (например, разбирая скрипт), чтобы
найти какая переменная в какой функции используется. Понимание усложняется.
Но в bash нет именованных параметров у функций. При их наличии, такого вопроса,
скорее всего, не возникло бы.

Если задача решается средствами шелла плохо и сложно - надо либо менять
постановку задачи, либо инструмент.

Re: Несколько вопросов вразброс


26.06.2012 20:14, Артём Н. пишет:

26.06.2012 12:54, Igor Chumak пишет:

25.06.2012 18:03, Артём Н. пишет:

Я наворачиваю не для того, чтобы круто на баш написать и не из-за проблем с
головой, а для того, чтобы попробовать TDD (или хотя бы просто unit тесты) там,
где его обычно не используют... На перспективу. Пока что, не особенно хорошо
получается. :-)



Было бы интересно посмотреть.

Да что там интересного? Я только пытаюсь, пока-что. Взял небольшую задачу,
которую требуется выполнить. Конкретно: требуется бэкап-скрипт. Но нужно
сохранять не только иерархию каталогов, но и некоторые служебные данные: LVM,
LUKS заголовки, дамп БД и т.п.. Причём, используя для бэкапа тот же самый
rdiff-backup, который используется для сохранения каталогов.
Каталоги для сохранения - в отдельном списке.

Развернуть bacula будет быстрее ;)


На очереди задачка побольше, поэтому думаю, стоит попробовать на совсем 
небольшом.
Для этого я сделал:
1. Функцию assert:
###TESTING
assert()
# $1 - message;
# $2 - comannd.
{
echo Command: $2
eval $2 || { echo $1  exit 1; }
return 0;
}
###/TESTING

2. Теги ###TESTING ###/TESTING.
Не мудрствуя лукаво, реализовав обработку на awk:
#!/bin/sh

fl=$1
fl=${-:-$fl}

awk '
BEGIN {
   prf = 0;
}

/^#!\/bin\/bash/ {
   print #!/bin/sh;
   next;
}

/###TESTING/ {
   prf = pfm + 1;
   next;
}

/###\/TESTING/ {
   if (prf == 0)
   {
  print Error: unexpected ###\/TESTING  /dev/stderr;
  exit 1;
   }
   prf = prf - 1;
   next;
}

{
   if (prf == 0) print;
}

END {
   if (prf  0)
   {
  print Error: unclosed ###TESTING;
  exit 1;
   }
}
' $fl


Это мы проверяем скрипт на связность тегов ###TESTING и ###/TESTING?
А смысл?
grep ###/*TESTING script.sh выведет теги на экран, глаз несвязность и 
так заметит. Единоразово прокатит, а автоматически проверять - не вижу 
смысла.

3. Функцию dbg со товарищи, для вывода сообщений, соответствующих уровню
разговорчивости:
dbg()
# $1 - verbosity level;
# $2 - message.
{
[ $V_LEVEL -ge $1 ]  echo $2  /dev/stderr
}

err()
# $1 - message.
{
dbg 1 $1
dbg 0 Backup failed... # failed...  exit 1
return 1
}

Вложенные функции (в функции сохранения служебной информации каждое действие
оформлено маленькой функцией, вложенной в основную) проверяются модульными
тестами внутри функции-родителя (в тегах ###TESTING).
Каждая внешняя функция проверяется в главной функции, заменяющей реальную 
главную.
(Например, вызывается main, которая переопределяется в тегах ###TESTING, на
вызов тестирующей функции).

В итоге получается какой-то намёк на модульные тесты, плюс на что-то
интегративное.

Внутри каждой тестирующей функции проверяется правильное поведение и реакция на
ошибку (в случае ошибки, функция должна возвращать свой код отличный от нуля или
$?, если была выполнена команда перед завершением). Ну и граничные условия,
если имеются.
К примеру:
assert backup_kernel_conf error 0 backup_kernel_conf bla-bla-bla...
\$PWD/_config\||true
assert backup_kernel_conf error 1 backup_kernel_conf \$LINUX_CONFIG\
\$PWD/_config\

Сделано грязновато, но хоть что-то... К TDD это относится мало. Разве что, я
пытаюсь вначале писать тесты.

Собственно, на этом всё.


Как-то все сложно.. Зачем TDD в обертке вокруг rdiff-backup? Я вижу 
процесс архивирования так:

прочитали конфиг || свалились по ошибке
запустили pre-backup скрипт || свалились по ошибке
запустили backup || свалились по ошибке
запустили post-backup скрипт || свалились по ошибке
обновили каталог || свалились по ошибке
отправили уведомления

не вижу я здесь места для 100500 вложенных функций с кучей параметров ;)




--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4feac2bb.2040...@gmail.com

Re: Несколько вопросов вразброс

27.06.2012 17:29, Артём Н. пишет:

27.06.2012 12:22, Igor Chumak пишет:

26.06.2012 20:14, Артём Н. пишет:

26.06.2012 12:54, Igor Chumak пишет:

25.06.2012 18:03, Артём Н. пишет:

Я наворачиваю не для того, чтобы круто на баш написать и не из-за проблем с
головой, а для того, чтобы попробовать TDD (или хотя бы просто unit тесты) там,
где его обычно не используют... На перспективу. Пока что, не особенно хорошо
получается. :-)

Было бы интересно посмотреть.

Да что там интересного? Я только пытаюсь, пока-что. Взял небольшую задачу,
которую требуется выполнить. Конкретно: требуется бэкап-скрипт. Но нужно
сохранять не только иерархию каталогов, но и некоторые служебные данные: LVM,
LUKS заголовки, дамп БД и т.п.. Причём, используя для бэкапа тот же самый
rdiff-backup, который используется для сохранения каталогов.
Каталоги для сохранения - в отдельном списке.

Развернуть bacula будет быстрее ;)

Но не лучше:
1. Bacula Не подходит для такой простой задачи.
2. Всё, что мне нужно, делает rdiff-backup.
3. Сделав, используя готовое решение, я не получу того, что мне нужно.

Это мы проверяем скрипт на связность тегов ###TESTING и ###/TESTING?
А смысл?

Это я вырезаю всё, что между тегами. Смысл - убрать всю тестирующую фигню и
получить на выходе готовый скрипт.

grep ###/*TESTING script.sh выведет теги на экран, глаз несвязность и так
заметит. Единоразово прокатит, а автоматически проверять - не вижу смысла.

См. выше.

ИМХО автоматическое генерирование скриптов - еще 1 способ выстрелить
себе в ногу ;)

Как-то все сложно.. Зачем TDD в обертке вокруг rdiff-backup?

Ради изучения TDD.

Я вижу процесс
архивирования так:
прочитали конфиг || свалились по ошибке
запустили pre-backup скрипт || свалились по ошибке

Он состоит из нескольких независимых действий. Как отследить все ошибки?
Действия очень даже зависимые. Если свалились при ошибке при чтении
конфига - нет смысла в дальнейшем выполнении. Не отработал pre-backup -
не прошел дамп mysql'я - нет смысла в backup'e, ибо неизвестно что в
него попадет

И т.д.

запустили backup || свалились по ошибке

Так и делаю. Сам backup - просто запуск rdiff-backup с нужными параметрами.

Но есть два типа бэкапа: полный и декрементальный. Скрипт должен определить
какой делать (к примеру, в случае полного бэкапа, не нужно удалять старые (да,
если запустить rdiff-backup --remove-older-than, он сам определит нужно ли
удалять, но так неинтересно)).

Это да.. ;)

-куть

не вижу я здесь места для 100500 вложенных функций с кучей параметров ;)

Там и нету 100500. Всего два уровня. :-)

Что-то мне сдается, что TDD в этой задаче не к месту. Инструмент должен
упрощать жизнь, а не усложнять.

Re: Несколько вопросов вразброс

27.06.2012 17:20, Артём Н. пишет

-куть

С архитектурой совсем плохо. Зачем переопределять глобальную переменную, если ее
же переопределять нельзя, потому что если переопределили - надо восстановить?
В bash есть и локальные переменные ;)

Facepalm. Я не использую глобальные _переменные_ там, где не нужно. В данном
случае, я их не использую вообще. Это не мой случай. Это ответ на вопрос.

Есть функция, которая вызывает другую функцию. В обеих используется одна и та
же переменная (не для связи между ними). Если внутренняя функция её
переопределяет, внешняя должна сохранять.

Это не о глобальной переменной?

Задавайте значения глобальных переменных таким образом , чем не аналог read-only
переменных?
#!/bin/bash
SET()
{
var=$1
val=$2
echo set $var to $val
eval $var=$val
}

SET ZZ_aa abc
echo $ZZ_aa

Попытки сдуру переопределить переменную ловятся grep'ом

1. Для начала надо понять, что ошибка связана с переопределением.

Вот он - способ отловить переопределения

2. Я не конкретно про bash писал.
3. А кто сказал, что в общем случае имя переменной не может динамически
формироваться?

А зачем придумывать способы написания стрёмного кода?
Если динамически формировать имя переменной нежелательно по каким-то
причинам - этого ведь можно избежать?

Если задача решается средствами шелла плохо и сложно - надо либо менять
постановку задачи, либо инструмент.

Задача, как раз, для шелла. Просто именованные параметры, как мне кажется, были
бы не лишними. :-)

Это шеллозависимое хотение ;) Ассоциативные массивы есть не везде. А для
управления backup'ом достаточно и соглашения об именовании.

Re: Несколько вопросов вразброс


25.06.2012 17:56, Andrey Rahmatullin пишет:

On Mon, Jun 25, 2012 at 05:52:35PM +0300, Igor Chumak wrote:

ООП как лекарство ;)
класс с конструктором, где парсится конфиг, и функцией, отдающей
значение параметра. Все в одном месте. Read only параметры -
отдельно, read-write - отдельно. Дефолтные значения - отдельно.
+Предупреждения при попытке прострелить себе ногу.

Это всё в баше?


;) на баше свет клином не сошелся.
PS. Я видел способ, как писать на баше в ООП-стиле


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fe97553.4030...@gmail.com

Re: Несколько вопросов вразброс

25.06.2012 18:03, Артём Н. пишет:

25.06.2012 18:52, Igor Chumak пишет:

ООП как лекарство ;)
класс с конструктором, где парсится конфиг, и функцией, отдающей значение
параметра. Все в одном месте. Read only параметры - отдельно, read-write -
отдельно. Дефолтные значения - отдельно. +Предупреждения при попытке прострелить
себе ногу.

Ну да, в теории. А на практике? ООП - хорошо (там, где возможно штатными
средствами), но ведь им всё не исчерпывается. К тому же, у ООП свои проблемы. И
там абсолютно тоже самое. Плюс, ещё и надо тестировать объект (помимо, каждого
метода). А плохая архитектура может сделать любую программу неподъёмной. Пример
для ООП - почти любая RAD, например Delphi и аналоги. Чистое ООП. И что? Если не
брать в расчёт откровенную фигню (типа Button1Click, который, не меняют на
нормальное имя), часто получается процедурный стиль в объектной обёртке.
Это от программиста зависит, как он будет использовать инструмент. Если
готовая иерархия классов его устраивает - зачем усложнять себе жызнь? ;)

Но под bash я такой среды не знаю, да и ООП под ним - это изврат.

Было бы интересно посмотреть.

Re: Несколько вопросов вразброс

26.06.2012 20:22 пользователь Артём Н. artio...@yandex.ru написал:

26.06.2012 17:40, Artem Chuprina пишет:
Артём Н. - debian-russian@lists.debian.org @ Mon, 25 Jun 2012
18:26:49 +0400:

Если именно из конфига, то правильный подход - иметь один вход для
параметров, прочитанных из конфига. Там, где в языке есть
встроенные
хэши, обычно удобнее хэш, где нету - специальную функцию, которую
можно
позвать с именем параметра, а она вернет значение.
АН Пожалуй, так и сделаю. Ассоц. массивы в bash есть. В dash, вроде,
тоже
АН поддерживаются.

Ну, все-таки в шеллах традиционно используют . /path/to/config и
отдельный префикс для своих переменных. Зачитывают обычно не в каждой
функции, а один раз на скрипт. Зачастую еще прикрыв проверкой на
определенность переменной вроде

if [ -z $MY_VAR ]; then . /path/to/config; fi

А если проект настолько велик, что этот метод становится неуправляемым,
то его уже не надо писать на шелле - это там будет не самое
трудноуправляемое место, гораздо хуже будет с обработкой ошибок.
Хм... Может, лучше сделать массив PARAMS и обычную загрузку через source?
Т.е., грубо говоря, писать в конфиге не CFG_PARAM=123, а
PARAMS[CFG_PARAM]=123...

А в чем разница? Букв в коде больше, удобство использование - одинаковое.
Как по мне, в шелле удобнее всего читать параметры через source , ну и
префикс чтобы был одинаковый. Ну и после чтения параметров выполнить
проверку на валидность (отследить пустые, некорректные значения )

Re: Несколько вопросов вразброс

26.06.2012 20:18 пользователь Артём Н. artio...@yandex.ru написал:

25.06.2012 22:30, Alexander Danilov пишет:
25.06.2012 18:56, Артём Н. пишет:
25.06.2012 18:48, Alexander Danilov пишет:
25.06.2012 18:39, Артём Н. пишет:
...
У меня, последнее время, постоянный когнитивный диссонанс: я не
понимаю, как
нужно делать. O_O
+1
-1. В совокупности со всем прочим, меня так и тянет напиться и
забыться. :-(

+2. Я это проходил. Как оказывается, общение с такими вот шедеврами
хоть и тяжко,
но всё же имеет и положительные моменты - немного повышается
самооценка. Когда
покопаешься в таком коде, то как-то спокойно даже становится,
понимаешь, что до
Линуса или Кнута тебе далеко,
но даже ты, с твоим небольшим опытом такого бы не написал.
У меня самооценка повышается с отрицательным коэффициентом.
Люди пишут такую херню. А им за это платят. И немалые бабки. А ещё
приходится с
этим работать... :-(
Вот сегодня пытался разобраться с нижним уровнем. Лютый край. Пример:
есть
сервер БД. Гордо названная программка BaseWriter, которая получает
данные и
складывает их в каталог. Каталог задаётся в параметрах. Оно использует
конфиг.
Файл конфига задаётся в параметрах. Почему нельзя было засунуть этот
несчастный
каталог в конфиг, не загромождая параметры - первая мысль?
И это самое невинное решение...

Если бы программистам платили за красоту кода... ;)

Re: Несколько вопросов вразброс

2012-06-25 Пенетрантность Igor Chumak

24.06.2012 23:29, Артём Н. пишет:

24.06.2012 23:08, igor Chumak пишет:

Правильно так, как удобно. Возможно, удобно будет возиться с
глобальными переменными, возможно удобно будет делать в ООП-стиле..
Зависит от задачи и от программиста ;)

ООП там точно нет. Там маленький скрипт, просто я вдруг приплёл к нему тесты.
Делаю небольшими функциями.
И дело не в конкретном скрипте, а в подходе.
С глобальными переменными, которые используются в нескольких функциях, в
общем-то понятно. Но здесь не совсем переменные.
Т.е., например, если есть команда, которую, в принципе, может когда-то
потребоваться изменить (ну не знаю, инструмент поменяется, к примеру), её удобно
сделать глобальной переменной. Но, фактически, это константа.
А, если есть какой-нибудь пользователь MySQL, например, который используется в
одном месте, но читается только при загрузке конфига? Что с ним делать?
Передавать его функции, которая вызывает другую функцию, передавая, как параметр
этой функции или просто использовать в конечной функции какой-нибудь глобальный
$MYSQL_UNAME?

Как-то все сложно.. Я за глобальные переменные/глобальный класс,
смотря какой стиль больше нравится ;)

Re: Несколько вопросов вразброс

2012-06-25 Пенетрантность Igor Chumak

25.06.2012 17:45, Артём Н. пишет:

25.06.2012 14:37, Dmitrii Kashin пишет:

Как загружать в bash-скрипт исходные данные - это дело вкуса.
Но в общем случае, имхо, вполне нормально иметь первые несколько строчек
в виде:

MYVAR='default value'
source default-config.sh
source ~/.user-config.sh

Дело не в том, как загружать, а в том, как использовать.
Загрузка, обычно (если не требуется какая-то сложная обработка) - средствами
bash, как вы и показали. По-моему, тоже: придумывать велосипед смысла нет.

Плохо соображаю и не могу выбрать.
Минус - при их использовании, увеличивается связность.

Не понял аргумент про связность.

Глобальные переменные сильно увеличивают связность и вероятность появления
ошибок, в результате их случайного переопределения, например. К тому же, функция
их использующая, не совсем рентабельна: её не всегда возможно вызвать без лишних
движений из самой себя или из внешней функции, если та пользуется теми же
переменными (например, придётся использовать стек или локальные переменные для
сохранения глобальных перед вызовом).
Для констант, хотя, это не актуально..? O.o
Но, тем не менее, получается, что интерфейс функции не сосредоточен в одном
месте, а в какой-то степени разбросан, что не есть хорошо (и естественно,
связность между функцией и внешним окружением повышается).

ООП как лекарство ;)
класс с конструктором, где парсится конфиг, и функцией, отдающей
значение параметра. Все в одном месте. Read only параметры - отдельно,
read-write - отдельно. Дефолтные значения - отдельно. +Предупреждения
при попытке прострелить себе ногу.

Re: Несколько вопросов вразброс

2012-06-24 Пенетрантность igor Chumak

В Sun, 24 Jun 2012 21:26:10 +0400
Артём Н. artio...@yandex.ru пишет:

Небольшой вопрос по скриптам.
Если у меня есть функция, которая требует много параметров, напрямую
с ней не связанных (т.е., к примеру, она вызывает вложенные функции),
нормально ли это - использовать глобальные константы?
Т.е., они, вроде как, не совсем константы: один загружаются, при
чтении конфига, после чего не меняются.
Плохо соображаю и не могу выбрать.
Минус - при их использовании, увеличивается связность.
Плюс - мне не нужно передавать в функцию 100500 параметров.
А если мне нужно протестировать функцию, я всегда могу их заменить...
И не нужно передавать кучу слабосвязанных параметров.
Вообще, как правильно?

Re: Настройка доступности компьютеров через доменные имена

2012-06-14 Пенетрантность Igor Chumak


14.06.2012 10:13, Victor Wagner пишет:

On 2012.06.14 at 09:20:31 +0400, Dmitrii Kashin wrote:


Igor Chumakichumak2...@gmail.com  writes:


Для протокола http(s) - легко. Reverse proxy (nginx,Apache) в помощь.

Если не купит дополнительные адреса, с https легко не будет.

Если браузеры поддерживают расширение TLS SNI (Server Name Indication)
то будет. А сейчас уже по-моему большинство поддерживает.




Я делал так: между клиентом и прокси - https (с общим на все домены 
самоподписанным сертификатом); между прокси и компами за NAT - http (ибо 
было некритично).



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fd9abe7.3080...@gmail.com

Re: Настройка доступности компьютеров через доменные имена

2012-06-13 Пенетрантность Igor Chumak

Для протокола http(s) - легко. Reverse proxy (nginx,Apache) в помощь.

12.06.2012 21:05 пользователь Konstantin Fadeyev jred...@gmail.com
написал:

 Да ладно вам.
 Вопрос был как имея статический ип и доменное имя к нему прикрученное,
 сделать так чтоб при обращении на имена comp1.domname.ru,
 comp2.domname.ru запрос уходил на соответствующие машины за НАТом, а
 не на одну и туже машину куда проброшены порты на роутере.

 --
 Константин Фадеев

Re: Система централизованного управления и мониторинга

2011-11-08 Пенетрантность Igor Chumak


06.11.2011 20:48, Евгений Верещагин пишет:

Да, собственно Windows в моей сети занимает далеко не малую долю. И каждый раз 
бегать перенастраивать всякую ересь надоело, а samba-домен многое не умеет (да 
и вообще вин-домен не умеет).

Чего не умеет делать с виндовыми клиентами Active Directory?



А Puppet только через cygwin, как-то костыли чувствуются :-(

Есть Puppet. Если нужно настолько всеобъемлющее управление.

--
Константин Фадеев



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4eb928c8.4010...@gmail.com

Re: почтовый сервер для маленькой компании

2011-09-15 Пенетрантность Igor Chumak


08.09.2011 19:18, alexander barakin пишет:

On Thu, Sep 08, 2011 at 05:29:09PM +0300, Igor Chumak wrote:

07.09.2011 20:32, Anton пишет:

почтовый сервер для маленькой компании
с удобным интерфейсом управления
есть ли рекомендации


Про communigate никто не вспомнил..

а главное — не вспомнили ни про kerio mailserver, ни даже про exchange!
и это в рассылке русскоязычных пользователей debian gnu/linux!


Компания насколько маленькая, что без exchange никак? ;))

Еще citadel бывает..



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e71ec5f.6070...@gmail.com

Re: почтовый сервер для маленькой компании

2011-09-08 Пенетрантность Igor Chumak


07.09.2011 20:32, Anton пишет:

почтовый сервер для маленькой компании
с удобным интерфейсом управления
есть ли рекомендации


Про communigate никто не вспомнил..

google в руки - и будет вам 100500 решений


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e68d135.8050...@gmail.com

Re: Есть ли в Linux/Debian генераторы сканов российских паспортов?

2011-09-06 Пенетрантность Igor Chumak


06.09.2011 10:56, Konstantin Matyukhin пишет:

Подлог - это преступление.


Скан паспорта имеет юридическую силу?


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e65d769.6050...@gmail.com

Re: Есть ли в Linux/Debian генераторы сканов российских паспортов?

2011-09-06 Пенетрантность Igor Chumak

06.09.2011 12:06, Konstantin Matyukhin пишет:

2011/9/6 Igor Chumakichumak2...@gmail.com:

06.09.2011 10:56, Konstantin Matyukhin пишет:

Подлог - это преступление.

Скан паспорта имеет юридическую силу?

Извините, что отвечаю вопросом на вопрос. А имеет ли юридическую
силу фотография в вашем паспорте?

Фотография в паспорте - просто фотография
Паспорт установленного образца (в т.ч. с фотографией) == документ,
удостоверяющий личность. Подлинность паспорта достаточно просто
проверить (любой ППСник на улице это умеет ;)). Паспорт выдает на руки
серьезная гос. контора. Паспорт существует в единственном экземпляре.

Скан паспорта - хз что это такое. Любой, у кого есть сканер, может
наделать любое количество сканов. Любой , у кого есть фотошоп, может..
много чего он может.

Вот и вопрос - кому и зачем он нужен, скан паспорта? И в чем мегасмысл
его подделки? По скану паспорта кредит можно взять? ;)

Re: Есть ли в Linux/Debian генераторы сканов российских паспортов?

2011-09-06 Пенетрантность Igor Chumak


06.09.2011 14:54, Andrey Rahmatullin пишет:

On Tue, Sep 06, 2011 at 02:14:10PM +0300, Igor Chumak wrote:

Скан паспорта - хз что это такое.  Любой, у кого есть сканер, может
наделать любое количество сканов. Любой , у кого есть фотошоп,
может.. много чего он может.

Вот и вопрос - кому и зачем он нужен, скан паспорта? И в чем
мегасмысл его подделки? По скану паспорта кредит можно взять? ;)

Вы тоже не читали оригинальное письмо?


Читал, но не понял, что такое palpay ;)


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e661130.8050...@gmail.com

Re: альтернативы LDAP

2011-08-16 Пенетрантность Igor Chumak


16.08.2011 14:37, Ed пишет:

On 08/09/11 21:06, Ivan Shmakov wrote:

Edsp...@yandex.ru  writes:


  чем больше вожусь я с LDAP, тем меньше он мне нравится ;)

Любопытно, чем именно?


в первую очередь тем, что не встречал нормального инструментария для 
управления каталогом.



ldapvi + phpldapadmin + gosa (в порядке возрастания user-friendly ;) )


ну и если честно - каждый раз, когда я сталкиваюсь со схемами, у меня 
возникает мысль надо почитать документаию, только никак не соберусь 
соответствующие RFC читать, а другой документации не встречал.




Обычно достаточно знания для реализации XXX нужна схема YYY.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e4a5c35.5020...@gmail.com

Re: qtnotifydaemon

2011-08-12 Пенетрантность Igor Chumak


11.08.2011 18:16, Andrey Rahmatullin пишет:

On Thu, Aug 11, 2011 at 06:09:56PM +0300, Igor Chumak wrote:

Хочу предложить что бы добавили в репозитарий дебиана вот эту прогу
http://drull.org.ru/qtnotifydaemon/,
подскажите, плз, сайт где можно это сделать?

А в чем разница с libnotify-bin ?

Это сервер.


notification-daemon - не оно?

ЗЫ: На сервере debian, на десктопе ubuntu, уведомления с сервера 
отрисовываются.. Дополнительных софтин не ставил



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e44df2c.9000...@gmail.com

Re: qtnotifydaemon

2011-08-11 Пенетрантность Igor Chumak


11.08.2011 17:46, Pavel Gaidai пишет:

Привет Всем!

Хочу предложить что бы добавили в репозитарий дебиана вот эту прогу
http://drull.org.ru/qtnotifydaemon/,
подскажите, плз, сайт где можно это сделать?


А в чем разница с libnotify-bin ?


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e43f0c4.8080...@gmail.com

Re: postfix forwardings

2011-08-08 Пенетрантность Igor Chumak


08.08.2011 09:28, Andrey N. Prokofiev пишет:

День добрый. Имею postfix с юзерами в субд mysql. Там же и адреса пересылок.
К примеру есть адрес для пересылки в виде: mail...@example.com -
us...@example.com,us...@example.com

Необходимо сделать так, чтобы на адрес mail...@example.com можно было
послать письмо только из внутренней сети (либо как вариант с адресов в
домене example.com). Хочется сделать это на уровне флага в таблице базы
данных. Как сие реализовать?


В http://www.postfix.org/RESTRICTION_CLASS_README.html (Protecting 
internal email distribution lists) описан очень похожий случай. Только 
вместо таблиц .db надо использовать mysql



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e3f89c0.2040...@gmail.com

Re: обновление с обределенного интерфейса

2011-08-02 Пенетрантность Igor Chumak


02.08.2011 12:32, Anatoliy Kushner пишет:
есть сервер с несколькими интерфейсами, какой опцией можно сказать 
apt-get-у на какой интерфейс биндиться при отсылке запросов ?



Если вопрос именно так проставлен (apt-get+bind interface) - вряд ли. Но 
если добавить прослойку в виде прокси.. squid точно умеет.



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e38051f.1060...@gmail.com

Re: Fwd: 2 wifi карты

2011-07-28 Пенетрантность Igor Chumak


28.07.2011 18:11, Roman Sergeyev пишет:

да нету никакого прокси, был бы - написал

28 июля 2011 г. 21:10 пользователь Roman Sergeyevopri4n...@gmail.com  написал:

да нету никакого прокси, был бы - написал

28 июля 2011 г. 21:07 пользователь Andrey Rahmatullinw...@wrar.name  написал:

On Thu, Jul 28, 2011 at 08:39:20PM +0600, Roman Sergeyev wrote:

Может быть кто-нибудь все-таки поможет дельным советом?

Вы уже выяснили, прокси у вас или нет?

--
WBR, wRAR




--
de RN9RQ ex RA9QCE





tcpdump в руки ;)

tcpdump -i wlan1 -n
и ping 192.168.0.1
должны чего-то показать.

Все ж не понятно - работает или не работает. Если смущает встроенная 
карточка - отключете ее (rmmod, modprobe, blacklist)



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e317f82.3050...@gmail.com

Re: autofs

2011-07-21 Пенетрантность Igor Chumak


21.07.2011 10:31, sergio пишет:

On 07/20/2011 04:00 PM, Artem Chuprina wrote:


В /etc/auto.master сказано
/misc   /etc/auto.misc  --timeout=4

Я никогда не понимал, как можно использовать автомаунтеры. Как можно быть
уверенным, что устройство размонтировано, если ещё нужно время на сброс
буферов?



Бывают read-ony файловые системы


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e27dd6d.2080...@gmail.com

Re: autofs

2011-07-21 Пенетрантность Igor Chumak


21.07.2011 11:11, Mikhail A Antonov пишет:

21.07.2011 12:03, Igor Chumak пишет:

21.07.2011 10:31, sergio пишет:

On 07/20/2011 04:00 PM, Artem Chuprina wrote:


В /etc/auto.master сказано
/misc   /etc/auto.misc  --timeout=4

Я никогда не понимал, как можно использовать автомаунтеры. Как можно быть
уверенным, что устройство размонтировано, если ещё нужно время на сброс
буферов?



Бывают read-ony файловые системы


И часто ты с такими сталкиваешься? А обычный пользователь?



CD-ROM


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e27dfa2.1070...@gmail.com

Re: Доступ к машине за nat

2011-06-24 Пенетрантность Igor Chumak

24.06.2011 18:52, Ed пишет:

Дано:
1. linux-host (A) у меня под боком, со статическим IP.
2. много десятков удалённых linux-хостов (B1, B2, ); на них есть
доступ в интернет, возможно с серым ip-адресом (например GPRS);

все хосты в моём полном распоряжении.

Требуется:
иметь воможность организовать ssh-сессию с A на любой из Bx.

Как это лучше организовать?

Я знаю два решения:
- openvpn;
- reverse ssh port forwarding.

openvpn пользуюсь сейчас, в режиме static key, не нравится количество
телодвижений на добавление нового туннеля.

переход на клиент/серверные сертификаты по-моему ситуацию не исправит.

Почему же?
Серверный сертификат генерится 1 (один) раз

Подключение клиента = генерация сертификата+генерация конфига
(опционально) + копирование

ssh также с первого взгляда не очень удобен в конфигурации с
множеством клиентов.
Подключение клиента = генерация пары ключей + копирование публичного
ключа на сервер + копирование приватного ключа клиенту + придумывание
уникального номера порта

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

может быть я просмотрел какое-то простое и удобное решение?

Все автоматизируется..

Re: The Linux Security Circus: On GUI isolation

2011-06-23 Пенетрантность Igor Chumak


23.06.2011 12:31, Artem Chuprina пишет:

Здравствуйте. Прочитал интересную статью про безопасноть X-сервера.
http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
Проверил, у меня работает, как описано. Это получается что любая прога в
рамках запущенного X-сервера может слушать что я ввожу. Только мне кажется это
огромной дырой в безопасности?

Да.  Если ты запускаешь что попало в своем X-сервере, то лучше просто знать,
что кто угодно может что угодно, чем не знать.  Поскольку для работы им все
равно нужно мочь.  Не с клавиатуры, так из selection, но нужно.


Очень удобно, что клавиатурный сниффер уже включен в дистрибутив ;)


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e030b11.2070...@gmail.com

Re: The Linux Security Circus: On GUI isolation

2011-06-23 Пенетрантность Igor Chumak


23.06.2011 13:52, duk пишет:

http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
Проверил, у меня работает, как описано. Это получается что любая прога в
рамках запущенного X-сервера может слушать что я ввожу. Только мне кажется это
огромной дырой в безопасности?


Не желаю офтопить, но такой вопрос, на гуя мне выделять Х другим пользователям?

Серьёзно, для каких целей я поставлю Х-сервер на линию и дам кому-то
доступ?

Это уж вам виднее ;) Странная постановка вопроса. У всех задачи разные

   По вашему мнению, есть какие-то приложения, что нуждаются в Х
сервировке?

chromium-browser например

Если есть, то можно ли запретить пользование Х консолем в
таком случае?  И будет ли это примитивным решением вышеуказанной
проблемы безопасности?
Пользуясь этой фичей, администратор системы может спокойно тырить 
пользовательские пароли. Не все же серфят lynx'ом из xterm'а ;)



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e032414.1050...@gmail.com

Re: Отдельная файлопомойка и её взаимодействие с доменом Samba

2011-06-20 Пенетрантность Igor Chumak


20.06.2011 12:45, evgeny_ver...@mail.ru пишет:
Есть PDC на LDAP+Samba. Нужно рядом поднять файлопомойку для 
пользователей этого же домена. Как поступить лучше:

1. Файлопомойку авторизовать в Samba
2. Файлопомойку авторизовать в LDAP
3. Саму машину с файлопомойкой завести в LDAP
4. Просто экспортировать по NFS папки файлопомойки на сервер домена

Ессно, требуется доменная авторизация и раздача прав на папки.Об 
недоступности одно из хостов речи нет, обе машины находятся в 
виртуалках на одной железной ноде.




PDC и файлопомойку желательно разнести по разным нодам, ага

http://www.samba.org/samba/docs/man/Samba-Guide/unixclients.html - 
включение в существующий домен сервера SAMBA





--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dff1cc8.2070...@gmail.com

Re: регистратор в з оне ru

2011-06-15 Пенетрантность Igor Chumak


14.06.2011 16:48, Dmitry E. Oboukhov пишет:

Разве может единожды зарегистрированный домен освободиться? Их же скупают
тут же.

Нет.

самые крутые киберсквоттеры у нас сами регистраторы. уж сколько
скандалов было на эту тему а все бестолку


Дык все логично. Регистраторы - торговцы воздухом; кто не согласен - 
пусть объяснит разницу в цене доменов .ru, .com, .ua ;)
Если у них нет служб, занимающихся отслеживанием нужных доменов - 
значит их надо срочно создавать ;)) И скупать им ничего не нужно - 
зачем покупать воздух у самого себя.



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4df850a1.4040...@gmail.com

Re: apache+x.509+alias на другой домен

2011-06-15 Пенетрантность Igor Chumak

14.06.2011 14:58, Nicholas пишет:

On 14.06.2011 15:02, Alexander GQ Gerasiov wrote:

Можно
google://openssl dns subjectAltName

Спасибо.

On 13.06.2011 18:55, Pavel Ammosov wrote:
Ну или apache и использовать ProxyPass с аналогинчым синтаксисом.
Для клиентской авторизации? Для неё используются сертификаты
клиентов, не сервера.

On 13.06.2011 20:13, Чумак Игорь wrote:
на сервере с основной_домен.ком - прокси или mod_rewrite
и использовать для авторизации (а не только для https) сертификат для
основной_домен.ком
Кто, на чем и каким образом будет авторизоваться?
Сколько сертификатов будут в этой схеме задействованы?

Да, ProxyPass видимо то что надо.

Сервер сам будет выступать в качестве клиента платежных систем и тд,
для этого нужны сертификаты (и для https - так что так что их 2-4 будет)

Надеюсь с ProxyPass они заработают.

Спасибо.

Я бы все равно попробовал бы откорректировать ТЗ.
2 набора сертификатов (клиентских и серверных), 2 разных сервера и
миграция данных в час 0 - как-то более предсказуемо. ИМХО.

Re: vpn-client

2011-06-06 Пенетрантность Igor Chumak


06.06.2011 16:18, Timothy Silent пишет:

On Mon, 6 Jun 2011 16:57:36 +0400
Konstantin Matyukhin wrote:


2011/6/6 Grey Fenrirgrey.fen...@gmail.com:

Я думаю, у провайдера проблем нету, проблемы где-то у меня с
руками... Под офтопом этот vpn работает (люди говорят, я не
пробовал).



и ping 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
затяжное и безрезультатное раздумье


при уже установленном VPN-соединении.




Догда посмотрите
ping 192.168.100.2
ping 8.8.8.8

tcpdump -n -i ppp0 при работающем ping'е

iptables-save на предмет настроек файрвола


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4decdc2d.1090...@gmail.com

Re: 2 канала интернета

2011-06-01 Пенетрантность Igor Chumak


01.06.2011 12:13, skele...@lissyara.su пишет:
Возникло несколько вопросов по данной статье. Дело в том, что у меня 
поднимается 2 ppp соединения через USB модемы. Вот вывод касательно их 
адресов:


~$ /sbin/ifconfig | grep inet | grep 'Mask:255.255.255.255'
  inet addr:195.128.XX.XX  P-t-P:195.128.XX.XX 
Mask:255.255.255.255

  inet addr:77.52.YY.YY  P-t-P:80.255.YY.YY  Mask:255.255.255.255

А теперь вопрос: что мне прописывать в переменных P1_NET и P2_NET ?


Возьмите shorewall; через него настройка 2 линков выглядит более человечно.
http://shorewall.net/MultiISP.html


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de604bb.8000...@gmail.com

Re: mount.cifs и хранение пароля


30.05.2011 23:46, Stanislav Maslovski пишет:
-cut

Правильное решение с точки зрения безопасности в данной задаче - это
вместо предоставления доступа линукс-машине к ресурсам
виндовс-сервера, предоставить доступ виндовс-серверу к ресурсам
линукс-машины. Например, подложить виндовому шедулеру скрипт, который
по (s)ftp в определенное время будет забирать готовый файл бэкапа с
линукс-машины.

В добавление: сгодится даже анонимный ftp (или tftp) с
ограничением доступа к линукс-машине просто по IP, если бэкапы
выкладывать зашифрованными открытым ключём (предполагается, что
секретный ключ и доступ к виндовс-серверу есть у лица, ответственного
за восстановление из бэкапа).

Тогда, пожалуй, пора прекращать конструировать лисапет и развернуть 
bakula ;)



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de48c12.2080...@gmail.com

Re: 2 канала интернета


31.05.2011 15:35, skele...@lissyara.su пишет:
Возникла задача: реализовать доступность сервера одновременно по 2-м 
каналам. Какие вообще есть варианты реализации данной задачи?


ПС. Без применения динамической маршрутизации, конечно же :)



Смотря что подразумевать под словом одновременно

2 канала, 2 IP адреса, 2 A-записи в DNS, указывающие на разные адреса - 
один из вариантов.



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de4e98b.4060...@gmail.com

Re: 2 канала интернета


31.05.2011 16:35, skele...@lissyara.su пишет:
А что скажите насчёт использования iproute2? Получиться ли реализовать 
данную задачу?


Мне бы не столько round-robin, сколько доступность сервера из мира 
одновременно с 2-х каналов.

Что есть одновременно?
Пакеты одной tcp-сессии должны бежать параллельно по обоим каналам?
Или TCP-сессия может быть установлена по любому каналу?
Или там воще не будет TCP?



31.05.2011 15:35, skele...@lissyara.su пишет:

Возникла задача: реализовать доступность сервера одновременно по 2-м
каналам. Какие вообще есть варианты реализации данной задачи?

ПС. Без применения динамической маршрутизации, конечно же :)








--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de4f012.6030...@gmail.com

Re: 2 канала интернета


31.05.2011 16:47, skele...@lissyara.su пишет:
Одновременно, это значит: что если мы постучались из мира по 1-му 
каналу (ssh, ftp, webm vpn) соединение успешно установилось, 
поработали. Потом захотели постучаться по другому каналу - и в этом 
случае соединение тоже установилось и мы тоже смогли одновременно 
поработать.

Думаю объяснил доходчиво.

Дык iproute2 + 2 IP адреса
Подключаетесь к которому хотите и работайте.



31.05.2011 16:41, Igor Chumak пишет:

31.05.2011 16:35, skele...@lissyara.su пишет:



Что есть одновременно?
Пакеты одной tcp-сессии должны бежать параллельно по обоим каналам?
Или TCP-сессия может быть установлена по любому каналу?
Или там воще не будет TCP?







--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de4f24d.1010...@gmail.com

Re: 2 канала интернета


31.05.2011 16:35, Mikhail A Antonov пишет:

31.05.2011 17:30, Korona Auto Ltd./ Andrey N. Prokofiev пишет:

31.05.2011 17:13, Igor Chumak пишет:


2 A-записи в DNS, указывающие на разные адреса -
один из вариантов.


игра в наперсток.


Честно говоря задача сама по себе без динамической маршрутизации
предполагает что будет именно игра в напёрсток. Если один канал
отвалился - работать будет, но тормоза при каждом следующем подключении
будут давать о себе знать т.к. клиент будет стучаться в сдохший канал.
Как вариант - поставить маленькое время жизни DNS-записи дабы можно было
оперативно убрать ссылку на сдохший канал. Других вариантов я как-то не
особо вижу.


Да, в сдохший канал клиент будет стучаться с вероятностью 50%


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de4f8fb.8050...@gmail.com

Re: mount.cifs и хранение пароля


28.05.2011 08:41, Stanislav Maslovski пишет:

On Wed, May 25, 2011 at 03:04:22PM +, Evgeniy Vidyakov wrote:

Хранение бэкапов организовано на Widows сервере. Шара монтируется скриптом 
строчкой на подобии:
  mount.cifs //server/share /mnt/server -o 
iocharset=utf8,credentials=/root/.smbpass,dom=DOMAIN.LOCAL
Не нравится, что пароли в открытом текстовом виде. Возможно ли при монтировании получать 
их из какого-нибудь закрытого зашифрованного источника?

Чтобы зашифрованный пароль расшифровать, потребуется другой пароль
или ключ, и т.д.
Это понятно. А нет ли возможности хранить не пароль, а его хеш, ведь при 
авторизации на windows-сервере, насколько я знаю, используется хеш?


mount.cifs так не умеет - разработчики samba считают, что 
credentials=/root/.smbpass - достаточно хорошо ;)



Возможно, существуют патчи, реализующие авторизацию по хешу, но я не нашел.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de3495a.80...@gmail.com

Re: mount.cifs и хранение пароля


30.05.2011 11:02, alexander barakin пишет:

2011/5/30 Igor Chumakichumak2...@gmail.com:

28.05.2011 08:41, Stanislav Maslovski пишет:

On Wed, May 25, 2011 at 03:04:22PM +, Evgeniy Vidyakov wrote:

Хранение бэкапов организовано на Widows сервере. Шара монтируется
скриптом строчкой на подобии:
  mount.cifs //server/share /mnt/server -o
iocharset=utf8,credentials=/root/.smbpass,dom=DOMAIN.LOCAL
Не нравится, что пароли в открытом текстовом виде. Возможно ли при
монтировании получать их из какого-нибудь закрытого зашифрованного
источника?

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

Это понятно. А нет ли возможности хранить не пароль, а его хеш, ведь при
авторизации на windows-сервере, насколько я знаю, используется хеш?

если для авторизации достаточно наличия хэша, то чем же хранение этого
хэша будет отличаться от хранения пароля (с точки зрения
безопасности)?


Пароль по хешу восстановить тяжело.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de3522f.7000...@gmail.com

Re: mount.cifs и хранение пароля


30.05.2011 11:22, alexander barakin пишет:

2011/5/30 Igor Chumakichumak2...@gmail.com:

30.05.2011 11:02, alexander barakin пишет:

2011/5/30 Igor Chumakichumak2...@gmail.com:

28.05.2011 08:41, Stanislav Maslovski пишет:

On Wed, May 25, 2011 at 03:04:22PM +, Evgeniy Vidyakov wrote:

Хранение бэкапов организовано на Widows сервере. Шара монтируется
скриптом строчкой на подобии:
  mount.cifs //server/share /mnt/server -o
iocharset=utf8,credentials=/root/.smbpass,dom=DOMAIN.LOCAL
Не нравится, что пароли в открытом текстовом виде. Возможно ли при
монтировании получать их из какого-нибудь закрытого зашифрованного
источника?

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

Это понятно. А нет ли возможности хранить не пароль, а его хеш, ведь при
авторизации на windows-сервере, насколько я знаю, используется хеш?

если для авторизации достаточно наличия хэша, то чем же хранение этого
хэша будет отличаться от хранения пароля (с точки зрения
безопасности)?


Пароль по хешу восстановить тяжело.

ну так зачем восстанавливать, если и так (допустим) можно авторизоваться?


mount.cifs требует ПАРОЛЬ
net use в windows требует ПАРОЛЬ
Так что для _стандартных_ способов авторизации знание хеша бесполезно.


Со стороны samba-сервера с авторизацией по LDAP, в каталоге хранятся 
некие sambaLMPassword и sambaNTPassword - подозреваю, что клиенту этого 
тоже должно быть достаточно.
И если верить http://en.wikipedia.org/wiki/NTLM, для авторизации таки 
достаточно хеша.



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de35885.4050...@gmail.com

Re: mount.cifs и хранение пароля


30.05.2011 11:55, Alexander Galanin пишет:

On Mon, 30 May 2011 11:42:45 +0300
Igor Chumakichumak2...@gmail.com  wrote:


Со стороны samba-сервера с авторизацией по LDAP, в каталоге хранятся
некие sambaLMPassword и sambaNTPassword - подозреваю, что клиенту этого
тоже должно быть достаточно.
И если верить http://en.wikipedia.org/wiki/NTLM, для авторизации таки
достаточно хеша.

Надо читать чуть внимательнее. По сети передаётся только хеш, на сервере
также проверяется только хеш, но для генерации ответа от клиента нужен
пароль.


:(
Посыпаю голову пеплом


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de364b1.4000...@gmail.com

Re: mount.cifs и хранение пароля


30.05.2011 11:57, alexander barakin пишет:

2011/5/30 Igor Chumakichumak2...@gmail.com:

30.05.2011 11:22, alexander barakin пишет:

2011/5/30 Igor Chumakichumak2...@gmail.com:

30.05.2011 11:02, alexander barakin пишет:

2011/5/30 Igor Chumakichumak2...@gmail.com:

28.05.2011 08:41, Stanislav Maslovski пишет:

On Wed, May 25, 2011 at 03:04:22PM +, Evgeniy Vidyakov wrote:

Хранение бэкапов организовано на Widows сервере. Шара монтируется
скриптом строчкой на подобии:
  mount.cifs //server/share /mnt/server -o
iocharset=utf8,credentials=/root/.smbpass,dom=DOMAIN.LOCAL
Не нравится, что пароли в открытом текстовом виде. Возможно ли при
монтировании получать их из какого-нибудь закрытого зашифрованного
источника?

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

Это понятно. А нет ли возможности хранить не пароль, а его хеш, ведь
при
авторизации на windows-сервере, насколько я знаю, используется хеш?

если для авторизации достаточно наличия хэша, то чем же хранение этого
хэша будет отличаться от хранения пароля (с точки зрения
безопасности)?


Пароль по хешу восстановить тяжело.

ну так зачем восстанавливать, если и так (допустим) можно авторизоваться?


mount.cifs требует ПАРОЛЬ
net use в windows требует ПАРОЛЬ
Так что для _стандартных_ способов авторизации знание хеша бесполезно.


Со стороны samba-сервера с авторизацией по LDAP, в каталоге хранятся некие
sambaLMPassword и sambaNTPassword - подозреваю, что клиенту этого тоже
должно быть достаточно.
И если верить http://en.wikipedia.org/wiki/NTLM, для авторизации таки
достаточно хеша.

ок. хоть как-то, но авторизоваться с помощью хэша, допустим, можно.
перечитываем первое письмо в треде:


Возможно ли при монтировании получать их из какого-нибудь закрытого 
зашифрованного источника?

и понимаем, что хранение хэша вместо пароля никаким образом не
является ответом на этот вопрос.
даже если научить mount.cifs пользоваться хэшем, а не паролем, вся
разница будет лишь в содержимом сохраняемой информации. но сама
информация (пароль или его хэш) так и будет храниться в открытом виде.

Как уже сообщили, пароль для авторизации клиенту все равно нужен, так 
что фантазии насчет хеша остаются фантазиями. ;)


Тогда можно сделать например так:
1. патчить mount.cifs на предмет того, что пароль в файле указанном в  
credentials , зашифрован неким ключом
2. сделать тулзовину make_credentials, которая будет шифровать этим 
самым ключом поле с паролем.



Наиболее правильно, ИМХО, было правильно генерировать ключ случайным 
образом на этапе компиляции samba - тогда ключ окажется идентичным и в 
mount.cifs и в make_credentials. Удалить исходники после установки - и 
можно считать, что хранилище паролей достаточно надежно.


Естествено, надо позаботиться о том, чтобы ключ дизассемблировать было 
неудобно ;).



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de36a98.1060...@gmail.com

Re: mount.cifs и хранение пароля


30.05.2011 13:27, Konstantin Matyukhin пишет:

Если шифровать credentials с ключом, то этот ключ надо где-то хранить,
чтобы в момент загрузки
его использовать. Т.о. задача сводится к предыдущей. За что боролись?

Вот я и предлагаю: ключ генерировать на этапе компиляции samba, хранить 
непосредственно в исполняемом файле mount.cifs.



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de3738c.4040...@gmail.com

Re: mount.cifs и хранение пароля


30.05.2011 13:50, Andrey Rahmatullin пишет:

On Mon, May 30, 2011 at 12:59:52PM +0300, Igor Chumak wrote:

Наиболее правильно, ИМХО, было правильно генерировать ключ случайным
образом на этапе компиляции samba - тогда ключ окажется идентичным и
в mount.cifs и в make_credentials. Удалить исходники после установки
- и можно считать, что хранилище паролей достаточно надежно.

Естествено, надо позаботиться о том, чтобы ключ дизассемблировать
было неудобно ;).

Ужасно.


Угу. Безопасность не должна основываться на секретном алгоритме, я в курсе.
Предложите решение покрасивше ;)


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de37bd3.6030...@gmail.com

Re: mount.cifs и хранение пароля


30.05.2011 13:57, Konstantin Matyukhin пишет:

2011/5/30 Igor Chumakichumak2...@gmail.com:

Вот я и предлагаю: ключ генерировать на этапе компиляции samba, хранить
непосредственно в исполняемом файле mount.cifs.

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


Зачем ?
В опции configure добавить чего-то вроде --with-secret_key. Опция не 
включена - у всех пользователей debian не будет _никаких_ ключей.

Кому надо - соберет для себя с этой опцией.

Да, _мне_ это не надо, это я рассуждаю на тему как организовать 
безопасное хранилище паролей для mount.cifs.



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de37d4e.7090...@gmail.com

Re: mount.cifs и хранение пароля


30.05.2011 14:15, Andrey Rahmatullin пишет:

On Mon, May 30, 2011 at 03:12:21PM +0400, Konstantin Matyukhin wrote:

2011/5/30 Andrey Rahmatullinw...@wrar.name:

Разве речь про Debian?

Где я?!

По кр.мере в Debian не требуется Удалить исходники после установки.


Собс-но , исходники удалять необязательно
В debian/rules добавить

# сгенерировать ключ
dd if=/dev/urandom bs=1k count=1 |sha512sum secret.key

# и удалить после сборки
rm -f secret.key

В этом нет нарушений Debian Policy? ;)


А вариант с аппаратным ключом тоже не идеален.
Если ключ отдаст пароль без авторизации - кто мешает утянуть этот самый 
пароль кому угодно, имеющему доступ к ключу?

Если требуется вводить пароль - тогда проще вызывать mount.cifs вручную ;)


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de385ae.4060...@gmail.com

Re: mount.cifs и хранение пароля


30.05.2011 15:32, Andrey Rahmatullin пишет:

-куть

А вариант с аппаратным ключом тоже не идеален.
Если ключ отдаст пароль без авторизации - кто мешает утянуть этот
самый пароль кому угодно, имеющему доступ к ключу?
Если требуется вводить пароль - тогда проще вызывать mount.cifs вручную ;)

В таком случае вам нужен аппаратный ключ, отдающий не пароль, а респонс по
переданному челленджу (мы ведь челлендж-респонс протокол обсуждаем?)

Началось все с организации безопасного хранилища паролей для mount.cifs. 
В котором получение root доступа не означает получение пароля.


Причем из хранилища надо получить не подтверждение того, что я знаю 
пароль (челлендж-респонс протокол это обеспечит) , а именно пароль. В 
виде текста. Или же хранилище паролей (аппаратный ключ) должно уметь NTLM?




--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de39c5e.9050...@gmail.com

Re: mount.cifs и хранение пароля