From lonely.ruyk на mail.ru Mon Apr 15 08:37:23 2013 From: lonely.ruyk на mail.ru (lonely.ruyk) Date: Mon, 15 Apr 2013 08:37:23 +0400 Subject: [P&AM Lab] crypti printf questions Message-ID: <20130415083723.1ca571aa@Lonely-1015.local> Всем доброго времени суток. Я к вам с вопросом. На днях приделал к crypti реализацию printf. Выглядит пока довольно криво, обещаю в ближайшее время довести до вменяемого состояния. https://github.com/dzruyk/crypti/blob/master/src/var_print.c Небольшой вопрос по поводу va_list: Сейчас интерфейс функции форматированного вывода выглядит так: int var_print_formatted(struct variable *fmt, struct variable **args, int nargs); хотелось бы сделать чтобы она выглядела как то так int var_print_formatted(struct variable *fmt, va_list ap); или так int var_print_formatted(struct variable *fmt, ...); Однако функция, которая использует var_print_formatted хранит список аргументов в массиве, и я не смог придумать как запихать элементы массива в va_list или передать их как список переменной длины. Есть ли красивый способ это сделать (без танцев с ассемблером и прочими радостями жизни)? P.S.: Страшное название функции сейчас вызвано тем что интерфейс отличается от стандартных функций семейства printf (посчитал что var_printf не подходит так как интерфейсы разные). Большое спасибо за ваши ответы. From sitkarev на komitex.ru Mon Apr 15 21:59:43 2013 From: sitkarev на komitex.ru (Grigoriy A. Sitkarev) Date: Mon, 15 Apr 2013 21:59:43 +0400 Subject: [P&AM Lab] crypti printf questions In-Reply-To: <20130415083723.1ca571aa@Lonely-1015.local> References: <20130415083723.1ca571aa@Lonely-1015.local> Message-ID: <516C400F.2010309@komitex.ru> Всем здоровья! lonely.ruyk wrote: > Небольшой вопрос по поводу va_list: > Сейчас интерфейс функции форматированного вывода выглядит так: > > int var_print_formatted(struct variable *fmt, struct variable **args, > int nargs); > > хотелось бы сделать чтобы она выглядела как то так > > int var_print_formatted(struct variable *fmt, va_list ap); > или так > int var_print_formatted(struct variable *fmt, ...); > Я думаю, что тебе не совсем понятно, откуда вообще взялся va_list и сопровождающие его макросы va_start(), va_end(), va_copy() и va_arg(). Они появились для того, чтобы обеспечить переносимость Си функций, принимающих переменное количество аргументов, с одной машины на другую, без привязок к особенностям ABI. В твоём случае мы имеем дело с интерпретатором, где сами переменные и аргументы при вызове функций хранятся некоторым образом в его состоянии времени выполнения. Сам интерпретатор может полностью контроллировать сколько значений было передано функции при вызове, поэтому необходимости в va_list для передачи аргументов никакой нет. Чем плох нынешний вариант с передачей аргументов в массиве? В конце концов, кто запрещает сделать структуру struct arg_list { const struct variable **item; int nitems; int nalloc; }; int var_print_formatted(const struct variable *fmt, const struct arg_list *args); -- Г.А. From lonely.ruyk на mail.ru Tue Apr 16 10:43:11 2013 From: lonely.ruyk на mail.ru (=?UTF-8?B?0JHQvtGA0LjRgSDQm9C40L/QuNC9?=) Date: Tue, 16 Apr 2013 10:43:11 +0400 Subject: [P&AM Lab] =?utf-8?q?crypti_printf_questions?= In-Reply-To: <516C400F.2010309@komitex.ru> References: <20130415083723.1ca571aa@Lonely-1015.local> <516C400F.2010309@komitex.ru> Message-ID: <1366094591.542851887@f345.mail.ru> Я подумал что с такой интерфейс выглядит более стандартным и каноничным. В конечном итоге ведь и printf(3) функции могли реализовать как то вроде: printf(char *fmt, void *args, int nargs). Спасибо за ответ, наверное я действительно немного не прав относительно интерфейса функций.:) А вообще есть возможность сделать преобразование array -> va_list или запихать массив в функции с переменным количеством параметров *стандартными средствами* или эта ситуация - совсем не то для чего они используются и о таких вопросах не стоит задумываться? Понедельник, 15 апреля 2013, 21:59 +04:00 от "Grigoriy A. Sitkarev" : >Всем здоровья! > >lonely.ruyk wrote: >> Небольшой вопрос по поводу va_list: >> Сейчас интерфейс функции форматированного вывода выглядит так: >> >> int var_print_formatted(struct variable *fmt, struct variable **args, >> int nargs); >> >> хотелось бы сделать чтобы она выглядела как то так >> >> int var_print_formatted(struct variable *fmt, va_list ap); >> или так >> int var_print_formatted(struct variable *fmt, ...); >> > >Я думаю, что тебе не совсем понятно, откуда вообще взялся va_list и >сопровождающие его макросы va_start(), va_end(), va_copy() и va_arg(). >Они появились для того, чтобы обеспечить переносимость Си функций, >принимающих переменное количество аргументов, с одной машины на другую, >без привязок к особенностям ABI. > >В твоём случае мы имеем дело с интерпретатором, где сами переменные и >аргументы при вызове функций хранятся некоторым образом в его состоянии >времени выполнения. Сам интерпретатор может полностью контроллировать >сколько значений было передано функции при вызове, поэтому необходимости >в va_list для передачи аргументов никакой нет. > >Чем плох нынешний вариант с передачей аргументов в массиве? В конце >концов, кто запрещает сделать структуру > >struct arg_list { >const struct variable **item; >int nitems; >int nalloc; >}; > >int var_print_formatted(const struct variable *fmt, const struct >arg_list *args); > > >-- >Г.А. > >_______________________________________________ >Lab mailing list >Lab на amplab.syktsu.ru >http://amplab.syktsu.ru/cgi-bin/mailman/listinfo/lab ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From ilyin_mikhail на inbox.ru Tue Apr 16 11:07:05 2013 From: ilyin_mikhail на inbox.ru (=?UTF-8?B?TWlraGFpbCBJbHlpbg==?=) Date: Tue, 16 Apr 2013 11:07:05 +0400 Subject: [P&AM Lab] =?utf-8?q?crypti_printf_questions?= In-Reply-To: <1366094591.542851887@f345.mail.ru> References: <20130415083723.1ca571aa@Lonely-1015.local> <516C400F.2010309@komitex.ru> <1366094591.542851887@f345.mail.ru> Message-ID: <1366096025.438031410@f337.mail.ru> Привет всем, я хотел написать тебе, Боря, еще вчера. Г.А все верно сказал, что ты не до конца понимаешь, для чего нужны эти ф-ии/макросы в Си. И как хранятся аргументы. printf(char *fmt, void *args, int nargs) в твоем предложенном варианте аргументы уже хранятся в подготовленном массиве, и в ф-ию передаются только  указатель на массив, его размерность + конечно же сама форматная строка, так вот получается на стеке в итоге находится 3 аргумента. Когда же мы говорим про оригинальную версию printf, то ВСЕ аргументы хранятся в регистрах и/или в стеке (в зависимости как и сказал Г.А. от ABI), сколько ты их передашь это не имеет значение. И если посмотреть на реализацию самой printf, то она полагается на форматную строку, и  данные  извлеченные из стека/регистров с помощью va_arg интерпретируются согласно спецификации строки, то есть количество аргументов заведомо не передается. То есть еще раз: 1. все аргументы живут в стеке/регистрах (нет промежуточного хранилища, типа массива); 2. количество аргументов не передается; 3. форматная строка это то на что полагаются при извлечении аргументов (если строка косячная и не соотвествует извлеченным данным всего скорее программа скоро завалится, при первом обращении к данным). Если ты хочешь избавится от количества аргументов в своей реализации и от промежуточного массива, почему бы тебе не создавать конечную строку динамически, извлекая одновременно операцией pop свои значения и консультируясь со своей форматной строкой. Посмотри для примера http://wiki.syktsu.ru/websvn/filedetails.php?repname=litepac&path=%2Fvmlibcall%2Fio.c Удачи. Вторник, 16 апреля 2013, 10:43 +04:00 от Борис Липин : >Я подумал что с такой интерфейс выглядит более стандартным и каноничным. >В конечном итоге ведь и printf(3) функции могли реализовать как то вроде: >printf(char *fmt, void *args, int nargs). >Спасибо за ответ, наверное я действительно немного не прав относительно интерфейса функций.:) > >А вообще есть возможность сделать преобразование array -> va_list или запихать массив в функции с переменным количеством параметров *стандартными средствами* или эта ситуация - совсем не то для чего они используются и о таких вопросах не стоит задумываться? > > >Понедельник, 15 апреля 2013, 21:59 +04:00 от "Grigoriy A. Sitkarev" : >>Всем здоровья! >> >>lonely.ruyk wrote: >>> Небольшой вопрос по поводу va_list: >>> Сейчас интерфейс функции форматированного вывода выглядит так: >>> >>> int var_print_formatted(struct variable *fmt, struct variable **args, >>> int nargs); >>> >>> хотелось бы сделать чтобы она выглядела как то так >>> >>> int var_print_formatted(struct variable *fmt, va_list ap); >>> или так >>> int var_print_formatted(struct variable *fmt, ...); >>> >> >>Я думаю, что тебе не совсем понятно, откуда вообще взялся va_list и >>сопровождающие его макросы va_start(), va_end(), va_copy() и va_arg(). >>Они появились для того, чтобы обеспечить переносимость Си функций, >>принимающих переменное количество аргументов, с одной машины на другую, >>без привязок к особенностям ABI. >> >>В твоём случае мы имеем дело с интерпретатором, где сами переменные и >>аргументы при вызове функций хранятся некоторым образом в его состоянии >>времени выполнения. Сам интерпретатор может полностью контроллировать >>сколько значений было передано функции при вызове, поэтому необходимости >>в va_list для передачи аргументов никакой нет. >> >>Чем плох нынешний вариант с передачей аргументов в массиве? В конце >>концов, кто запрещает сделать структуру >> >>struct arg_list { >>const struct variable **item; >>int nitems; >>int nalloc; >>}; >> >>int var_print_formatted(const struct variable *fmt, const struct >>arg_list *args); >> >> >>-- >>Г.А. >> >>_______________________________________________ >>Lab mailing list >>Lab на amplab.syktsu.ru >>http://amplab.syktsu.ru/cgi-bin/mailman/listinfo/lab > >_______________________________________________ >Lab mailing list >Lab на amplab.syktsu.ru >http://amplab.syktsu.ru/cgi-bin/mailman/listinfo/lab ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From sitkarev на komitex.ru Tue Apr 16 11:37:28 2013 From: sitkarev на komitex.ru (Grigoriy A. Sitkarev) Date: Tue, 16 Apr 2013 11:37:28 +0400 Subject: [P&AM Lab] crypti printf questions In-Reply-To: <1366094591.542851887@f345.mail.ru> References: <20130415083723.1ca571aa@Lonely-1015.local> <516C400F.2010309@komitex.ru> <1366094591.542851887@f345.mail.ru> Message-ID: <516CFFB8.5090602@komitex.ru> Борис Липин wrote: > Я подумал что с такой интерфейс выглядит более стандартным и каноничным. > В конечном итоге ведь и printf(3) функции могли реализовать как то вроде: > printf(char *fmt, void *args, int nargs). Могли бы, но не стали, потому что при передаче аргументов достаточно поместить их в регистры и/или стек в соответствии с ABI; что, собственно, и делает компилятор, когда генерирует код передачи аргументов функции. Если бы мы передавали там args и nargs, то здесь ещё кто-то должен бы был выделить память для массива, поместить в массив аргументы. Это существенно бы затруднило переносимость программ и усложнило бы окружение времени исполнения. В этом прелесть Си, -- требования к окружению времени выполнения минимальные и могут быть обрезаны по желанию программиста в соответствии с требованиями его программ. > Спасибо за ответ, наверное я действительно немного не прав относительно интерфейса функций.:) > > А вообще есть возможность сделать преобразование array -> va_list или запихать массив в функции с переменным количеством параметров *стандартными средствами* или эта ситуация - совсем не то для чего они используются и о таких вопросах не стоит задумываться? Этого делать не нужно. По сути va_list с его макросами -- это доступ к кадру стека, где хранятся аргументы. Он не предназначается для хранения каких-то иных данных и/или ссылок на них. Всё это, конечно, можно осуществить, на то у нас и ассемблерные вставки есть и Си позволит это сделать, но тогда нужно реализовывать такой финт для каждого ABI и аппаратной платформы. Здесь без аппаратных привязок не обойтись. Короче говоря, не для того он делался. Нужно было сделать переносимые макросы для доступа к кадру стека и извлечения из него аргументов, вот и всё. -- Г.А. From lonely.ruyk на mail.ru Tue Apr 23 02:59:31 2013 From: lonely.ruyk на mail.ru (ruyk) Date: Tue, 23 Apr 2013 02:59:31 +0400 Subject: [P&AM Lab] some admin tasks Message-ID: <20130423025931.3355cf90@Lonely> Привет, рассылка. На работе пара задач интересных появилась, и я к вам за советами:) 1) На одном из серверов необходимо настроить логгирование действий пользователей (к примеру когда какие команды в консольке набивались), подключившихся из внешней сети. Демон наверное auditd не вполне подходит т.к. он работает на слишком низком уровне. Подозреваю что замучаюсь потом логи анализировать. Нашёл ещё snoopy(https://github.com/a2o/snoopy). Разделяемая библиотека, которая вешает хуки на execve вызовы. Тоже не подходит так как в логи попадает много левой информации, т.к. например при инициализации bash из .bashrc и profile запускается куча левого хлама. Решил остановиться на rootsh (http://sourceforge.net/projects/rootsh/) Могу врать но на сколько я понял он создаёт пару псевдотерминалов между пользователем и запускаемой программой, и поэтому всё что попадаёт на экран может быть словленно им и записано в лог. Как решил задачу: С помощью директивы openssh сервера ForceCommand будет запускаться скрипт который будет анализировать переменную SSH_CLIENT и в соответствии с ней запускать rootsh или обычный bash. Вроде всё хорошо но не отпускает мысль что я нашёл не оптимальное решение, есть какие-то штатные средства которые позволят добиться того же? 2) Совсем коротенько опишу:) Надо обеспечить передачу логов по шифрованному каналу с одного сервера на другой. Так как канал должен быть шифрованным, на сколько я понимаю, syslog и rsyslog сразу отваливаются. Из более менее подходящих программ нашёл только nxlog ( http://nxlog-ce.sourceforge.net/) Есть ли известные вам удобные инструменты для централизованного анализа логов (не грепить жеж)? Может кто-то сталкивался с подобной проблемой, насоветуйте пожалуйста ещё инструментов её решения. Всем спасибо и заранее дополнительное спасибо ответившим:) P.S.: Начало появляться это неловкое чувство когда понимаешь что только ты задаёшь в рассылке вопросы :-[ From sitkarev на komitex.ru Tue Apr 23 22:35:48 2013 From: sitkarev на komitex.ru (Grigoriy A. Sitkarev) Date: Tue, 23 Apr 2013 22:35:48 +0400 Subject: [P&AM Lab] some admin tasks In-Reply-To: <20130423025931.3355cf90@Lonely> References: <20130423025931.3355cf90@Lonely> Message-ID: <5176D484.8010809@komitex.ru> Всем доброго здоровья! Я завтра утром улечу в Москву и вернусь только к концу недели. К субботе я буду в Лаборатории по расписанию. ruyk wrote: > 1) На одном из серверов необходимо настроить логгирование действий > пользователей (к примеру когда какие команды в консольке набивались), > подключившихся из внешней сети. > Демон наверное auditd не вполне подходит т.к. он работает на слишком > низком уровне. Подозреваю что замучаюсь потом логи анализировать. > > Нашёл ещё snoopy(https://github.com/a2o/snoopy). Разделяемая > библиотека, которая вешает хуки на execve вызовы. Тоже не подходит так > как в логи попадает много левой информации, т.к. например при > инициализации bash из .bashrc и profile запускается куча левого хлама. > > Решил остановиться на rootsh (http://sourceforge.net/projects/rootsh/) > Могу врать но на сколько я понял он создаёт пару псевдотерминалов между > пользователем и запускаемой программой, и поэтому всё что попадаёт на > экран может быть словленно им и записано в лог. > Как решил задачу: > С помощью директивы openssh сервера ForceCommand будет запускаться > скрипт который будет анализировать переменную SSH_CLIENT и в > соответствии с ней запускать rootsh или обычный bash. > > Вроде всё хорошо но не отпускает мысль что я нашёл не оптимальное > решение, есть какие-то штатные средства которые позволят добиться того > же? Культура и опыт Unix учит нас, что одного единственно верного решения не существует. Мне кажется, что вы не понимаете основной принцип этой ОС. Здесь вы сами можете конструировать нужные вам инструменты. Если есть какой-то текст, то с помощью комбинации программ, объединённых конвеером, мы можем получить совершенно новый инструмент. Порядок и способ использования этих программ может быть совершенно неочевидным, и здесь Unix таит много непознанных возможностей и простора для творчества. Можно сказать, что если вам удалось текстуализировать временную метку, PID, UID, GID и вызовы exec с аргументами, то остаётся лишь пропустить этот текстовый поток через фильтр. Из полученного ?дистиллята? формируются отчёты и представляются в нужной форме, вплоть до печатных форм в PostScript, сгенерированных в troff. Традиция Unix предполагает существование простых программ, которые можно комбинировать друг с другом, получая новые, а не монстров-монолитов на все случаи жизни, которые знают лучше вас, что нужно делать в том или ином случае. > 2) Совсем коротенько опишу:) > Надо обеспечить передачу логов по шифрованному каналу с одного сервера > на другой. > Так как канал должен быть шифрованным, на сколько я понимаю, syslog и > rsyslog сразу отваливаются. > Из более менее подходящих программ нашёл только nxlog ( > http://nxlog-ce.sourceforge.net/) > > Есть ли известные вам удобные инструменты для централизованного анализа > логов (не грепить жеж)? > Может кто-то сталкивался с подобной проблемой, насоветуйте пожалуйста > ещё инструментов её решения. Опять вернёмся к теме взаимодействия программ. Любой сетевой трафик можно пропустить через туннель ssh. Любую удалённую команду можно запустить точно так же через ssh. Многие утилиты могут использовать stdin/stdout других программ для ввода-вывода, например, rsync. (Для этого у rsync есть опция -e, она же --rsh.) Кроме того, тот же rsync имеет такие опции как --append и --append-verify. Если говорить про Rsyslog, то он сам имел поддержку TLS. Защищённый обмен можно было организовать его встроенными средствами, через PKI. По поводу анализа логов -- всё сказаное выше справедливо и по отношению к этой задаче. Если очень хочется интегрированное решение, то можно попробовать OSSEC [1]. > P.S.: Начало появляться это неловкое чувство когда понимаешь что только > ты задаёшь в рассылке вопросы :-[ Дело в том, что все стали писать лично мне. Плохого в этом ничего нет, безусловно, я сам люблю получать письма и отвечать. Но как-то не очень пока получается вовлечь коллектив в совместную разработку. И вам всем стоит об этом задуматься. [1] http://www.ossec.net -- Г.А. From alexeypetrunev на gmail.com Wed Apr 24 12:27:05 2013 From: alexeypetrunev на gmail.com (Alex Pnv) Date: Wed, 24 Apr 2013 12:27:05 +0400 Subject: [P&AM Lab] =?koi8-r?b?8NLPwszFzdkg0yDSwdPT2czLz8o6KA==?= Message-ID: Всем привет. Это тестовое сообщения. Хорошего дня!:) ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From zudin.vadim на mail.ru Fri Apr 26 16:51:09 2013 From: zudin.vadim на mail.ru (=?UTF-8?B?0JLQsNC00LjQvCDQl9GD0LTQuNC9?=) Date: Fri, 26 Apr 2013 16:51:09 +0400 Subject: [P&AM Lab] =?koi8-r?b?KMLF2iDUxc3ZKQ==?= Message-ID: <1366980669.680583268@f146.mail.ru> Всем здравствуйте. Будут ли у нас в эту субботу (27.04) какие нибудь... лекции (имеется в виду планировавшийся курс по операционным системам). Просто если нет, то скорее всего нас, новичков (ну меня точно), в эту субботу не будет. -- Вадим Зудин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From sitkarev на komitex.ru Tue Apr 30 16:12:02 2013 From: sitkarev на komitex.ru (Grigoriy A. Sitkarev) Date: Tue, 30 Apr 2013 16:12:02 +0400 Subject: [P&AM Lab] =?utf-8?b?KNCx0LXQtyDRgtC10LzRiyk=?= In-Reply-To: <1366980669.680583268@f146.mail.ru> References: <1366980669.680583268@f146.mail.ru> Message-ID: <517FB512.8080604@komitex.ru> Всем здоровья. Вадим, мы старательно избегали нагружать вас любыми занятиями в лекционной форме. У меня есть предложение к вам со своей стороны. В субботу мешать всё в одну кучу не выйдет, многие вещи для остальных будут повтором банальностей. Если вы действительно хотите курс по операционным системам, то у меня есть к вам предложение сначала разобраться, -- что это вообще такое и научиться системному программированию. По существу, это и будет курс по ОС, ведь мы их воспринимаем -- с точки зрения программиста -- как набор функций интерфейса прикладного программирования. В курсах по ОС, предлагаемых в большинстве учебных заведений, весь набор средств ОС рассматривается как данность: мнения участников событий, комментарии, мемуары непосредственных разработчиков, как правило, не рассматриваются. Например, откуда появились трубы, механизмы System V IPC, мультиплексированный ввод-вывод, кто обеспечивал им ?протеже? и т.д.? Мы должны нарушить эту традицию. Структуру курса мы тоже построим иначе. Я предлагаю рассмотреть компактную классическую программную модель Unix, а затем постепенно добавить к ней всё, что появилось по ходу её развития для удовлетворения возрастающих потребностей пользователей и прилаживания к изначально не предусматриваемым задачам (реальное время в частности). Можно выбрать любой день на неделе и определиться со временем, желательно во второй половине дня. Какие будут возражения и предложения? -- Г.А. Вадим Зудин wrote: > Всем здравствуйте. Будут ли у нас в эту субботу (27.04) какие нибудь... лекции (имеется в виду планировавшийся курс по операционным системам). Просто если нет, то скорее всего нас, новичков (ну меня точно), в эту субботу не будет. > > ------------------------------------------------------------------------ > > _______________________________________________ > Lab mailing list > Lab на amplab.syktsu.ru > http://amplab.syktsu.ru/cgi-bin/mailman/listinfo/lab