Skip to content

By Тодор in Windows

Да, ако HTML формата съдържа само едно единствено текстово поле, то тя не може да бъде събмитната с натискане на Ентер в Internet Explorer коя-да-е-версия. Страницата просто се презарежда, без да се събмитне (каква чудесна българска дума).
Наличието на този „дефект“ във всички версии на IE подсказва, че навярно това е нарочно…

Проблема може да бъде заобиколен, като просто добавим още едно скрито INPUT поле във формата:
<!--[if IE]><input type="text" style="display: none;" /><![endif]-->

Tags: , , , , , ,

By Тодор in Cisco

Ще покажа най-важната част от конфигурацията на Cisco рутер, който може да приема dial-up vpn клиенти закачащи се с Cisco VPN Client (има и алтернатива от Shrew Soft).

crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 2
!
crypto isakmp client configuration group vpngroup
 key p4ssw0rd
 domain domain.local
 pool vpnpool
 acl 110
 netmask 255.255.255.255
!
crypto ipsec transform-set myset esp-aes esp-sha-hmac
!
crypto dynamic-map dynmap 10
 set transform-set myset
!
crypto map clientmap isakmp authorization list default
crypto map clientmap client configuration address respond
crypto map clientmap 10 ipsec-isakmp dynamic dynmap
!
interface FastEthernet1
 ip address dhcp
 ip nat outside
 crypto map clientmap
!
ip local pool vpnpool 192.168.55.100 192.168.55.200
!
ip nat inside source list 150 interface FastEthernet1 overload
access-list 110 permit ip 192.168.0.0 0.0.0.255 any
access-list 150 deny   ip 192.168.0.0 0.0.0.255 192.168.55.0 0.0.0.255
access-list 150 permit ip 192.168.0.0 0.0.0.255 any

Това което трябва да се настрои при клиента е групата vpngroup с парола p4ssw0rd.
В тази конфигурация вътрешната мрежа зад рутера е 192.168.0.0/24, а клиентите на криптирания тунел са 192.168.55.0/24. ACL 110 разрешава на вътрешната мрежа да мине през тунела, а ACL 150, който съдържа списък с какво трябва да се NAT-не, първо не позволява NAT в случай на трафик от 192.168.0.0/24 към 192.168.55.0/24 и второ разрешава NAT за всички останали дестинации.

Ако желаем да имаме още един фактор на идентификация т.е. да пита и за потребителско име и парола, освен конфигурираните вече група и парола на групата, добавяме следните няколко реда:

aaa new-model
aaa authorization network default local
crypto map clientmap client authentication list default

By Тодор in Cisco

Понякога се налага да не искаме да приемем маршрут по подразбиране в OSPF 🙂

ip prefix-list AllowedRoutes deny 0.0.0.0/0
ip prefix-list AllowedRoutes permit 0.0.0.0/0 le 32
router ospf 1
distribute-list prefix AllowedRoutes in 

Естествено, че не откривам топлата вода 🙂
Кредитите тук – https://supportforums.cisco.com/thread/2052012

Tags: , , , , , , , ,

By Тодор in Linux

В случай, че се наложи горещо включване на SATA диск, вероятно ще е необходимо на ръка да предизвикаме саниране за нови устройства:
echo "0 0 0" >/sys/class/scsi_host/host<N>/scan
Където N е номера на шината.
А може и така:
partprobe

By Тодор in Openwrt

Напоследък все по-често започнах да използвам Openwrt. Наложи се да мога да изпращам електронни писма през такава машинка. Избрах да ползвам ssmtp. Ето и пример как се случва всичко след инсталацията му.

Конфигурационният файл /etc/ssmtp/ssmtp.conf изглежда така:

root=postmaster
mailhub=smtp.gmail.com:465
authuser=accountname@gmail.com
authpass=SuperMegaQkataPar0la
rewriteDomain=gmail.com
hostname=gmail.com
FromLineOverride=YES
UseTLS=YES

Както виждате, ползвам услугите на Гугата. За малък брой писма това е ОК, но не забравяйте, че има лимит изпратени писма на ден (май беше 100). За повече, ще трябва да ползвате друг пощенски сървър.

Ето как изглежда и изпращането на писмо:
echo -e "From: Goshko <accountname@gmail.com>\nSubject: test subject\n\nMessage body" | ssmtp -vvv some@address.com

