Debian: Быстрая настройка pure-ftpd

pure-ftpd - один из многих ftp-серверов под Linux, но как-то так сложилось, что я использую именно его. Приведу небольшой пример его послеустановочной настройки в Debian.

Во-первых, идем в /etc/pure-ftpd/conf/. В некоторых системах все конфигурационные директивы собраны в один файл (типа /usr/local/etc/pure-ftpd.conf), в Debian же каждой конфигурационной директиве соответствует один файл в /etc/pure-ftpd/conf/, где имя файла совпадает с именем директивы (имя регистро-зависимо!), а значение директивы определяется содержимым этого файла:

По-моему не самое лучшее решение, но придется с этим мириться. 

По-умолчанию установлены настройки MinUID=1000 (что уже не даст зайти под системными пользователями, в т.ч. под root), NoAnonymous=yes (отключает анонимных клиентов), и включена PAM-аутентификация. Меня устраивает и UNIX-аутентификация, поэтому я задал в файле PAMAuthentication значение 'no', а в UnixAuthentication - 'yes'. Кстати, порядок использования средств аутентификации задается в /etc/pure-ftpd/auth символическими ссылками на соответствующие конфигурационные файлы в /etc/pure-ftpd/conf/:

Единственная опция, которую я решил добавить, это ChrootEveryone, чтобы пользователи блокировались в своей домашней директории. Для этого создаем файл ChrootEveryone, открываем его и записываем в него 'yes' (без кавычек).

Трассировка оригинальных SQL-запросов Tecdoc

В принципе можно трассировать запросы средствами ODBC-драйвера Transbase, но он обрезает длинные запросы, и поэтому толку от него мало. Я нашел следующий вариант трассировки:
1) Устанавливаем клиент-северную конфигурацию Tecdoc, т.е. на одном из компов в локалке разворачиваем сервер текдока, на другом - клиент.
2) На сервере запускам сниффер сетевого трафика, например, Wireshark, устанавливаем фильтр таким образом, чтобы он показывал трафик только с той машины, где установлен клиент текдока (в принципе, другие фильтры можно не ставить если между машинами другого трафика не ходит):

3) На клиенте запускаем интерфейс текдока, выполняем в нем некоторые операции. В сниффере видим SQL-запросы к базе =)

java.lang.IllegalArgumentException: Invalid Proxy при использовании Proxy.Type.HTTP для создания сокета

Проблема: 

При попытке использовать прокси типа Proxy.Type.HTTP для создания сокета следующим кодом:

Proxy prx = new Proxy(Proxy.Type.HTTP, new InetSocketAddress("webprox", 8888));
Socket socket = new Socket(prx);

 вылетает исключение:

java.lang.IllegalArgumentException: Invalid Proxy

Решение:

Действительно, при создании ява-сокета использовать HTTP-прокси нельзя, что, в общем-то, и логично =), ведь HTTP-прокси умеет работать только с протоколом HTTP, а сокет является более низкоуровневым объектом, не привязанным ни к какому протоколу прикладного уровня. А вот в URL.openConnection HTTP-прокси использовать уже можно, если, конечно, используемый урлом протокол http или https.

Для создания сокета, работающего через прокси, можно использовать только прокси типа Proxy.Type.SOCKS (и, соответственно, Ваш прокси должен поддерживать Socks).

apache 2.2.x и "MaxClients of xxx would require yy servers, and would exceed the ServerLimit value of 16."

Проблема:
При установке в конфигурации Apache версии 2.2.х параметра MaxClients большим, чем 400 (например, 1000), получаем при перезапуске ошибку:

WARNING: MaxClients of 1000 would require 40 servers,
 and would exceed the ServerLimit value of 16.
 Automatically lowering MaxClients to 400.  To increase,
 please see the ServerLimit directive.

Директивы же  ServerLimit в конфиге нету, и её добавление туда ситуации не меняет.

Причина:
В новых версиях Apache параметр ServerLimit  больше нельзя установить через конфигурацию.

Решение:
Установить MaxClients в 400 или перекомпилировать Apache (как, написано тут: http://onaxer.com/blog/blog/2010/04/11/compiling-serverlimit-in-apache-2-x/).

Linux: просмотр списка прослушиваемых портов

sudo netstat -anp --udp --tcp | grep LISTEN

java.net.UnknownHostException при вызове java.net.InetAddress.getLocalHost()

Проблема:
При вызове метода java.net.InetAddress.getLocalHost() для получения IP-адреса локальной машины генерируется исключение "java.net.UnknownHostException: ... ".

Причина:
Имя, указанное как hostname компьютера (в Debian это устанавливается в /etc/hostname), неразрешимо в IP-адрес.

Решение:
Возможно 2 варианта:

• изменить /etc/hostname на имя, которое преобразуемо в IP либо с помощью /etc/hosts, либо с помощью нелокального DNS
• добавить hostname в /etc/hosts