Mysql размер лог-файла
Есть ли опция, ограничивающая mysql.log определённым размером? Бо каждые два месяца мне субд заканчивает диск 80-Гб логами, вручную их чистить просто забываю.
Есть ли опция, ограничивающая mysql.log определённым размером? Бо каждые два месяца мне субд заканчивает диск 80-Гб логами, вручную их чистить просто забываю.
PostgreSQL v9.0.4. Более новую поставить нет возможности.
Делаю дамп базы:
# pg_dump -Upostgres -p5432 -Fc -b --inserts --disable-dollar-quoting database > database.dump
Затем пытаюсь на свежесозданном кластере восстановить её:
# pg_restore -C -p5432 -Upostgres ./database.dump > import.log 2> error.log
База не создаётся. Может, я чего-то не понимаю, но про опцию -C сказано:
-C create the target database
Причём, первые 20 строчек лога выдают:
--
-- PostgreSQL database dump
--
SET statement_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = off;
SET check_function_bodies = false;
SET client_min_messages = warning;
SET escape_string_warning = off;
--
-- Name: mail_user; Type: DATABASE; Schema: -; Owner: postgres
--
CREATE DATABASE mail_user WITH TEMPLATE = template0 ENCODING = 'UTF8' LC_COLLATE = 'ru_RU.UTF-8' LC_CTYPE = 'ru_RU.UTF-8';
ALTER DATABASE mail_user OWNER TO postgres;
Добрый день!
Я счастливый обладатель сего работающего чуда. Когда железка покупалась, в комплекте шёл Serial для активации сбора статистики по SNMP и E-mail отправке состояний.
Так как железка довольно давно покупалась, диски уже канули в небытие, но статистику очень хочется. Постоянно мониторить StorView не очень рациональное решение.
Фирмы, которые поставляют подобное оборудование, запросили довольно много денег за покупку нового серийника.
Собственно, пара вопросов тем, кто сталкивался с етим RAID-массивом:
- законен ли будет подбор серийника, если железо покупалось вместе с ним, но сам серийник утерян?
- если законен, то можно ли как-то найти сабж?
Не очень хочется нарушать закон, вместе с тем очень хочется статистику. Объясните по сабжу, пжлст
Задача: организовать полный бекап кластера со всеми БД без остановки СУБД. Потом етот бекап планируется развернуть в качестве тестового кластера. Одна из баз весит 26Гб. Если pg_dumpall довольно быстро пишет дамп, то разворачивание етого бекапа при помощи psql происходит примерно по 10Мб/мин. 26Гб таким образом просто состарюсь ждать.
# psql -V
psql (PostgreSQL) 9.0.4
Прочитал вот ету статью: http://korzh.net/2011-04-rezervnoe-kopirovanie-baz-dannyx-v-subd-postgresql-o...
Попробовал организовать оба способа, но никаких файлов на выходе не получил.
Что, собственно, происходило. Когда я дошёл до строчки «select pg_start_backup('/db/backup/base/20130116');», postgres сначала матернулся:
ERROR: WAL level not sufficient for making an online backup
HINT: wal_level must be set to "archive" or "hot_standby" at server start.
ОК, поставил ему «wal_level = archive» и «archive_mode = on». Команда pg_backup_start затем выполнилась:
pg_start_backup
-----------------
8B/20
(1 row)
Смутило, что она выполнилась быстро - за секунды и после етого в папке назначения ничего не появилось.
Далее ругнулась команда «select pg_stop_backup()»:
NOTICE: pg_stop_backup cleanup done, waiting for required WAL segments to be archived
WARNING: pg_stop_backup still waiting for all required WAL segments to be archived (60 seconds elapsed)
HINT: Check that your archive_command is executing properly. pg_stop_backup can be cancelled safely, but the database backup will not be usable without all the WAL segments.
archive_command = 'test ! -f /db/base/backup_in_progress || cp -i %p /db/backup/archive/%f < /dev/null'
На етот раз и «pg_start_backup» и «pg_stop_backup» выполнились без ошибок, но опять же, ничего я не нашёл.
Скажите, я вобще правильно понимаю, что можно создать полный бекап БД по указанной статье и затем развернуть его гораздо быстрее, чем при помощи psql?
Если да, то почему у меня на выходе ничего нет?
Добрый день! Настроил связку nginx + php-fpm + eaccelerator.
Конфиг eaccelerator:
[eAccelerator]
extension="eaccelerator.so"
eaccelerator.shm_size="32"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.shm_max="0"
eaccelerator.cache_dir="/var/cache/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.compress="1"
eaccelerator.compress_level="9"
Сомнения возникли по тому поводу, что /var/cache/eaccelerator содержит только пустые каталоги. В них нет ни одного файла. Как я понимаю, модуль должен переводить в байт-код php-скрипты и хранить их какое-то время в кеше, но почему тогда кеш пуст?
Переехали с одного сервака на другой. Настраиваю exim. Конфиг один в один со старым.
Системы - ubuntu server 10.04. Адрес сервака пусть mydomain.org.
# cat /etc/exim4/update-exim4.conf.conf
dc_eximconfig_configtype='satellite'
dc_other_hostnames='localhost;www;www.localhost;www.mydomain.org'
dc_local_interfaces='127.0.0.1 ; ::1'
dc_readhost='www'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='11.22.33.44::25'
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'
Суть exim-a в том, чтобы принять письмо от скрипта php и передать его на релей mail.mydomain.org (другой сервак) для отправки.
Проблема в том, что первые несколько писем отправляются без ошибок. А затем очередь начинает пополнятся сообщениями из cron-a и некоторыми сервисными письмами. Сообщения из крона шлются на root@mydomain.org. Сервисные письма шлются из скриптов для сотрудников и клиентов на различные адреса и домены.
Сообщения из крона щё ладно, но плохо, что висят ети самые сервисные письма. Если пропихнуть такое письмо командой `exim -M messageID', то оно спокойно уходит. Если вручную ничего не делать, письмо может висеть часами. Ошибки сервисных писем на данный момент две:
retry time not reached for any host
Remote host 11.22.33.44 [11.22.33.44] closed connection in response to initial connection
Пробовал отправлять письма на root@mydomain.org через `exim -v root@mydomain.com'. 50/50 либо отправляет, либо «retry time not reached for any host».
Дополнительно хочу уточнить, что старый сервак mydomain.org был в одной локальной сети с mail.mydomain.org. Думаю, может в етом дело.
Также добавлю, что старый сервак, новый сервак и почтовый релей организованы в облаках, и на сеть грешу в самую последнюю очередь.
Что можете посоветовать по проблеме?
Столкнулся с проблемой, что автоподстановка в адресной строке выводит сайты, которых нету в журнале. Чистил все упоминания сайта в истории посещений, удалял его куки. Никакими способами не получается его удалить из числа автоподстановок. Набираю «mo», выдаётся «moswar.ru», как бы я не чистил всё вышеописанное. Стирать историю полностью и очищать куки всех сайтов не могу, нужно удалить конкретный сайт. Как быть?
Firefox 17
ОС, на которых ситуация повторяется: Linux Mint 14.1 (Nadya), Windows XP, Ubuntu 10.04
Есть такой код:
#include <list>
#include <stdio.h>
using namespace std;
class MyClass
{
public:
MyClass(int id);
~MyClass();
private:
int m_id;
};
int main(int argc, char * argv[])
{
list<MyClass*> m_list;
int i;
for (i = 1; i <= 4; ++i)
{
MyClass * m_myClass = new MyClass(i);
m_list.push_back(m_myClass);
}
m_list.clear();
return 0;
}
MyClass::MyClass(int id)
: m_id(id)
{
printf("MyClass::MyClass(%d)\n", id);
}
MyClass::~MyClass()
{
printf("MyClass::~MyClass(%d)\n", m_id);
}
Суть в том, что я циклически создаю объекты и помещаю их в list. Но как мне потом средствами самого list удалить все объекты из памяти? Или прийдётся ето делать вручную?
Вывод программы такой:
MyClass::MyClass(1)
MyClass::MyClass(2)
MyClass::MyClass(3)
MyClass::MyClass(4)
деструкторы класса не срабатывают. Может, я не правильно понимаю документацию, но здесь http://www.cplusplus.com/reference/list/list/clear/ написано:
All the elements in the list container are dropped: their destructors are called, and then they are removed from the list container, leaving it with a size of 0.
почему тогда в моём случае деструкторы не вызываются?
Сабж неожиданно для меня не определяется системой. Всегда, когда йоту вставляю в комп с убунтой начиная от 10.04, модем определяется, как сетевое устройство ethN. В моём случае - его нет. Более того, нету даже вывода lsusb - пусто.
# uname -a
Linux server 2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
# lsusb
Какой модуль отвечает за такие модемы и как узнать, почему он не определяется? Диод на модеме загорается, то есть, физически USB работает. Флешки определяются.
Проблема стандартная для нестандартного MTU - пинги, трейсы и прочая дигностика рабоает, а сайты открываются не очень хорошо.
Сеть такова: yota-модем вставлен в роутер Keenetic. Роутер подключен в общую сеть. В сети имеется сервак с Ubuntu 10.04. Сервер настроен на раздачу DHCP, сам стоит шлюзом:
# iptables -t mangle -L -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
TCPMSS tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
# iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 192.168.3.0/24 0.0.0.0/0
# ifconfig
eth0 Link encap:Ethernet HWaddr 50:e5:49:c1:47:8b
inet addr:192.168.3.3 Bcast:192.168.3.255 Mask:255.255.255.0
inet6 addr: fe80::52e5:49ff:fec1:478b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:19251625 errors:0 dropped:0 overruns:0 frame:0
TX packets:19599669 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:1000
RX bytes:11066820494 (11.0 GB) TX bytes:12212266417 (12.2 GB)
Interrupt:42
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:18546 errors:0 dropped:0 overruns:0 frame:0
TX packets:18546 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:9815256 (9.8 MB) TX bytes:9815256 (9.8 MB)
Клиентам в качестве главного шлюза присваивается адрес сервака. То биш, весь трафик идёт через него (мониторинг кинетика ето подтвердил - левых соединений нет).
Ситуация с MTU многим, думаю, известна - у них он равен 1400.
Конфиг роутера:
KEENETIC 4G> exec ifconfig
br0 Link encap:Ethernet HWaddr CC:5D:4E:B8:D8:12
inet addr:192.168.3.2 Bcast:192.168.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:876551 errors:0 dropped:0 overruns:0 frame:0
TX packets:901394 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:186258055 (177.6 MiB) TX bytes:614250252 (585.7 MiB)
eth2 Link encap:Ethernet HWaddr CC:5D:4E:B8:D8:12
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:876759 errors:0 dropped:0 overruns:0 frame:0
TX packets:901394 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:202063727 (192.7 MiB) TX bytes:619041599 (590.3 MiB)
Interrupt:3
eth2.1 Link encap:Ethernet HWaddr CC:5D:4E:B8:D8:12
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:876752 errors:0 dropped:0 overruns:0 frame:0
TX packets:901394 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:189788271 (180.9 MiB) TX bytes:617855828 (589.2 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
ra0 Link encap:Ethernet HWaddr CC:5D:4E:B8:D8:12
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3685914 errors:0 dropped:0 overruns:0 frame:0
TX packets:41136 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:466992330 (445.3 MiB) TX bytes:0 (0.0 B)
Interrupt:4
wimax0 Link encap:Ethernet HWaddr 00:09:3B:F0:1A:40
inet addr:10.0.0.10 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1400 Metric:1
RX packets:871046 errors:0 dropped:0 overruns:0 frame:0
TX packets:823436 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:592154514 (564.7 MiB) TX bytes:221413667 (211.1 MiB)
KEENETIC 4G> exec iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- 0.0.0.0/0 10.0.0.10 tcp dpt:22 to:192.168.3.3
DNAT udp -- 0.0.0.0/0 10.0.0.10 udp dpt:22 to:192.168.3.3
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE udp -- 192.168.3.0/24 192.168.3.3 udp dpt:22
MASQUERADE tcp -- 192.168.3.0/24 192.168.3.3 tcp dpt:22
SNAT all -- 0.0.0.0/0 0.0.0.0/0 to:10.0.0.10
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
KEENETIC 4G> exec iptables -t mangle -L -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
TCPMSS tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
TCPMSS tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Казалось бы, при наличии TCPMSS везде, де только можно, клиенты должны договариватся с сервером об MTU, но проблема на месте.
В данный момент поменял настройки на серваке:
# ifconfig eth0 mtu 1372
Такой размер нашёл здесь: http://kubuntu.ru/node/4559
Дополнительно поменял рамер MTU и на роутере на всех интерфейсах, даже на беспроводной:
# ifconfig br0 mtu 1372
# ifconfig eth2 mtu 1372
# ifconfig eth2.1 mtu 1372
# ifconfig ra0 mtu 1372
В йоте специалисты говорят, что MTU надо менять на клиентах - тогда проблем вобще не будет. Но поменять MTU на компах с WinXP и Win7 в количестве пусть и 20-ти, мне не представляется быстрым и умным.
В чём мои вопросы: - всё ли я сделал, что мог, для того, чтобы победить проблемы с MTU на уровне шлюзов? - верить ли спецам из Yota и настраивать ли каждый комп в отдельности?
Сабж. Хочу смотреть, у кого какая скорость потребления трафика в данный момент и статистика за промежуток времени.
Киньте ссылку на мануал по етой теме или описание, хотя бы, как с сетью работать.
Понимаю, что баян, но я не могу подобрать теги, по которым гуглить. Везде выдают zabbix java gateway, но я же наивно надеюсь, что ето не оно?
В данный момент установил zabbix-server на серваке, с которого буду смотреть статистику, и zabbix-agent на шлюзе. Оба - ubuntu-server 12.04
Есть проблема в быстром обрыве соединения по ssh при неактивности, если соединение было установлено на комп в локальной сети посредством DNAT. Если установить соединение на шлюз, а со шлюза на комп в локальной сети, то ети оба соединения могут сколь угодно долго висеть, но при пробросе портов отваливается через 2 минуты неактивности.
IP внешний, ip_forwarding естественно включен. Правило в iptables:
iptables -tnat -A PREROUTING -d 11.22.33.205/32 -p tcp -m tcp --dport 4210 -j DNAT --to-destination 192.168.1.210:22
Что посмотреть, кого откопать?
Предисловие: хочу опробовать динамический конфиг, потому как «LDAP свойственно обрубать старые хвосты и возможно скоро статический slapd.conf в новых версиях просто не будет поддерживатся» (c) откуда-то_с_просторов_интернета. Да и просто для опыта, думаю, пригодится.
Не пойму, как мне отредактировать содержимое /etc/ldap/slapd.d. В самих файлах ldif прописано, что
AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
Составил файлик ldif для добавления аттрибутов:
dn: cn=config
olcLogFile: /var/log/slapd.log
Применяю:
# slapadd -l ~/add.ldif -b cn=config -F /etc/ldap/slapd.d -v
slapadd: dn="cn=config" (line=1): no objectClass attribute
_#################### 100.00% eta none elapsed none fast!
Closing DB...
# ldapadd -f ~/add.ldif -D cn=config
ldap_bind: Server is unwilling to perform (53)
additional info: unauthenticated bind (DN with no password) disallowed
# ldapadd -f ~/add.ldif -D cn=config -W
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
# ldapadd -f ~/add.ldif -D cn=admin,dc=mydomain,dc=local -W
Enter LDAP Password:
adding new entry "cn=config"
ldap_add: Insufficient access (50)
#
Прочитал кучу манов, пишу сюда просто чуя тупик моей соображалки..
Настроил LDAP, добавил к нему связку smb. Администрированию поддаётся, самба работает на ура. Решил сегодня завести одну линуксовую машину в домен, но возникла проблема. `getent {passwd|group|shadow}` выдают данные о новом пользователе, `su %ldap_user%` срабатывает, но по ssh доступ на ету линуксовую машину отвергается.
На сервере ситуация почти обратная. По ssh под пользователем зайти могу, однако заходит в sh, хотя в ldap для него указано /bin/bash. Если набрать bash, то в строке приглашения значится «У меня нет имени!@server». И такая же строка, если просто набрать `su %ldap_user%`.
Операционка на обоих компах Ubuntu Server 12.04
Конфиги сервера:
# cat /etc/ldap.conf | grep -vE '^#'
host 192.168.1.200
base dc=mydomain,dc=local
uri ldapi:///mydomain.local
ldap_version 3
binddn cn=proxyuser,dc=mydomain,dc=local
bindpw PASSWORD
rootbinddn cn=admin,dc=mydomain,dc=local
pam_password md5
nss_initgroups_ignoreusers avahi,backup,bin,colord,daemon,firebird,ftp,games,gnats,irc,landscape,libuuid,libvirt-dnsmasq,libvirt-qemu,list,lp,mail,man,messagebus,news,openldap,postgres,proftpd,proxy,root,sshd,statd,sync,sys,syslog,usr1cv8,uucp,whoopsie,www-data
# cat /etc/nsswitch.conf
passwd: files ldap
group: files ldap
shadow: files ldap
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
Конфиги клиента:
# cat /etc/ldap.conf | grep -vE '^#'
host 192.168.1.200
base dc=mydomain,dc=local
uri ldap:///192.168.1.200
ldap_version 3
binddn cn=proxyuser,dc=example,dc=net
bindpw PASSWORD
rootbinddn cn=admin,dc=mydomain,dc=local
pam_password md5
nss_initgroups_ignoreusers backup,bin,daemon,games,gnats,irc,landscape,libuuid,list,lp,mail,man,messagebus,news,proxy,root,sshd,sync,sys,syslog,uucp,whoopsie,www-data
/etc/pam.d/common-{auth,account,password} идентичны на обоих компах. Предполагаю, дело не в них, но при надобности выложу
/etc/pam.d/common-session отличается одной строкой (есть на сервере, нету на клиенте):
session optional pam_ck_connector.so nox11
Логи сервер: (auth.log)
Nov 20 14:16:06 localhost sshd[9105]: Received disconnect from 192.168.1.111: 11: disconnected by user
Nov 20 14:16:06 localhost sshd[9105]: pam_unix(sshd:session): session closed for user root
Nov 20 14:16:12 localhost sshd[9559]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=box.localnet.antora user=ldap_user
Nov 20 14:16:12 localhost sshd[9559]: Accepted password for ldap_user from 192.168.1.111 port 44191 ssh2
Nov 20 14:16:12 localhost sshd[9559]: pam_unix(sshd:session): session opened for user ldap_user by (uid=0)
Nov 20 14:16:14 localhost -bash: nss_ldap: failed to bind to LDAP server ldap://192.168.1.200: Invalid credentials
Nov 20 14:16:14 localhost -bash: nss_ldap: failed to bind to LDAP server ldapi:///mydomain.local: Invalid credentials
Nov 20 14:16:14 localhost -bash: nss_ldap: reconnecting to LDAP server...
Nov 20 14:16:14 localhost -bash: nss_ldap: failed to bind to LDAP server ldap://192.168.1.200: Invalid credentials
Nov 20 14:16:14 localhost -bash: nss_ldap: failed to bind to LDAP server ldapi:///mydomain.local: Invalid credentials
Nov 20 14:16:14 localhost -bash: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)...
Nov 20 14:16:15 localhost -bash: nss_ldap: failed to bind to LDAP server ldap://192.168.1.200: Invalid credentials
Nov 20 14:16:15 localhost -bash: nss_ldap: failed to bind to LDAP server ldapi:///mydomain.local: Invalid credentials
Nov 20 14:16:15 localhost -bash: nss_ldap: could not search LDAP server - Server is unavailable
Nov 20 14:16:16 localhost sshd[9702]: Received disconnect from 192.168.1.111: 11: disconnected by user
Nov 20 14:16:16 localhost sshd[9559]: pam_unix(sshd:session): session closed for user ldap_user
Логи клиента (auth.log):
Nov 20 14:17:22 localhost sshd[1469]: Received disconnect from 192.168.1.111: 11: disconnected by user
Nov 20 14:17:22 localhost sshd[1469]: pam_unix(sshd:session): session closed for user root
Nov 20 14:17:27 localhost sshd[1711]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=box.localnet.antora user=ldap_user
Nov 20 14:17:27 localhost sshd[1711]: pam_ldap: ldap_simple_bind Can't contact LDAP server
Nov 20 14:17:27 localhost sshd[1711]: pam_ldap: reconnecting to LDAP server...
Nov 20 14:17:27 localhost sshd[1711]: pam_ldap: ldap_simple_bind Can't contact LDAP server
Nov 20 14:17:29 localhost sshd[1711]: Failed password for ldap_user from 192.168.1.111 port 59674 ssh2
Что необходимо подправить, чтобы на сервере:
- определялось имя пользователя в bash
- сессия ssh открывалась в том процессоре, который указан для пользователя (например /bin/bash)
а на клиенте:
- пускал бы по ssh
?
Хочу с сервака сливать себе на комп бекапы файлов. Вопрос в том, что владельцы и группы файлов различные, а rsync на локальной машине я не хочу запускать из-под root, поетому есть мысль архивировать на лету. Вопрос: как?
Собственно полное описание задачи: как можно сливать с сервера файлы в tar-архив, не затирая владельца, группу и права, если rsync (или любая другая прога) запущена из-под непривилегированного пользователя на локальной машине?
При выполнении `ifconfig` есть такая строка:
RX packets:23365517 errors:0 dropped:13252 overruns:0 frame:0
Почтовая связка axigen+spamd. Спам пропускает почти через раз. Хотя, spamc на список контрольных писем реагирует нормально. Написал акисгеновцам, подсказали запустить spamd в режиме отладки. При анализе логов обнаружились строки:
Nov 12 12:09:53 mail spamd[4568]: config: using "/.spamassassin" for user state dir
Nov 12 12:09:53 mail spamd[4568]: config: mkdir /.spamassassin failed: mkdir /.spamassassin: Ð<9e>Ñ<82>казано в доÑ<81>Ñ<82>Ñ<83>пе at /usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin.pm line 1853
Почему он ломится в «/.spamassassin», если у меня рабочие файлы антиспама в ~/.spamassassin? `grep '\.spamassassin' /etc/mail/spamassassin` ничего путного не выдал.
Добрый день! В данный момент на шлюзе имеются такие настройки:
# ifconfig
eth0 Link encap:Ethernet HWaddr cc:cc:cc:cc:cc:cc
inet addr:192.168.200.10 Bcast:192.168.200.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:29 Base address:0xe000
eth1 Link encap:Ethernet HWaddr dd:dd:dd:dd:dd:dd
inet6 addr: fe80::214:d1ff:fe15:bd24/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1400 Metric:1
RX packets:13045311 errors:0 dropped:0 overruns:0 frame:0
TX packets:12113512 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9394208816 (9.3 GB) TX bytes:2627579737 (2.6 GB)
Interrupt:21 Base address:0xbc00
eth1:1 Link encap:Ethernet HWaddr dd:dd:dd:dd:dd:dd
inet addr:11.22.33.205 Bcast:11.22.33.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1400 Metric:1
Interrupt:21 Base address:0xbc00
eth2 Link encap:Ethernet HWaddr ee:ee:ee:ee:ee:ee
inet addr:192.168.1.241 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::214:d1ff:fe10:c40e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14237829 errors:0 dropped:341 overruns:0 frame:0
TX packets:15173684 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3663482603 (3.6 GB) TX bytes:10402933575 (10.4 GB)
Interrupt:20 Base address:0x2000
eth2:1 Link encap:Ethernet HWaddr ee:ee:ee:ee:ee:ee
inet addr:192.168.1.240 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:20 Base address:0x2000
eth2:2 Link encap:Ethernet HWaddr ee:ee:ee:ee:ee:ee
inet addr:10.1.1.1 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:20 Base address:0x2000
lo Link encap:Локальная петля (Loopback)
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:484108 errors:0 dropped:0 overruns:0 frame:0
TX packets:484108 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:182401129 (182.4 MB) TX bytes:182401129 (182.4 MB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.130.1 P-t-P:172.16.130.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:56258 errors:0 dropped:0 overruns:0 frame:0
TX packets:36244 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:4824487 (4.8 MB) TX bytes:6445844 (6.4 MB)
11.22.33.205 - наш выделенный IP-адрес
# iptables -tnat -L -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- 0.0.0.0/0 11.22.33.205 tcp dpt:2447 to:192.168.1.247:22
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- 10.1.1.5 0.0.0.0/0 mark match !0x1 to:11.22.33.205
SNAT all -- 172.16.130.0/24 0.0.0.0/0 to:192.168.1.240
SECOND_ROUTE all -- 192.168.1.0/24 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain SECOND_ROUTE (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 192.168.1.0/24
SNAT all -- 192.168.1.0/24 0.0.0.0/0 mark match !0x1 to:11.22.33.205
# iptables -tmangle -L -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
MARK all -- 0.0.0.0/0 192.168.3.0/24 MARK xset 0x1/0xffffffff
MARK all -- 0.0.0.0/0 10.10.10.0/24 MARK xset 0x1/0xffffffff
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
MARK all -- 0.0.0.0/0 192.168.3.0/24 MARK xset 0x1/0xffffffff
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
# iptables -tfilter -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
# ip rule
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
# ip route show table main
55.66.77.20 via 11.22.33.205 dev eth1
172.16.130.2 dev tun0 proto kernel scope link src 172.16.130.1
172.16.130.0/24 via 172.16.130.2 dev tun0
11.22.33.0/24 dev eth1 proto kernel scope link src 11.22.33.205
192.168.3.0/24 dev eth1 scope link src 192.168.1.241
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.241
192.168.200.0/24 dev eth0 proto kernel scope link src 192.168.200.10
10.0.0.0/8 dev eth2 proto kernel scope link src 10.1.1.1
default via 11.22.33.205 dev eth1 scope link
# ip route show table local
local 192.168.200.10 dev eth0 proto kernel scope host src 192.168.200.10
broadcast 192.168.1.0 dev eth2 proto kernel scope link src 192.168.1.241
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
broadcast 192.168.200.255 dev eth0 proto kernel scope link src 192.168.200.10
broadcast 11.22.33.0 dev eth1 proto kernel scope link src 11.22.33.205
broadcast 10.0.0.0 dev eth2 proto kernel scope link src 10.1.1.1
local 172.16.130.1 dev tun0 proto kernel scope host src 172.16.130.1
local 192.168.1.240 dev eth2 proto kernel scope host src 192.168.1.241
local 192.168.1.241 dev eth2 proto kernel scope host src 192.168.1.241
broadcast 192.168.1.255 dev eth2 proto kernel scope link src 192.168.1.241
broadcast 10.255.255.255 dev eth2 proto kernel scope link src 10.1.1.1
broadcast 192.168.200.0 dev eth0 proto kernel scope link src 192.168.200.10
broadcast 11.22.33.255 dev eth1 proto kernel scope link src 11.22.33.205
local 10.1.1.1 dev eth2 proto kernel scope host src 10.1.1.1
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 11.22.33.205 dev eth1 proto kernel scope host src 11.22.33.205
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
# route -n
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
55.66.77.20 11.22.33.205 255.255.255.255 UGH 0 0 0 eth1
172.16.130.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
172.16.130.0 172.16.130.2 255.255.255.0 UG 0 0 0 tun0
11.22.33.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
192.168.200.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth2
0.0.0.0 11.22.33.205 0.0.0.0 UG 0 0 0 eth1
Есть IPSec, настроен между нашим 11.22.33.205 и удалённым 55.66.77.20 шлюзами. В сети на нескольких компах стоят тестовые веб-сервера, на шлюзе стоит nginx, который проксирует запросы извне в сеть. Плюс ко всему, в iptables существует прямой проброс портов для доступа на компы внутри сети. На данный момент всё работает, как требуется.
В сети есть и другой шлюз - 192.168.1.250. Хочу сделать таким образом, чтобы интернет шёл через него, IPSec же должен гулять по первому каналу. А также должны работать внутренние сайты извне и доступ ко внутренним компам через проброс портов. Перенастраиваю следующим образом:
В iptables таблице nat меняю последнюю строку в цепочке SECOND_ROUTE:
Chain SECOND_ROUTE (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 192.168.1.0/24
SNAT all -- 192.168.1.0/24 0.0.0.0/0 mark match !0x1 to:192.168.1.241
После етого:
# route del default
# route add default gw 192.168.1.250
# ip route add 55.66.77.20 via 11.22.33.205
# ip rule add from 11.22.33.205 table 100
# ip route add default via 11.22.33.205 table 100
Получается следующая маршрутизация:
# ip rule
0: from all lookup local
32765: from 11.22.33.205 lookup 100
32766: from all lookup main
32767: from all lookup default
# ip route show table local
local 192.168.200.10 dev eth0 proto kernel scope host src 192.168.200.10
broadcast 192.168.1.0 dev eth2 proto kernel scope link src 192.168.1.241
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
broadcast 192.168.200.255 dev eth0 proto kernel scope link src 192.168.200.10
broadcast 11.22.33.0 dev eth1 proto kernel scope link src 11.22.33.205
broadcast 10.0.0.0 dev eth2 proto kernel scope link src 10.1.1.1
local 172.16.130.1 dev tun0 proto kernel scope host src 172.16.130.1
local 192.168.1.240 dev eth2 proto kernel scope host src 192.168.1.241
local 192.168.1.241 dev eth2 proto kernel scope host src 192.168.1.241
broadcast 192.168.1.255 dev eth2 proto kernel scope link src 192.168.1.241
broadcast 10.255.255.255 dev eth2 proto kernel scope link src 10.1.1.1
broadcast 192.168.200.0 dev eth0 proto kernel scope link src 192.168.200.10
broadcast 11.22.33.255 dev eth1 proto kernel scope link src 11.22.33.205
local 10.1.1.1 dev eth2 proto kernel scope host src 10.1.1.1
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 11.22.33.205 dev eth1 proto kernel scope host src 11.22.33.205
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
# ip route show table main
55.66.77.20 via 11.22.33.205 dev eth1
172.16.130.2 dev tun0 proto kernel scope link src 172.16.130.1
172.16.130.0/24 via 172.16.130.2 dev tun0
11.22.33.0/24 dev eth1 proto kernel scope link src 11.22.33.205
192.168.3.0/24 dev eth1 scope link src 192.168.1.241
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.241
192.168.200.0/24 dev eth0 proto kernel scope link src 192.168.200.10
10.0.0.0/8 dev eth2 proto kernel scope link src 10.1.1.1
default via 192.168.1.250 dev eth2
# ip route show table 100
default via 11.22.33.205 dev eth1
Теперь проблемы:
- перестаёт пинговатся 11.22.33.205 с компов из сети. Извне внутренние сайты остаются доступными - nginx отрабатывает нормально.
- не работает проброс портов извне. Последнее действие, которое iptables совершает с пакетом - DNAT, дальше я пакета не вижу нигде.
Как побороть ети проблемы?
Добрый день!
# ifconfig
eth0 Link encap:Ethernet HWaddr 1a:1a:1a:1a:1a:1a
inet addr:192.168.200.10 Bcast:192.168.200.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:28 Base address:0xe000
eth1 Link encap:Ethernet HWaddr 1b:1b:1b:1b:1b:1b
inet6 addr: fe70::224:d1ff:fe15:bd24/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:365574 errors:0 dropped:0 overruns:0 frame:0
TX packets:319358 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:305510970 (305.5 MB) TX bytes:43551826 (43.5 MB)
Interrupt:21 Base address:0xbc00
eth1:1 Link encap:Ethernet HWaddr 1b:1b:1b:1b:1b:1b
inet addr:11.22.33.205 Bcast:11.22.33.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:21 Base address:0xbc00
eth1:2 Link encap:Ethernet HWaddr 1b:1b:1b:1b:1b:1b
inet addr:44.33.22.122 Bcast:44.33.22.127 Mask:255.255.255.248
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:21 Base address:0xbc00
eth2 Link encap:Ethernet HWaddr 1c:1c:1c:1c:1c:1c
inet addr:192.168.1.241 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe70::224:d1ff:fe10:c40e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:268328 errors:0 dropped:0 overruns:0 frame:0
TX packets:292235 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:25363710 (25.3 MB) TX bytes:300222487 (300.2 MB)
Interrupt:20 Base address:0x2000
eth2:1 Link encap:Ethernet HWaddr 1c:1c:1c:1c:1c:1c
inet addr:192.168.1.240 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:20 Base address:0x2000
eth1.10 Link encap:Ethernet HWaddr 1a:1a:1a:1a:1a:1a
inet addr:44.33.22.125 Bcast:44.33.22.127 Mask:255.255.255.248
inet6 addr: fe70::224:d1ff:fe15:bd24/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:53 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:4830 (4.8 KB)
eth1.20 Link encap:Ethernet HWaddr 1a:1a:1a:1a:1a:1a
inet addr:11.22.33.207 Bcast:11.22.33.255 Mask:255.255.255.0
inet6 addr: fe70::224:d1ff:fe15:bd24/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:80 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:6072 (6.0 KB)
lo Link encap:Локальная петля (Loopback)
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:20300 errors:0 dropped:0 overruns:0 frame:0
TX packets:20300 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2344755 (2.3 MB) TX bytes:2344755 (2.3 MB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.130.1 P-t-P:172.16.130.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
# ip route show
55.66.77.20 via 11.22.33.205 dev eth1
172.16.130.2 dev tun0 proto kernel scope link src 172.16.130.1
44.33.22.120/29 dev eth1.10 proto kernel scope link src 44.33.22.125
44.33.22.120/29 dev eth1 proto kernel scope link src 44.33.22.122
172.16.130.0/24 via 172.16.130.2 dev tun0
11.22.33.0/24 dev eth1.20 proto kernel scope link src 11.22.33.207
11.22.33.0/24 dev eth1 proto kernel scope link src 11.22.33.205
192.168.3.0/24 dev eth1 scope link src 192.168.1.241
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.241
192.168.200.0/24 dev eth0 proto kernel scope link src 192.168.200.10
10.0.0.0/8 dev eth2 proto kernel scope link src 10.1.1.1
default via 192.168.1.250 dev eth2
# iptables -tnat -L -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
SQUID_ROUTE all -- 0.0.0.0/0 0.0.0.0/0
DNAT tcp -- 0.0.0.0/0 11.22.33.205 tcp dpt:1230 to:192.168.1.100:22
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- 172.16.201.172 0.0.0.0/0 mark match !0x1 to:44.33.22.122
SNAT all -- 172.16.130.0/24 0.0.0.0/0 to:192.168.1.240
SECOND_ROUTE all -- 192.168.1.0/24 0.0.0.0/0
Chain SECOND_ROUTE (1 references)
target prot opt source destination
SNAT all -- 192.168.1.0/24 0.0.0.0/0 mark match !0x1 to:192.168.1.241
Chain SQUID_ROUTE (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 192.168.1.0/24
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 80,8080 to:192.168.1.240:3128
# iptables -t mangle -L -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
MARK all -- 0.0.0.0/0 192.168.2.0/24 MARK xset 0x1/0xffffffff
MARK all -- 0.0.0.0/0 10.10.10.0/24 MARK xset 0x1/0xffffffff
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
MARK all -- 0.0.0.0/0 192.168.2.0/24 MARK xset 0x1/0xffffffff
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
11.22.33.205 - наш внешний адрес
44.33.22.122 - наш второй внешний адрес
192.168.1.250 - ADSL-роутер внутри локальной сети
В сети имеются web-серверы, доступ к которым осуществляется через адрес 11.22.33.205. Также имеется IPSec-соединение с удалённым адресом 11.22.33.205 <-> 55.66.77.20.
Задача: - Необходимо, чтобы исходящие в интернет пакеты, не относящиеся к IPSec, с клиентов и шлюза 192.168.1.240 ходили через шлюз 192.168.1.250. Соответственно, у всех клиентов сети будет указан 192.168.1.240 в качестве шлюза.
- Должна работать IPSec (как выше сказано, пакеты до удалённого адреса 55.66.77.20 должны уходить только с 11.22.33.205).
- Пакеты внешних соединений, установленных на 11.22.33.205 естественно должны ходить через 11.22.33.205.
Что имеем: в данный момент удалось орагнизовать первые два пункта. Проблема с третьим. В идеале должно быть так: удалённый клиент (пусть будет 88.88.88.88) запрашивает сайт с нашего адреса 11.22.33.205, устанавливается соединение и, в рамках данного содинения, наш шлюз должен отдавать пакеты через етот интерфейс. Если же кто-то из сети или сам шлюз решит установить соединение 88.88.88.88:1234, то такой пакет должен будет уйти через 192.168.1.250
Делал по етой статье: http://gazette.linux.ru.net/rus/articles/lartc/x348.html но столкнулся с той проблемой, что у меня два разномастных канала - один настроен через сетевую с внешним IP, другой - через ADSL-модем, который находится внутри сети.
Возникла мысль, что соединения как-то можно маркировать посредством iptables, но в мануалах написано, что MARK маркирует только одиночные пакеты, да и то внутри шлюза. Советуют играть с TOS. По нему есть два вопроса: будет ли один TOS принадлежать всем пакетам из одного соединения? И как правильно его задавать?
В общем, посоветуйте что-нть по задаче
Настроил bind, локально имена из моей зоны резолвятся. А вот если делать nslookup или dig по сети, ответа нет.
Система: Ubuntu 12.04
# named -v
BIND 9.8.1-P1
/etc/hosts на серваке с bind-ом (192.168.1.160)
127.0.0.1 localhost
127.0.1.1 dimon-desktop
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Зона:
/etc/bind/named.conf.local
zone "local" {
type master;
file "local/local";
notify no;
};
/etc/bind/local/local
$TTL 3600
@ SOA local. root.local. (
2012092501 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expiry
86400 ; TTL
)
@ NS ns.
pixun A 192.168.1.160
/etc/resolv.conf пустой
С сервера
# dig @192.168.1.160 pixun.local.
; <<>> DiG 9.8.1-P1 <<>> @192.168.1.160 pixun.local.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28818
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;pixun.local. IN A
;; ANSWER SECTION:
pixun.local. 3600 IN A 192.168.1.160
;; AUTHORITY SECTION:
local. 3600 IN NS ns.
;; Query time: 0 msec
;; SERVER: 192.168.1.160#53(192.168.1.160)
;; WHEN: Tue Sep 25 23:47:15 2012
;; MSG SIZE rcvd: 61
С клиента
# dig @192.168.1.160 pixun.local.
; <<>> DiG 9.7.0-P1 <<>> @192.168.1.160 pixun.local.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8715
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;pixun.local. IN A
;; AUTHORITY SECTION:
local. 10800 IN SOA localhost. nobody.localhost. 42 86400 43200 604800 10800
;; Query time: 36 msec
;; SERVER: 192.168.1.160#53(192.168.1.160)
;; WHEN: Tue Sep 25 23:47:55 2012
;; MSG SIZE rcvd: 81
ЧЯНТД? Почему при запросе с клиентов нет ответа?
← назад | следующие → |