Това може лесно да се ползва в скрипт, като ще дам жокер и за нещо друго – името „Goshko“ може да бъде различно всеки път. Например „Server A Power“ или „Klimatik 02 Status“ 🙂

Примерен скрипт за кратки нотификации – само с няколко думи в темата на писмото:

#/bin/sh
while getopts n:s:a: option
do
        case "${option}"
        in
                n) NAME=${OPTARG};;
                s) SUBJ=${OPTARG};;
                a) ADDR=${OPTARG};;
        esac
done
echo -e "From: $NAME <some@address.com>\nSubject: $SUBJ\n\n`date`" | ssmtp $ADDR

Работи по следния начин:
notify.sh -n 'Comms UPS' -s 'Power Down' -a admin@address.com
Ще изпрати съобщение, което в тялото си съдържа само датата на събитието.

Tags: ,

By Тодор in Openwrt

Openwrt е нещото, за което все още не съм писал и ред, но това предстои тепърва 🙂
Наскоро ми се наложи да направя така, че USB флашка с ext4 файлова система да се монира с пускането на рутера:

Първоначалната инсталация, за да може рутера изобщо да разпознае флашката:

# opkg update
# opkg install kmod-usb-storage kmod-fs-ext4

Задължителен рестарт. Това е достатъчно, за да виждаме и монтираме с:
# mount /dev/sda1 /mnt
Приемам, че флашката има вече форматиран ext4 партишан на нея. По-лесно е това да се свържи на компютър, тъй като инструментите за openwrt са малко големки и вероятно няма да могат да се съберат в паметта на рутера, без да се наложи да триете нещо.

/etc/config/fstab трябва да изглежда горе-долу ей така:

config global automount
        option from_fstab 1
        option anon_mount 1

config mount
        option target        /mnt/
        option uuid          38bfd7ec-e32b-47c7-974d-de3aea122a1f
        option fstype        ext4
        option options       rw,sync
        option enabled       1
        option enabled_fsck  1

Като uuid на устройството получаваме от инструмента blkid:

# opkg install blkid
# blkid
/dev/mtdblock2: TYPE="squashfs"
/dev/sda1: UUID="38bfd7ec-e32b-47c7-974d-de3aea122a1f" TYPE="ext4"

При мен се наложиха още няколко операции, които не срещнах по други подобни упътвания:

# rm -f /etc/fstab
# ln -s /tmp/fstab /etc/fstab
# /etc/init.d/fstab enable
# /etc/init.d/fstab start

И рестарт за проба 🙂

Tags: , , , ,

By Тодор in Cisco

Генерирането на ключове най-често се налага при пускане на ново устройство, което си няма такива или при необходимост от ъпгрейд към по-голям ключ – от 512 към 1024 или към 2048.
На скоро от Micro$oft публикуваха ъпдейт (KB2661254), който блокира ползването на ключове с дължина 1024 бита или по-малка. Та ето и чудесен повод да си генерираме 2048 битови ключове на устройствата, които са с по-малки.

conf t
ca zeroize rsa
ca generate rsa key 2048
ca save all
write mem
reload

Отнема около 5мин на PIX 501 🙂

Tags: , , , , , , , , , , , , ,

By Тодор in Linux

Примерният сценарий е линукс рутер с повече от 1 входящ интерфейс:
eth0.123 – вход 1
eth0.321 – вход 2
eth1 – изход

# tc qdisc add dev eth1 root handle 1: htb
# tc class add dev eth1 parent 1: classid 1:1 htb rate 10000kbit
# tc filter add dev eth1 protocol all basic match meta\(rt_iif eq 1\) flowid 1:1

Интересен е само третият ред. И по специално частта match meta\(rt_iif eq 3\)
rt_iif указва, че ще сравняваме пакетите по входящ интерфейс
3 е поредният номер (индекс) на интерфейса от който идва трафика

Индексите на интерфейсите можете да видите с ip addr list
Примерен скрипт, който можете да ползвате за получаване на индекс на посочен интерфейс:

# ip addr list | grep " eth1:" | awk -F":" '{print $1}'

С така конфигурирания шейпър се ограничава скоростта само на трафика идващ от интерфейса с индекс 3.

Полезно:

