Администрирование Windows, Linux, Postfix. SQUID: ноября 2012

среда, 28 ноября 2012 г.

SQUID and IPv6

Столкнулся с некой проблемой взаимодействия SQUID и IPv6 адресов. В частности при подключении по SSL к некоторым сайтам страница могла загружаться очень медленно от 90 до 300 сек. Причем где то на 90 секунде в access.log появлялась запись вида:
1354011161.038 59810 192.168.0.116 TCP_MISS/503 0 CONNECT vk.com:443 - DIRECT/2a00:bdc0:3:103:1:0:403:903
Решается это либо назначением карте IPv6 адреса, либо простым отключением IPv6 следующим образом:
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
echo 1 > /proc/sys/net/ipv6/conf/default/disable_ipv6

Openfire кэш

Openfire использует кэш для эффективной работы. Но размер кэша по умолчанию может оказаться мал, если у Вас в джаббере подключено много пользователей/групп. При этом в логах об ошибках вы можете увидеть множество сообщений такого плана:
Cache Roster was full, shrinked to 90% in 0ms.
…
Для решения этой проблемы вам следует добавить следующие параметры:

cache.group.size = 5242880
cache.group.maxLifetime = 3600000

cache.username2roster.size = 5242880
cache.username2roster.maxLifetime = 3600000

cache.userGroup.size = 5242880
cache.userGroup.maxLifetime = 3600000

cache.userCache.size = 2097152
cache.userCache.maxLifetime = 3600000

cache.groupMeta.size = 2097152
cache.groupMeta.maxLifetime = 3600000

Добавлять новые настройки следует через вкладку Server -> Server Manager -> System Properties.
После обновления настроек следует перезапустить службу.
Ссылка на оригинал: http://lapitoop.ru/

понедельник, 26 ноября 2012 г.

CIDR для чайников.

Как то пришлось мне столкнуться с CIDR, очень хотелось понять эту технологию, т.к очень смутно представлял я ее себе, в отличие от традиционного деления на сети (A, B,C) и традиционные маски вида 255.255.0.0. Облазив пол интернета, и прочитав статьи нескольких источников, через пару дней я понял суть технологии.
Итак начнем.
В традиционной технологий масок и ip мы имеем:
192.168.0.0 - сеть
255.255.255.0 - маска
11111111.11111111.11111111.00000000 - маска в двоичном виде.
Т..е маска состоит их 4-х байт либо 32 бит по 8 бит на каждый кусок до. Заполнив его весь 11111111111 мы получим число 255 по правилам перевода двоичных в десятичные 2*0+2*1+2*2 ...=255 (знак * - это возведение в степень). Например число 192 это 11000000 т.е
2*7+2*6=128+64=192. Вообщем в выше приведенном примере 3 байта или 24 бита отводится на адрес сети а 1 байт или 8 бит на адрес сети. В итоге мы получим адрес сети 192.168.0 остальная часть для адреса хоста, сколько в такой сети хостов определяется так:
2*8=256 ( но 256 - это диапазон 0-255), т.е 255 хостов, при этом вычтем 0 и 255 т.к это служебные адреса получим 253 хоста.
Вообщем адреса 192.168.0.1-192.168.0.254 и маской сети 255.255.255.0 будут иметь сеть 192.168.0.0 и при этом прекрасно пинговаться и работать в одной сети.

Тогда WTF 192.168.0.30/26.
Итак посмотрим как будет выглядеть это в традиционной записи.
Что такое 26? Это количество бит заполненных единицами. Как мы помним всего имеем 32 бита на весь адрес, посмотрим пример выше
192.168.0.0 - сеть
255.255.255.0 - маска
11111111.11111111.11111111.00000000 - маска в двоичном виде.
последние 8 бит нули, значит 192.168.0.0 в сокращенной нотации будет иметь такой вид
192.168.0.0./24 т.к 32-8=24 т.е у нас 8 бит на адрес хоста.
Переведем 26 в двоичный вид
11111111.11111111.11111111.11000000
Т.е как види мы добавили еще 2 единицы слева к последнему биту, что за число мы получим в последнем бите: 2*7+2*6=128+64=192.
Т.е маска в традиционной записи будет иметь вид:
255.255.255.192
Сколько хостов будем иметь в такой сети 32-26=6. Т.е остается 6 бит на адрес хоста 2*6=64 (отнимем 2 служебных)=62.
Вы наверное подумаете что мы получим сеть хостов от 192.168.0.192 до 192.168.0.255.
Нет, на самом же деле в с такой маской мы получим 256/64 (кол-во хостов в сети) = 4 подсети в сети 192.168.0.0 и эти подсети будут
Диапазон                          Сеть
192.168.0.1-192.168.0.62             192.168.0.0
192.168.0.65-192.168.0.126         192.168.0.64
192.168.0.129-192.168.0.190        192.168.0.128
192.168.0.193-192.168.0.254        192.168.0.192

