вторник, 30 декабря 2008 г.
понедельник, 29 декабря 2008 г.
двух стандартов - 568A или 568B. Данные стандарты предполагают раскладку проводов в следующем порядке (контакты нумеруются слева направо при условии, что разъем расположен контактной группой вверх).
Стандарт 568A:
- Бело-зеленый
- Зеленый
- Бело-оранжевый
- Синий
- Бело-синий
- Оранжевый
- Бело-коричневый
- Коричневый
Стандарт 568B:
- Бело-оранжевый
- Оранжевый
- Бело-зеленый
- Синий
- Бело-синий
- Зеленый
- Бело-коричневый
- Коричневый
В случае сети на два компьютера (без коммутатора) применяется кабель типа "кроссовер" , один конец которого обжимается по стандарту 568A, а другой - по стандарту 568B. Такой же кабель служит для соединения между собой двух коммутаторов.
пятница, 26 декабря 2008 г.
Печать через встроенный сервер на hp3005dn
среда, 24 декабря 2008 г.
Squid 2.7 for Windows
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
По умолчанию сервер работатет на порту с номером 3128. Если более привычен другой порт то в файле squid.conf правим
#always_direct deny all
четверг, 11 декабря 2008 г.
svhost и память
Временно помогло убивание процесса с помощью программы Process Explorer для Windows http://technet.microsoft.com/ru-ru/sysinternals/bb896653.aspx
Если точнее то это C:\WINDOWS\system32\wscntfy.exe и C:\WINDOWS\System32\svchost.exe -k netsvcs NT AUTHORITY\SYSTEM. После убивания процесса хлопается интерфейс на стандартный XP. Если стоя на процессе посмотреть свойства и вкладку сервисы, то
прибитие Фоновая интеллектуальная служба передачи (BITS) остановило утечку памяти;)
http://www.personalfirewall.comodo.com/
понедельник, 8 декабря 2008 г.
Пробросить порт во внутреннюю сеть
Помогло:
Включить пересылку IP, что даст Linux машине выполнять функции маршрутизатора.
/sbin/sysctl -w net.ipv4.ip_forward=1
/sbin/iptables -A FORWARD -p tcp -i eth0 -o eth1 -d 192.168.10.3 --dport 8015 -j ACCEPT
/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8015 -d 84.22.133.167 -j DNAT --to-destination 192.168.10.3
eth0 смотрит в инет, а eth1 в локальную сеть. На машине 192.168.10.3 шлюз по умолчанию должен быть как адрес eth1.
Линки по которым я прогулялся для ознакомления с применяемыми командами iptables.
- http://forum.ubuntu.ru/index.php?topic=37402.msg281791
- http://kb.etarea.com/2008/06/12/iptables-Проброс-портов-из-внешней-сети-во-вн/
правила NAT
http://www.rhd.ru/docs/manuals/enterprise/RHEL-4-Manual/security-guide/s1-firewall-ipt-fwd.html
#/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
#/sbin/sysctl -w net.ipv4.ip_forward=1
Чтобы узлы локальной сети с частными IP-адресами могли связываться с внешними сетями, настройте на брандмауэре подмену IP, которая замаскирует узлы локальной сети под IP-адресом внешнего интерфейса брандмауэра (в данном случае, eth0):
четверг, 4 декабря 2008 г.
Traffic Control And Report addon для проекта IPCop
Эта программа (аддон) является дополнением для брандмауэра с открытым исходным кодом IPCop. TCAR это сокращение от TrafficControlAndReport.
Основная идея:
Данный аддон является биллинговой системой для рабочих групп. Он предназначен для тарификации трафика, скачанного пользователями зеленого (GREEN) или синего (BLUE) интерфейса, а также для контроля доступа пользователей к серверу ipcop.
(Deferred: local mailer (/usr/bin/procmail) exited
Проблема оказалась в перенаправление почты на mail.ru одного пользователя через запись
в файле aliases.
понедельник, 1 декабря 2008 г.
Quagga
Google Mobilizer
среда, 26 ноября 2008 г.
Создание гиперссылки внутри страницы
понедельник, 24 ноября 2008 г.
Если что-то надо сделать больше, чем один раз - значит надо писать скрипт
Из опыта работы сисадмином я вынес одну мысль - "Если что-то надо сделать больше, чем один раз - значит надо писать скрипт". К примеру, если каждое утро нужно проверять состояние своих серверов, тогда я пишу bash-скрипт, который собирает нужную информацию, придает ей нужный вид и отправляет отчет по почте. Если нужно сменить конфигурацию на 12 различных машинах, для этого я напишу скрипт. Казалось бы, проделать мелкую работу можно вручную и это будет проще, чем написать и отладить соответствующий скрипт. Однако в моем подходе к работе есть некоторые преимущества. Когда скрипт написан и отлажен, значит его можно повторять в будущем, его запуск можно поручить низкоквалифицированным техникам, либо автоматизировать его выполнение. И вам не придется выполнять рутинные операции, все возьмет на себя скрипт, и сделает это четко и гарантированно. Вернемся к скриптам чуть позже.
Чтобы задействовать мощь скриптов для управления несколькими серверами, нужно настроить для каждого сервера беспарольный доступ по сертификатам. Для каждого сервера это займет не более нескольких минут - однако сделает жизнь куда легче. Когда вводить пароль не приходится, операции передачи файлов, резервное копирование и профилактические операции - все это можно писать в скриптах. В сети есть множество инструкций, как настроить аутентификацию по сертификатам, этот процесс здесь описан не будет.
Итак, аутентификацию настроили, теперь будем упрощать нашу работу. Для начала напишем скрипт, который определяет некоторые полезные переменные, к примеру:
# servers.sh export MAILSERVERS="server1 server2 server3" export WEBSERVERS="www1 www2 www3 www4"
После этого я могу написать простой скрипт, что-то вроде этого:
#!/bin/bash ### Сколько свободного места на почтовых серверах source ./servers.sh for i in ${MAILSERVERS} ; do echo =========${i} ============= ssh root@${i} "df" echo ============ ============= done
Этот простой скрипт быстро сообщает мне о наличии свободного места на почтовых серверах. Его также можно использовать как шаблон для других задач. Когда мне нужно написать другой скрипт, я делаю копию этого скрипта, меняю комментарий на второй строке и меняю тело цикла.
Все мои скрипты подключают файл servers.sh - это центральный конфигурационный файл. Когда я добавляю или убираю сервер, я просто редактирую соответствующим образом этот файл.
Обратите внимание на комментарий на второй строчке. Когда у вас накопится, к примеру, 50 различных скриптов, станет сложно запоминать, что делает каждый из них. Можно, конечно, именовать их наподобиесвободное_место_на_почтовых_серверах.sh, но мне так не нравится. Так что когда мне нужно узнать, что делает какой-либо скрипт, я набираю:
grep "###" *
Эта команда выводит мне список скриптов с кратким описанием того, что они делают.
Еще из своего опыта я вынес такую технику, что каждый скрипт в зависимости от задачи выполняется каждый день, неделю или месяц - я помещаю его в расписание cron, и результат выполнения приходит мне по электронной почте. Во многих системах есть каталоги, из которых cron выполняет скрипты каждый час (hourly), ежедневно (daily), или еженедельно (weekly). Однако мне не нравится такой подход, ведь администратор должен точно знать, когда должна выполняться операция, а не cron должен решать это за него. Поэтому я предпочитаю ручное редактирование crontab. К примеру, я хочу, чтобы резервное копирование выполнялось в нерабочее время. У меня есть более срочные дела, чем изучение формата crontab, поэтому в каждый такой файл я помещаю следующую строку:
# min hour dom month dow command
Она помогает мне быстро писать задания, и двигаться дальше. Это одна из простейших вещей, которая может сохранить время и силы.
Журналирование (через syslog) - это функция любой Linux-системы, однако по причине большого объема файлов журналов, эти возможности используются не в полную силу. Обычно администраторы настраивают logrotate для удаления старых журналов. Лишь когда что-то происходит, администратор смотрит в логи и ищет причину сбоя. В syslog я добавил журналирование веб-серверов, файрволла, почты и других служб. Никогда не любил читать логи строка за строкой, выискивая там ценную информацию. Вместо этого весьма полезно написать что-то вроде программы для анализа журналов, пусть даже это будет несколько операций grep. Эта программа должна развиваться вами, чтоб она могла отбрасывать все больше и больше ненужных данных. Когда вы сделаете это, и настроите отправку отчетов по электронной почте, вам будет достаточно одного взгляда, чтоб понять, что все в порядке (или наоборот).
Мне кажется, что настраивать систему анализа журналов на нескольких серверах - это слишком много работы. Можно сделать так, чтобы сервера отправляли журналы на какой-то один компьютер. После этого понадобится настроить лишь один анализатор, и не придется распространять его конфигурацию по всем серверам. Для копирования файлов журналов можно воспользоваться удаленным доступом по SSH, а анализировать журналы локально.