# tc filter add dev eth1 basic match 'meta(help)'
# tc filter add dev eth1 basic match 'meta(list)'

Tags: , , , , , ,

By Тодор in FreeBSD, Linux, Solaris

Да изпратим писмо с прикачени файлове в bash.
Удобно и лесно това става с меил-клиента mutt:
# echo "Body" | mutt -s "Subject" -a file1 -a file2 user@domain.tld

Tags: , , , , , ,

By Тодор in FreeBSD, Linux, Solaris

Най-сигурният начин за изпращане на поща от какъвто и да е сървър е препращането на писмата към пощенски сървър, който отговаря на всички стандарти, така че кореспонденцията идваща от него да не се счита за спам и да не бъде филтрирана.
Ще дам пример как sendmail ще „релейва“ през пощенските сървъри на Гугъл. Това означава, че задължително трябва да имаме активен пощенски акаунт в gmail.com.

В /etc/mail/sendmail.mc намираме следният ред:
dnl define(`SMART_HOST', `smtp.your.provider')dnl
и го корегираме на:
define(`SMART_HOST', `smtp.gmail.com')dnl

Следва компилация на направените промени:
# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
(Необходимо е пакета sendmail-cf да бъде инсталиран)

В /etc/mail/access добавяме реда с данните за аутентикация:
AuthInfo:smtp.gmail.com "U:username@gmail.com" "P:password" "M:PLAIN"

Следва отново „компилация“ на направената промяна:
# makemap hash /etc/mail/access < /etc/mail/access

Всички домейни писмата, до които не трябва да се изпращат към smart host-а се описват в /etc/mail/local-host-names по един на ред:

loclahost
localhost.localdomain
hostmaster.kamenitza.org

Така ще избегнете всички писма генерирани от локалните демони да излизат в Интернет.

И рестартиране на sendmail:
# /etc/init.d/sendmail restart

Не забравяйте да настроите sendmail да се стартира автоматично с операционната система:
# chkconfig sendmail on

Туй то 🙂

Tags: , , , , ,

By Тодор in Мрън-мрън

И все пак личната собственост не е неприкосновена…
Ей така си заварих колата тази сутрин.


Мамка му!

By Тодор in Linux

За да сме сигурни, че няма да загубим някаква информация обикновено я архивираме, нали? Веднъж месечно, веднъж седмично, веднъж дневно? Ами ако ни е необходимо по-често архивиране, на ресурс, който постоянно се актуализира, като база данни например? Някои сървъри за бази данни (като mysql) осигуряват собствено репликиране върху отдалечен сървър.

Нещо по-добро е репликирането на цяла файлова система на блоково ниво. Всяка една промяна върху диска се репликира моментално каквато и да е тя – и то без софтуерът, който ползва тази файлова система да разбере.

Удобен начин да се направи това в линукс е чрез DRBD. Тъй като репликацията е на много ниско ниво, не можем да репликираме отделни директории или файлове – работим с цели дискове или дялове (партишъни). Тъй като не всеки разполага със свободен диск/дял, който да ползва за репликацията, ще дам пример с „изкуствен“ диск, създаден във файл върху текущата файлова система (loopback image). Т.е. правим един файл с размер 1GB, присъединяваме го като виртуален локален диск, правим му файлова система по желание и вече е в бизнеса 😉

Създаваме файл с размер 1GB (на двата сървъра между, които ще репликираме):
# dd if=/dev/zero of=/root/disk.img bs=1M count=1024

Сега да го прилепим към локално устройство /dev/loop0:
# losetup /dev/loop0 /root/disk.img

Това до тук ще работи, но докато не рестартираме машината. За тази цел правим един init-скрипт, който да върши тази работа при стартиране на операционната система:

#!/bin/bash
# lofsd:         Loopback filesystem
#
# chkconfig:    - 10 80
# description:  Creates loopback device
DRBD_SRC="/root/disk.img"
DRBD_DEVICE="/dev/loop0"
LOSETUP_CMD="/sbin/losetup"
RETVAL=0
start() {
        echo "Connecting loop devices $DRBD_DEVICE"
        $LOSETUP_CMD $DRBD_DEVICE $DRBD_SRC
        RETVAL=$?
        return $RETVAL
}
stop() {
        echo "Releasing loop devices $DRBD_DEVICE"
        $LOSETUP_CMD -d $DRBD_DEVICE
        RETVAL=$?
        return $RETVAL
}
restart() {
    stop
    sleep 1
    start
}
case "$1" in
    start)
        start
    ;;
    stop)
        stop
    ;;
    restart)
        restart
    ;;
        *)
    echo "Usage: $0 {start|stop|restart}"
    exit 1
