Стихотворението е с автор Иван Адамов и е посветено на колегата Искрен който вечно задава някой въпрос свързан с линукс, и който горещо се старае да копира мрежовата топология на фирмата в негова домашна среда.
Въведението е от мен:
Николай: Всичко започна още от първият ден, когато започнах работа, дойде при мен и ме пита за vmware 🙂 Иван: и така се започна сага гореща, където той пита, а ти си на среща. виртуални машини на каишка държиш, той ти досажда а ти тихо ръмжиш.
Тъй като използвам cacti за мониторинг на сървърите ми, исках да добавя и домашния рутер TP-LINK TL-WR841N/ND v7 който има инсталиран OpenWRT, да мога да следя трафика му. За целта инсталирах пакета mini-snmpd тъй като е доста малък на размери (сравнение със snmpd) а TP-Link-a като цяло няма кой знае колко място :
root@OpenWrt:~# df -h
Filesystem Size Used Available Use% Mounted on
rootfs 1.1M 632.0K 456.0K 58% /
Използвах стандартния конфигурационен файл намиращ се в /etc/config/mini_snmpd като промених community, contact и location-a.
До тук всичко добре, обаче открих че през сървъра не виждам да е отворен порт-а на snmp-то (UDP 161), а през локалната мрежа си е ок.
Тук се досетих че имах наскоро подобен проблем със SSH демона, и тогава го оправих, като добавих SSH в /etc/config/firewall.
Ето как изглеждаха нещата на практика:
nmap от сървъра:
alpha:~# nmap -sU -p 161 192.168.168.101
Starting Nmap 6.00 ( http://nmap.org ) at 2014-01-26 12:02 EET
Nmap scan report for wifi (192.168.168.101)
Host is up (0.00050s latency).
PORT STATE SERVICE
161/udp closed snmp
nmap от вътрешната мрежа:
laptop ~ # nmap -sU -p 161 10.0.2.1
Starting Nmap 6.40 ( http://nmap.org ) at 2014-01-26 12:03 EET
Nmap scan report for 10.0.2.1
Host is up (0.0012s latency).
PORT STATE SERVICE
161/udp open|filtered snmp
Ето и какво промених за да оправя проблема:
добавих това в /etc/config/firewall:
#Allow snmp
config rule
option src wan
option proto udp
option dest_port 161
option target ACCEPT
И така в крайна сметка от сървъра нещата изглеждат вече така:
alpha:~# nmap -sU -p 161 192.168.168.101
Starting Nmap 6.00 ( http://nmap.org ) at 2014-01-26 12:18 EET
Nmap scan report for wifi (192.168.168.101)
Host is up (0.00061s latency).
PORT STATE SERVICE
161/udp open|filtered snmp
Тук идва и момента в настройката на cacti-то. Нямам идея дали това е от самия демон mini-snmp или от нещо друго, но при стандартни настройки за Downed Device Detection да бъде SNMP Uptime, Cacti-то казва : SNMP Information SNMP error.
Четох в нета че този проблем се оправя като се сменя от SNMP Uptime на Ping, и Ping Method се слага на ICMP Ping.
Така при пуснато Verbose Query, резултата е следния: Data Query Debug Information
+ Running data query [1].
+ Found type = '3' [SNMP Query].
+ Found data query XML file at '/usr/share/cacti/site/resource/snmp_queries/interface.xml'
+ XML file parsed ok.
+ Executing SNMP get for num of indexes @ '.1.3.6.1.2.1.2.1.0' Index Count: 3
+ Executing SNMP walk for list of indexes @ '.1.3.6.1.2.1.2.2.1.1' Index Count: 3
+ Index found at OID: 'iso.3.6.1.2.1.2.2.1.1.1' value: '1'
+ Index found at OID: 'iso.3.6.1.2.1.2.2.1.1.2' value: '2'
+ Index found at OID: 'iso.3.6.1.2.1.2.2.1.1.3' value: '3'
+ Located input field 'ifIndex' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.2.2.1.1'
+ Found item [ifIndex='1'] index: 1 [from value]
+ Found item [ifIndex='2'] index: 2 [from value]
+ Found item [ifIndex='3'] index: 3 [from value]
+ Located input field 'ifOperStatus' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.2.2.1.8'
+ Found item [ifOperStatus='Up'] index: 1 [from value]
+ Found item [ifOperStatus='Up'] index: 2 [from value]
+ Found item [ifOperStatus='Up'] index: 3 [from value]
+ Located input field 'ifDescr' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.2.2.1.2'
+ Found item [ifDescr='lo'] index: 1 [from value]
+ Found item [ifDescr='br-lan'] index: 2 [from value]
+ Found item [ifDescr='eth1'] index: 3 [from value]
+ Located input field 'ifName' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.31.1.1.1.1'
+ Located input field 'ifAlias' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.31.1.1.1.18'
+ Located input field 'ifType' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.2.2.1.3'
+ Located input field 'ifSpeed' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.2.2.1.5'
+ Located input field 'ifHighSpeed' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.31.1.1.1.15'
+ Located input field 'ifHwAddr' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.2.2.1.6'
+ Located input field 'ifIP' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.2.1.4.20.1.2'
ClearOS е CentOS базирана дистрибуция предназначена за малкия и среден бизнес. Лесна за администриране FIREWALL среда с вградена антивирусна система, впн сървър, поддръжка на няколко вида iptables скриптове (DMZ, 1-to1 nat, port forwarding,custom) и много други. Готиното е, че има вграден трафик анализатор(snort) чрез който лесно може да се следи трафика в реално време. Лесно може да се настрой сървъра да играе роля на gateway с 2 интернета и лоад балансинг между тях/ също така и бекъп.
За минус мога да кача че най-яките апликации са платени (и не са никак ефтини) Пример давам с : Active Directory Connector, Account Synchronization и Google Apps Synchronization които са по 100$ на година! 🙂
В обобщение ще пиша че инсталирах тази система на домашния ми гейт сървър преди 2 дни с идеята да я тествам, и до сега съм много доволен от нея. Чрез нея всеки може бързо и лесно да си направи собствен рутер с няколко клика (има много як уеб интерфейс)
Знам че има много подобни статии в интернет, но в моя блог няма нито една за LVM, и заради това сега ще напиша и първата такава! 🙂
Онзи ден трябваше да добавя 2 нови 500GB WD към сървъра „heaven“ и да ги вкарам в LVM „/dev/mapper/pve-data“
За целта първо добавих двата хард диска в LVM таблицата чрез:
heaven:~# pvcreate /dev/sdb
Physical volume "/dev/sdb" successfully created
heaven:~# pvcreate /dev/sdc
Physical volume "/dev/sdc" successfully created
а след това добавих двата харда в предварително създадената ни от proxmox-a група „pve“
heaven:~# vgextend pve /dev/sdb
Volume group "pve" successfully extended
heaven:~# vgextend pve /dev/sdc
Volume group "pve" successfully extended
ВАЖНО!!
Когато използваме не целият хард диск, а отделни партишъни, и по една или друга причина линукса ни не открива новите дялове, е необходимо да се пусне ръчно „partprobe“ която проверява за промени по дяловата таблица. Много е важно това!
Чрез командата vgdisplay можем да видим колко LVM групи имаме в момента
heaven:~# vgdisplay
--- Volume group ---
VG Name pve
System ID
Format lvm2
Metadata Areas 3
Metadata Sequence No 12
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 3
Max PV 0
Cur PV 3
Act PV 3
VG Size 1.49 TiB
PE Size 4.00 MiB
Total PE 390959
Alloc PE / Size 389037 / 1.48 TiB
Free PE / Size 1922 / 7.51 GiB
VG UUID wy2dkr-S89P-FnAS-CoWp-QPJb-guqv-MU2jiO
Чрез командите lvdisplay или lvscan ние можем да видим колко логически групи имаме в момента и какво е тяхното състояние.
heaven:~# lvscan
ACTIVE '/dev/pve/swap' [9.00 GiB] inherit
ACTIVE '/dev/pve/root' [96.00 GiB] inherit
ACTIVE '/dev/pve/data' [1.38 TiB] inherit
Тук вече съм добавил 2та WD в групата. За съмото добавяне на 2х500гб използвах следната команда:
lvextend -L+940G /dev/mapper/pve-data
Като по този начин добавих 940 GB към сегашните ми ~640GB.
Накрая за да влезе всичко това в сила, беше необходимо да напиша и това:
heaven:~# resize2fs /dev/mapper/pve-data
И така в крайна сметка състоянието на хард дисковете ми в момента е следното:
Моят съвет е да използваме RAID контролер и новите ни хард дискове предварително да сме ги добавили в RAID (1) примерно или (5) ако имаме повече от 2 хард диска. Така освен че ще имаме повече място, ще сме сигурни в системата си от евентуален счупен хард диск и загуба на информация.
Днес ми се случи нещо много интересно свързано с един виртуален сървър на OpenVZ. Тъй като сървъра не е настроен да се пуска сам, а наскоро рестартирах хост-а му, днес ми се наложи да го използвам и реших да го стартирам. Обаче греда.. виртуалката не се пусна и при команда : vzlist ми даде следния резултат:
CTID NPROC STATUS IP_ADDR HOSTNAME
104 3 running 192.168.0.81 testdns
Когато реших да вляза в него чрез:
vzctl enter 104
се оказа че немога, в /dev/ нямаше никакви tty*
Създадох ги чрез:
vzctl exec 104 "cd /dev; /sbin/MAKEDEV pty"
и след това видях че процесите не са се стартирали, мрежата не се е вдигнала – общо взето нищо не работеше.
heaven:~# vzctl enter 104
entered into CT 104
testdns:/# ps uax
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 10600 748 ? Ss 17:40 0:00 init boot
root 2 0.0 0.0 0 0 ? S 17:40 0:00 [kthreadd/104]
root 3 0.0 0.0 0 0 ? S 17:40 0:00 [khelper/104]
root 46 0.0 0.1 25536 688 ? Ss 17:40 0:00 vzctl: ttyp0
root 47 0.0 0.3 17812 1984 ttyp0 Ss 17:40 0:00 -bash
root 52 0.0 0.2 15260 1128 ttyp0 R+ 17:40 0:00 ps uax
Проблема го реших като видях че незнайно защо /etc/inittab е празен, така че, копирах направо inittab от друг сървър и нещата се оправиха.