Ждущий режим и логин
>>> Подробности (Invalid URL, no host part!)
>>> Подробности (Invalid URL, no host part!)
1. Есть сервер postfix на который ходят юзеры. 2. Есть отдельный сервер на котором в mysql храняться логины и пароли юзеров. 3. Mysql на сервере из п.2 НЕ виден из сети. Это принципиально. 4. На сервере п.2 есть апачь и возможность на нем сделать скрипт проверки авторизации при передаче ему имени и пароля юзера.
Вопрос: как можно организовать в postfix авторизацию в такой системе?
>>> Подробности (Invalid URL, no host part!)
Вот теперь она неожиданно понадобилась, но я напрочь забыл где я это видел и даже примерного названия не помню. :(
Гугль не помог.
Может быть кто-то в курсе - в какую сторону искать?
>>> Подробности (Invalid URL, no host part!)
Кто заинтересуется - пишите на andy собака russiamail dot ru
>>> Подробности (Invalid URL, no host part!)
До ядер 2.6.16-27 включительно все было нормально. Как только перешли на ядра >= 2.6.18 начались проявляться проблемы при записи в файлы через nfs. Смысл в том, что вместо нужных строк данных в файл почему-то пишеться строка с символом \0 аналогичной длины.
Кто-нибудь знает что это за баг, как его обойти или в каких ядрах его уже пофиксили?
Делаю текстовый файл и вводу строку "абвгдежзийклмн". Вместо это строки при вводе появляется "0123456789:;<=". При этом, если посмотреть в виде HEX видно, что добавляетс янормальный koi8 текст. Для проверки я снизу добавил ту строку которая видна. Вот что получилось: 00000000 C1 C2 D7 C7 │ C4 C5 D6 DA │ C9 CA CB CC │ CD CE CF 0A │ 30 31 32 33 │ 34 35 36 37 │ 38 39 3A 3B абвгдежзийклмно.0123456789:; 0000001C 3C 3D 3E 0A │ <=>. Fedora Core 5.
В чем может быть дело?
Но вот что интересно. На первом из них (с которым я обычно и работаю) иногда (не очень часто, но если уж начнет, то задолбает) начинаются пертурбации с экраном. Заключаются они в том, что происходит сдвиг всего изображения циклически вбок на неопределенную величину (меняется все время). Т.е. левая часть экрана шириной пикселей от 300 до 800 перемещается к правому краю, остальное на это-же значение смещается влево. Удалось заметить связь такого смещения с нажатием клавиш.
Железо тут не при чем, т.к. оно в процессе выяснения менялось полностью. Из патча dualhead для xorg я удалил все что относиться к PCI (есть там такая часть) и оставил исключительно правку драйвера клавы. После долгой нормальной работы сегодня опять появился этот глюк. :(
Кто знает как это дело поправить? Может быть существует в природе правки к патчу dualhead?
Перекомпилил себе сервер Xorg 6.8.2. И теперь у меня для переключения на текстовую консоль используется комбинация клавишь Ctrl-F*. Это очень неудобно. Подскажите, пожалуста, как вернуть переключение на консоли по Ctrl-Alt-F*?
Есть сервак. На нем куча всего, в т.ч. 2 postfix для двух разных доменов на разных IP (причем не на первых).
Сейчас у меня получается так, что исходящие письма от postfix иду с IPб который продиктован роутингом, т.е. как я понимаю, с того IP который стоит первым на сетевушке.
Можно-ли каким-то образом заставить postfix отправлять письма с определенным обратным IP не совпадающим с первым в системе?
Если расшареный nbd винт использовать с одного клиента, то никаких вопросов не возникает.
Но у меня вот такой вопрос: Возможно-ли при подключении nbd винта на разные клиенты использовать его на всех для записи/чтения, например, поставив на него файловую систему GFS?
И попутный вопрос: Если это возможно, будет-ли такое работать если поставить GFS на lvm раздел организованный на нескольких nbd?
Нужно поставить ограничение на количство отсылаемых копий одного письма. Т.е. что-бы у юзера не было возможности поставить сотню получателей в сотне полей "To:", а ограничить это количество например 5-ю возможными кописями.
Есть такое ограничение в postfix?
Но вот такая конструкция (выполняется долго) "delete from table1 using table1, table2 where ..." блокирует и table2 и я в нее ничего не могу добавить через insert.
Подскажите, плиз, можно-ли этого как-то избежать, возможно, добавив к этому запросу еще какие-то параметры?
Вариант с избавлением от двутабличного удаления очевиден, но у него плохо со скоростью.
Есть nfs сервер (ядро 2.6.14.4). На нем 4 Гб ОЗУ. Кроме nfsd на нем никаких сервисов не висит. Через некоторое время работы получаем вот такую картину:
Mem: 3370408k total, 1060940k used, 2309468k free, 779508k buffers Swap: 4096564k total, 0k used, 4096564k free, 35948k cached
При этом нагрузка на проц операциями wa составляет в среднем 90%.
Мне вот что непонятно. Почему в наличии присутствует такая куча свободной памяти при малом количестве выделяемой памяти под файловый кэшь при интенсивной работе с диском?
Может это дело можно через /proc поправить?
| ← предыдущие | следующие → |