esac
exit $?
exit $RETVAL

Записваме го под името /etc/init.d/lofsd. След това го правим изпълним:
# chkmod +x /etc/init.d/lofsd

Регистрираме скрипта като системна услуга и го активираме:

# chkconfig --add lofsd
# chkconfig lofsd on

До тук вече имаме един локален виртуален диск на /dev/loop0 и нищо повече. Сега е ред да инсталираме и самото DRBD:
# yum -y install drbd kmod-drbd

Конфигурационният му файл /etc/drbd.conf, е съвсем празен веднага след инсталацията, но има много добре коментиран примерен такъв в /usr/share/doc/drbd. Набързо спретвам следната конфигурация, която изглежда сложна само на пръв поглед (еднаква е и за двата сървъра):

global { usage-count no; }
resource repdata {
    protocol C;
    startup { wfc-timeout 0; degr-wfc-timeout     120; }
    disk { on-io-error detach; }
    net {  cram-hmac-alg "sha1"; shared-secret "ie74t6384"; }
    syncer { rate 10M; }
    on n1.kamenitza.org {
        device /dev/drbd0;
        disk /dev/loop0;
        address 10.0.0.1:7788;
        meta-disk internal;
    }
    on n2.kamenitza.org {
        device /dev/drbd0;
        disk /dev/loop0;
        address 10.0.0.2:7788;
        meta-disk internal;
    }
}

Няма да коментирам кой ред какво върши – вероятно само очевидните неща като, пътища до устройства и адреси ще трябва да редактирате – останалото е почти универсално. Все пак, ако се интересувате – разгледайте примерният drbd.conf, който е изключително добре коментиран. Когато приключите с конфигурацията – копирайте я и на вторият сървър.

Време е да инициализираме мета-данните (и на двата сървъра):

# drbdadm create-md repdata
v08 Magic number not found
v07 Magic number not found
v07 Magic number not found
v08 Magic number not found
Writing meta data...
initialising activity log
NOT initialized bitmap
New drbd meta data block sucessfully created.

Сигурно веднага ще опитате да стартирате услугата, но може да ударите стена:

# /etc/init.d/drbd start
Restarting all DRBD resourcesNo response from the DRBD driver! Is the module loaded?
Command '/sbin/drbdsetup /dev/drbd0 down' terminated with exit code 20
command exited with code 20
ERROR: Module drbd does not exist in /proc/modules

Ами това помага :):
# modprobe drbd

След като сте стартирали сървиса (и на двата сървъра), можете да наблюдавате статуса на дисковия ресурс ето така:

# cat /proc/drbd
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-x8664-build, 2008-10-03            11:30:17
 0: cs:Connected st:Secondary/Secondary ds:Inconsistent/Inconsistent C r---
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 oos:1048508

Ако някой забелязва – и двете копия са вторични (secondary). Такива ще си останат, докато ние не изберем, кой да е водещият сървър и в неговия шел пуснем ето това:
# drbdadm -- --overwrite-data-of-peer primary repdata

Я да видим статуса:

# cat /proc/drbd
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-x8664-build, 2008-10-03            11:30:17
 0: cs:SyncSource st:Primary/Secondary ds:UpToDate/Inconsistent C r---
    ns:16932 nr:0 dw:0 dr:19168 al:0 bm:1 lo:0 pe:4 ua:70 ap:0 oos:1031676
        [>....................] sync'ed:  2.0% (1031676/1048508)K
        finish: 0:00:59 speed: 16,832 (16,832) K/sec

Сякаш работи и вече тече репликация, а? 🙂
Остана да направим една файлова система на DRBD диска:
# mkfs -t ext3 /dev/drbd0

И да го монтираме (създайте директорията /mnt/disk и на двата сървъра, но го монтирайте само на първия):
mount /dev/drbd0 /mnt/disk

След приключване на репликацията, нещата изглеждат горе долу така:

