Досталось мне древнее железо от конторы одной. 2x512MB RAM DDR 333Mhz, Pentium D, 2 сетевки TP-Link и Acorp, IDE HDD 80Gb. Задумал я из этого дела шлюз+файлосвалку сделать. Под это дело вытащил из загашника 2 беспроводных сетевых и хард на 1Tb. Сетевая помощнее - TL WN722N, юэсбишная. Служит своего рода модемом для провайдера SosedNeZnaet-Telecom. Послабже - PCI, чтобы инет от вышеупомянутого прова на андроиды свои и гостевые раздавать. Проводные сетевки для раздачи на 2 стационарника. Настраивал-причесывал этот шлюз часов 5. Настроил как надо iptables - внутрь ничего не ходит, наружу можно всё. Примонтировал терабайтник, поднял самбу, настроил hostapd и wpa_supplicant. Попробовал поюзать. Какое-то время сеть нормально работала. Потом начались адовые тормоза. Шлюзик выключил до появления лучшего железа. Обидно стало за потраченное время. Позже вспомнил, что аналогичное железо раздавало 20 мбит инета на 17 хостов и не чахло. Включил шлюзик. Опытным путем было выяснено, что сеть работает отлично до тех пор, пока на любом из хостов, подключенных к шлюзу не будет запущен торрент-клиент. Хватает 1-2 минут, чтобы пинги выросли с 30ms до 4386ms, а если оставить торрент включенным, ещё через пару минут команда ping будет показывать совсем не радужные 65962ms. Если же выключить торрент на этапе когда сеть уже почти легла, но не совсем, время пинга упадёт с ~4000 до ~2000ms. Лечится только ребутом, после чего icmp-пакетики могут летать со скоростью не более 50ms достаточно долгое время(примерно 3 часа замерял) до запуска торрента.

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

Не могу подключить модем к одной из машин с debian+proxmox на борту. При подключении в dmesg валится следующее:

usb 7-1: new full speed USB device number 6 using ohci_hcd
usb 7-1: device descriptor read/64, error -32
usb 7-1: device descriptor read/64, error -32
usb 7-1: new full speed USB device number 7 using ohci_hcd
usb 7-1: device descriptor read/64, error -32
usb 7-1: device descriptor read/64, error -32
usb 7-1: new full speed USB device number 8 using ohci_hcd
usb 7-1: device not accepting address 8, error -32
usb 7-1: new full speed USB device number 9 using ohci_hcd
usb 7-1: device not accepting address 9, error -32
hub 7-0:1.0: unable to enumerate USB device on port 1

Вывод lsusb:

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 008 Device 002: ID 2109:3431  
Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

На второй машине с аналогичной ОС и софтом нормально подключается и определяется. Возможно, это как-то связано с тем, что хард, на который изначально ставилась система, был перенесён на совершенно другое железо (с Intel на AMD). Вроде как всё остальное работает

Есть много принтеров Pantum P2000, предназначенных для печати с терминальных станций. Имеются виндовые драйвера и ppd+filter для cups. А сама проблема заключается в следующем: линуксовый драйвер требует glibc 2.14, не меньше. В оф. репозиториях CentOS 6.5 доступна только версия 2.12, обновлять этот сервер не вариант совсем. Пробовал уже, много чего отвалилось, откатился назад. Пытался запускать из chroot с нужной библиотекой. При попытке напечатать что-нибудь фильтр падает без объяснения причин «printer failed due to backend errors» - пишет. Новый терминальный сервер развернуть попробовал, позже узнал что под текущую инфраструктуру нет вменяемого удаленного клиента под CentOS 7. Собственно, вопрос: что делать в такой ситуации? Где-то вычитал как заводили подобные принтеры: поднимали сервер печати на винде, из cups отправляли документы на виндовую машину as is, виндовая машина преобразовывала такие документы в формат понятный принтеру и отправляла по ipp на линуксовую машину, непосредственно подключенную к принтеру. ИМХО королевский изврат, но, если нет более красивых решений, придётся попробовать.

Даже не знаю куда смотреть. Ещё вчера всё работало (единственное, что делал на сервере терминалов: снёс network manager), отображались сессии в nxsadmin, команда who показывала юзеров как надо. Сейчас видно кто подключился по ssh, но не видно NX клиентов.

Используемый софт:
CentOS 6.3
FreeNX
NX клиент от NoMachine

Подскажите куда копать.
Есть терминальный сервер(CentOS 6) с интернетом и есть пользователи этого сервера, которым которым нужно открыть доступ только к 2м IP.
Настроил Squid, работает нормально, если ручками прописать в настройки Firefox.
Пользователей у меня немало, вручную прописывать лениво. Решил завернуть весь http траф на squid.

iptables -t nat -A OUTPUT -p tcp -m multiport --dports 80,8000,8088,3128 -j DNAT --to-destination 127.0.0.1:3128

http_port 127.0.0.1:3128 transparent

acl localnet src 10.x.0.0/16 127.0.0.1
acl allowed_ip dst 10.x.0.0/16 10.x.x.0/24 

acl SSL_ports port 443		# https
acl SSL_ports port 563		# snews
acl SSL_ports port 873		# rsync
acl Safe_ports port 80		# http
acl Safe_ports port 21		# ftp
acl Safe_ports port 443		# https
acl Safe_ports port 70		# gopher
acl Safe_ports port 210		# wais
acl Safe_ports port 1025-65535	# unregistered ports
acl Safe_ports port 280		# http-mgmt
acl Safe_ports port 488		# gss-http
acl Safe_ports port 591		# filemaker
acl Safe_ports port 777		# multiling http
acl Safe_ports port 631		# cups
acl Safe_ports port 873		# rsync
acl Safe_ports port 901		# SWAT
acl Safe_ports port 22		# ssh
acl purge method PURGE
acl CONNECT method CONNECT

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localnet allowed_ip
http_access deny all

access_log /var/log/squid/access.log squid

refresh_pattern ^ftp:		1440	20%	10080
refresh_pattern ^gopher:	1440	0%	1440
refresh_pattern -i (/cgi-bin/|\?) 0	0%	0
refresh_pattern (Release|Packages(.gz)*)$	0	20%	2880
refresh_pattern .		0	20%	4320

acl shoutcast rep_header X-HTTP09-First-Line ^ICY.[0-9]
#upgrade_http0.9 deny shoutcast

acl apache rep_header Server ^Apache
#broken_vary_encoding allow apache

hosts_file /etc/hosts
cache deny allowed_ip

Суть проблемы: Есть тонкий клиент Kraftway Credo vv18 и чековый принтер Posiflex P6800U-B. Нужно заставить их работать вместе из под терминальной сессии.
Что сделано:
1. При подключении принтера его видно в lsusb, видно также из панели управления терминальной станцией (веб морда на localhost), CUPS отказывался его видеть до тех пор, пока вручную не прописал

lpadmin -p Posiflex1 -v serial:/dev/ttyACM0?baud=115200

Собственно, нужно сделать так, чтобы принтер можно было увидеть из под терминальной сессии на COM3 (/dev/ttyS2), потому как специфичная софтина шлёт текст чека именно туда. Наверно, тут даже драйвер необязателен. Принтер успешно и без кракозябр печатает hello по команде «echo hello > /dev/ttyACM0» до входа в терминальную сессию.