Т.е машины с адресом 192.168.0.10/26 (255.255.255.192) и 192.168.0.70/26 (255.255.255.192) не будет видеть друг друга т.к первая находится в сети 192.168.0.0, вторая в 192.168.0.64. Но 192.168.0.10 и 192.168.0.30 будут в одной сети 192.168.0.0 и будут видеть друг друга.

Вот еще такой пример
172.18.0.0/17
255.255.255.128
11111111.11111111.10000000.00000000
Здесь мы получим такие диапазоны
Диапазон Сеть
172.18.1.1 -172.18.127.255           172.18.0.0
172.18.128.1 -172.18.255.255           172.18.128.0

Хостов в такой сети 32-17=15 и 2*15=32768 (-2 служебные)
Т.е хосты с адресами 172.18.1.120 и 172.18.90.220 будут видеть друг друга, а
172.18.1.120 и 172.18.160.220 нет.

Что дает CIDR?
CIDR позволяет отойти от традиционного деления на классы а также более гибко виделять диапазоны.
Например провайдеру требуется обслуживать сеть из 16 тысяч хостов, раньше бы ему пришлось выделять целую сеть B т.к С мала для таких целей, но B это более 65 тысяч хостов, что очень неэкномно. Более рационально выделить ему сеть в диапазоне
128.13.1.0 -128.13.64.255 т.е 128.13.0.0/18.

Как правильно переименовать пользователя в домене.

Предположим появилась необходимость переименовать некого пользователя домена irina на victor.
Итак условие задачи:

Имеется например старый пользователь настроенный irina и новый пользователь victor/ Необходимо, чтобы все настройки irina сохранились под новым именем включая принтеры, рабочий стол, сетевые диски и прочую лабуду.

Решение:

1) Создаем нового пользователя victor

2) Заходим под администратором и даем права админа victor.

3) Даем права на C:\Documents and Settings\irina на запись для victor.

4) Выходим из админа и логинимся под victor.

5) Перегружаем комп и заходим под админом, удаляем профиль victor а папку irina переименовываем в victor.

6) Заходим под пользователем victor и даем права записи на веку реестра HKCU.

7) Выходим из victor, заходим под админом, забираем у victor админские права, и снова заходм под victor.

8) Все работает.!!!!!!!!1

четверг, 15 ноября 2012 г.

Openfire и кририлица.

Итак вы установили Openfire сервер, завели в группы и пользователей на русском языке.

И уже почиваете от совершенных трудовых подвигов. Как вдруг обнаруживаете, что вместо имен пользователей и групп в вашем jabber клиенте отображаются какие то вопросы или крякозябры.

ВОТ РЕШЕНИЕ ВАШЕЙ ПРОБЛЕМЫ:

1) Прописать параметры в my.ini для mysql-server
[mysqld]
default-character-set=utf8
character-set-server=utf8
init-connect='SET NAMES utf8'

[client]
default-character-set=utf8

2)Создать базу данных jabber
CREATE DATABASE jabber CHARACTER SET utf8 COLLATE utf8_general_ci;
3)Создать пользователя базы данных для подключения openfire:
grant all on jabber.* to jabber@localhost identified by '123';
4) При настройке базы данныз из консоли либо в openfire.xml дописать
jdbc:mysql://localhost:3306/jb?useUnicode=true&characterEncoding=UTF-8&characterSetResults=UTF-8

Postfix.Temporary lookup failrue.Решено

Если не отправляются письма содержащие в поле from: кирилицу или другие не ASCII символы. А в maillog постоянно пишутся ошибки "Temporary lookup failrue".
Вот решение:
1) Необходимо кодировку всех таблиц по примеру:
alter table alias_domain character set utf8 collate utf8_general_ci;
2) В каждой таблице изменить кодировку каждого столбца на utf8:
alter table vacation modify email varchar(255) character set utf8;

Детальнее тут:
http://www.ogalik.ee/postfix-mysql-lookups-and-temporary-lookup-failure/

среда, 14 ноября 2012 г.

Настройка BIND и MS Windows

Необходимо настроить BIND так чтобы он одновремеено видел и адресса инета и резолвил локальные адреса для domain.com и был кэширующим сервером для этого необходимо на dc1 и dc2 организовать пересылку на это сервер. А на BIND /etc/named.conf в options прописать. rndc нам не нужно, поэтому с ним не заморачиваемся

forwarders {172.18.19.1}

И создать зоный по типу
zone domain.ua IN{
type forward;
forwarders {192.168.0.4; 192.168.0.4; };
};

zone 192.168.0.in-addr.arpa IN{
type forward;
forwarders {192.168.0.4; 192.168.0.4; };
};

Полный конфиг
options {
pid-file "/var/run/named/named.pid";
directory "/var/named";
allow-query {any; };
allow-recursion {127.0.0.1; 192.168.0.0/24; };
forwarders {172.18.19.1; 8.8.8.8; };};
zone "betonmash.ua" {
type forward;
forwarders {192.168.0.4; 192.168.0.5; };
};
zone "0.168.192.in-addr.arpa" {
type forward;
forwarders {192.168.0.4; 192.168.0.5; };
};

max-cahce-size=256M

среда, 28 ноября 2012 г.