# cat /proc/drbd
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-x8664-build, 2008-10-03 11:30:17
 0: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---
    ns:56 nr:1412 dw:1468 dr:21 al:2 bm:3 lo:0 pe:0 ua:0 ap:0 oos:0

Ами можем вече да го изпробваме. Копирайте някакви файлове на диска преди това.
Ръчно размонтираме и правим вторичен първият сървър (n1):
# umount /mnt/disk ; drbdadm secondary repdata

Сега отиваме на втория (n2) и правим следното:
# drbdadm primary repdata ; mount /dev/drbd0 /mnt/disk

И трябва да виждаме същите файлове, които преди това копирахме от сървър n1.

За да си улесним живота в бъдеще можем да редактираме и /etc/fstab, който до момента изглежда горе-долу така:

LABEL=/                 /                       ext3    defaults        1 1
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
LABEL=SWAP-sda2         swap                    swap    defaults        0 0

Добавяме следният ред най-долу:

/dev/drbd0              /mnt/disk               ext3    noauto          0 0

Така, че файлът да придобие този вид:

LABEL=/                 /                       ext3    defaults        1 1
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
LABEL=SWAP-sda2         swap                    swap    defaults        0 0
/dev/drbd0              /mnt/disk               ext3    noauto          0 0

Цялата тази глезотия става изключително полезна, когато се съвмести с Heartbeat. Тогава в /etc/ha.d/haresources добавяме следният ред:

n1.kamenitza.org   drbddisk::repdata Filesystem::/dev/drbd0::/mnt/disk::ext3::rw

Ще се радвам, ако някой успее да приложи това някъде и сподели коментари 😉

Tags: , , , , ,

By Тодор in Linux

Неизвестна грешка…
Никаква представа нямам какво я поражда – появява се когато си поиска при задаване на правила в iptables.
Ядрото е:
Linux xxx 2.6.18-274.7.1.el5 #1 SMP Thu Oct 20 16:21:01 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
Реших проблема като разреших centos-plus хранилището на yum:
/etc/yum.repos.d/CentOS-Base.repo:

[centosplus]
name=CentOS-$releasever - Plus
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

И актуализирах ядрото с
yum upgrade

Към явно по-прилична компилация:
Linux xxx 2.6.18-274.7.1.el5.centos.plus #1 SMP Thu Oct 20 19:28:06 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux

Проблема повече не се е появявал 🙂

Tags: , , ,

By Тодор in FreeBSD, Linux, Solaris

Имам предвид трансферирането на RRD базите данни от 64 битова платформа на 32 битова. Да, това не става просто с копиране на самите RRD файлове – те са различни в зависимост от това на каква платформа са създадени за по-добра оптимизация и бързодействие.

При просто копиране на файловете ще получаваме грешки от сорта на:
rrd_graph() ERROR: This RRD was created on another architecture

Най-доброто, което може да се направи е базите данни да се експортират в XML формат, след това тези XML файлове да се копират и да се конвертират обратно в RRD.

Експортиране в XML:
for i in `find -name "*.rrd"`; do rrdtool dump $i > $i.xml; done

Конвертиране обратно в RRD:
for i in `find -name "*.xml"`; do rrdtool restore $i `echo $i | sed s/.xml//g`; done

Енжой 😉

Tags: , , , ,

By Тодор in FreeBSD, Linux

Целта е да се изконфигурира прокси, което да допуска всеки „регистриран“ клиент – такъв с име и парола.

Squid поддържа много методи за уторизация на потребители, но най-лесен ми се струва NCSA. Ще дам пример със squid на CentOS 5.6 64bit.

Създаваме файла с потребителските имена и пароли:
# htpasswd -c /etc/squid/passwd user
Само ще попита за парола.

Модула ncsa_auth обикновено е инсталиран заедно със squid. Можете да проверите ето така:
# rpm -ql squid | grep ncsa_auth

Следните няколко реда се добавят в squid.conf:

auth_param basic program /usr/lib64/squid/ncsa_auth /etc/squid/passwd
auth_param basic children 5
auth_param basic realm Please authenticate!
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

Без ACL запис няма да минем естествено 🙂

acl ncsa_users proxy_auth REQUIRED
http_access allow ncsa_users

Необходим е рестарт на squid.