Пробвах да пусна PHP през STRACE - тръгна без проблем, не даде Segmentation Fault и изпълни "phpinfo();" която въведох на командния ред. Мога да покажа и съобщенията на "configure" и на "make" - но са голям обем

[-v]

Аз изобщо не изпълнявам скрипт - просто пускам PHP от командния ред без никакви опции, или пък с опция -v - мисля, че не е заради Exception, а може би някаква неразбория с библиотеки. Жалкото е, че в WINDOWS поне научаваш кой DLL и на какъв адрес е възникнал AV, а тук - пълно мълчание ...

[strace]

Пробвах и без "export CGLAGS" - получава се по-голям ELF файл, обаче и той също дава Segmentation Fault. Ще пробвам с strace какво ще излезе.

Опитвам се да инсталирам PHP 5.2.8 във Fedora Core 5. Компилирам го със следните опции:

export CFLAGS="-march=pentium4 -O3 -pipe -msse2 -mfpmath=387 -mmmx -fomit-frame-pointer -prefer-non-pic"
./configure --with-apxs2=/usr/local/apache2/bin/apxs \
   --with-mysql=/usr/local/mysql \
   --with-curl --enable-sockets \
   --without-iconv --with-config-file-path=/usr/local/lib \
   --disable-pdo --disable-reflection --disable-tokenizer \
   --disable-spl --disable-ipv6 --disable-ctype --disable-filter \
   --without-sqlite --without-xmlrpc --without-pear --without-cdb \
   --enable-inline-optimization --disable-debug

В резултат MOD_PHP работи нормално с Apache 2.2.2, но PHP-CLI версията дава "Segmentation Fault". Пробвах с различни комбинации на опциите - но успях да получа работещо PHP-CLI единствено при "./configure" без никакви аргументи.
Имам още 3 Федори (4, 5 и 6) - при тях няма такъв проблем.
Нямам опит с дебъгването под Линукс - някой може ли да помогне да открия проблема ?

[Цитат]

Цитат (anakinn @ Ян. 22 2008,14:49)

Мисля, че бъркам словореда, не че съм много наясно *.info;*.!warn;local7.!*                        /var/log/local7 local7.*                                        /var/log/local7 на прав път ли съм ?

По същия начин, както за FTP-то:

Примерен код

*.info;*.!warn;local7.none                        /var/log/messages local7.*                                        /var/log/local7

@qwert:

Странно.
Аз в началото започнах с 3-та версия (не беше популярната 3.23, но не помня точния номер) - и после като обнових до 4-та, точно в секция "client" ми даде грешка. В сегашния ми файл все още си седи командата с едно "#" отпред - за спомен.
За "init-connect" не се бях сетил - но аз винаги си ползвам една и съща функция за връзка с базата, и вътре си изпълнявам "SET NAMES cp1251" или "SET NAMES utf-8" (което ми трябва за текущия проект).
Но да не се отплесвам на философски теми :-)

[Изходни данни]

Изходни данни:
Два SATA диска по 120 GB със следните дялове:
/dev/md0 - монтиран като / (sda2, sdb2)
/dev/md1 - монтиран като /boot (sda1, sdb1)
/dev/md2 - монтиран като /usr (sda6, sdb6)
/dev/md3 - монтиран като /var (sda5, sdb5)
/dev/sda7 - монтиран като /tmp
/dev/sdb7 - монтиран като /var/tmp
/dev/sda3 и /dev/sdb3 - SWAP

Задача:
/dev/md3 беше започнал да се пълни, и преди да стигне до края - реших да подменя дисковете с 500 GB. Порових се в GOOGLE, намерих 2-3 статийки - изглеждаше лесна манипулация.

Решение:
1. С помощта на fdisk (команда p) проверих точните размери на всеки от дяловете, и след това с помощта на PartitionMagic създадох абсолютно същите дялове на двата нови диска - освен sda5 (sdb5), който разширих до максимално запълване на свободното пространство. Форматирах разделите за SWAP, а другите оставих UNFORMATTED

2. Изпълних командите

Примерен код

mdadm --fail /dev/md0 --remove /dev/sdb2 mdadm --fail /dev/md1 --remove /dev/sdb1 mdadm --fail /dev/md2 --remove /dev/sdb6 mdadm --fail /dev/md3 --remove /dev/sdb5 swapoff /dev/sdb3

3. Изключих сървъра, и подмених /dev/sdb с новия 500 GB

4. Включих сървъра, и с помощта на fdisk промених типа на разделите по следния начин (команда t):

Примерен код

/sdb1 - fd (Linux RAID autodetect) /sdb2 - fd /sdb4 - 5 (Extended), защото PartitionMagic го създаде с тип 4 /sdb5 - fd /sdb6 - fd /sdb7 - 83 (Linux native)

Форматирах /sdb7 като ext3 файлова система - команда mke2fs -j /dev/sdb7, след което изпълних следните команди, като изчаквах всяка от тях да завърши синхронизирането (периодично проверявах с cat /proc/mdstat)

Примерен код

mdadm /dev/md0 --add /dev/sdb2 mdadm /dev/md1 --add /dev/sdb1 mdadm /dev/md2 --add /dev/sdb6 mdadm /dev/md3 --add /dev/sdb5

5. Закоментирах редa в /etc/fstab за монтирането на /var (това е нужно, за да мога по-късно да разширя старата файловата система до размера на новия дял)

6. Изключих сървъра, извадих /dev/sda, на негово място сложих току-що записания 500 GB диск, а вместо /dev/sdb сложих втория (все още празен) 500 GB диск

7. Включих сървъра в еднопотребителски режим. За GRUB това се прави по следния начин:

Примерен код

1. по време на началното зареждане се натиска произволен клавиш 2. в резултат се появява менюто за избор на ядро 3. със стрелките се избира желаното ядро (моето беше SMP) 4. натиска се клавиш "е", появяват се параметрите за зареждане на ядрото 5. със стрелките се отива на реда, на който е посочено ядрото         kernel /vmlinuz-2.6.11-1.1369_FC4 ro root=/dev/md0 6. натиска се отново клавиш "e", за да влезе в режим на редактиране 7. накрая на реда се добавя интервал и думата "single" (или само "s") 8. натиска се ENTER, за да излезе от режим на редактиране 9. натиска се клавиш "b", за да започне зареждане на избраното ядро

8. При стартирането се появяват грешки, че липсват директории /var/lib и /var/run, но може смело да се игнорират. По същия начин както и за предния диск с fdisk промених типа на разделите, след което форматирах /dev/sdb7

9. Последователно изпълних следните команди, като изчаквах всяка от тях да завърши синхронизирането (периодично проверявах с cat /proc/mdstat)

Примерен код

mdadm /dev/md0 --add /dev/sdb2 mdadm /dev/md1 --add /dev/sdb1 mdadm /dev/md2 --add /dev/sdb6

Нарочно не написах последната команда mdadm /dev/md3 --add /dev/sdb5, както беше препоръчано в ръководствата, които намерих в GOOGLE - защото това не даде резултат.
Правилната поредица от команди е

Примерен код

mdadm --stop /dev/md3 mdadm --create /dev/md3 --level=1 --raid-devices=2 /dev/sd[ab]5

Последната команда е най-важна в цялото това упражнение, защото без нея resize2fs няма да може да свърши нищо - RAID масивът си остава със старата големина, въпреки че се намира в нов и по-голям раздел.
Изпълнението й е доста бавно, за разлика от mdadm --add - 132 минути срещу 26 минути за HOT-ADD.

10. След като всички RAID масиви бяха синхронизирани, изпълних командата resize2fs /dev/md3
Точно заради нея по-горе закоментирах монтирането на /var в /etc/fstab. При първото й изпълнение тя поиска да пусна e2fsck -f /dev/md3 - направих го.

11. Махнах коментара за монтирането на /var от /etc/fstab, промених правата на /tmp и /var/tmp да бъдат 0777 и рестартирах

12. Всичко тръгна нормално. За всеки случай реших да настроя GRUB да може да зарежда и от /dev/sdb (ако случайно се наложи):

Примерен код

grub device (hd0) /dev/sdb root (hd1,0) setup (hd1) quit

13. Готово - df би трябвало да показва, че /var е с новата големина

[mod_security]

Ако искаш, мога да ти пратя моя конфигурационен файл за mod_security - само че аз съм все още с 1.9.4, защото 2-ра версия още не ми е по силите. Имам и 1-2 PDF с разни примерчета, но тях ги има и на сайта на MOD_SECURITY.
Изпрати едно PM с емайл.

Книжката за SAMBA - 3 мога да ти я пратя на CHM, само напиши едно PM с емайл (5,5 МБ)

[/var/log/messages]

Ако искаш някое facility да отива в друг файл, а не в /var/log/messages - не е достатъчно да го добавиш като ред в /etc/syslog.conf. Трябва също така и да го изключиш от /var/log/messages.
За какво говоря ?
Ако просто напиша така:

Примерен код

# Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none;cron.none    /var/log/messages # The authpriv file has restricted access. authpriv.*                  /var/log/secure # Log all the mail messages in one place. mail.*                     -/var/log/maillog # Log cron stuff cron.*                     -/var/log/cron # Everybody gets emergency messages *.emerg                     * # Save news errors of level crit and higher in a special file. uucp,news.crit                  /var/log/spooler # Pure FTP ftp.*                     /var/log/pureftp.log

ще получа съобщенията на PureFTP в /var/log/pureftp.log, но ще ги имам също и в /var/log/messages. За да ги махна от там, трябва да напиша следното:

Примерен код

# Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none;cron.none;ftp.none   /var/log/messages

ftp.none означава, че никакви съобщения за facility ftp няма да се записват в /var/log/messages

[Цитат]

Цитат (qwert @ Ян. 21 2008,13:59)

по скоро опитай да сложиш в секцията mysqld опцията init-connect='SET NAMES cp1251',а в секцията client опцията default-character-set=cp1251

default-character-set=cp1251 не работи в секция client - мисля, че това започва от версия 4.1, но не съм сигурен. По-добре е да се сложи в секция mysqld. Също така трябва да се провери с какъв Character-Set и каква Collation схема е създадена съответната база данни и таблиците в нея - трябва да са cp1251_general_ci

[Изходни данни]

Изходни данни:
Два SATA диска по 120 GB със следните дялове:
/dev/md0 - монтиран като / (sda2, sdb2)
/dev/md1 - монтиран като /boot (sda1, sdb1)
/dev/md2 - монтиран като /usr (sda6, sdb6)
/dev/md3 - монтиран като /var (sda5, sdb5)
/dev/sda7 - монтиран като /tmp
/dev/sdb7 - монтиран като /var/tmp
/dev/sda3 и /dev/sdb3 - SWAP

Задача:
/dev/md3 беше започнал да се пълни, и преди да стигне до края - реших да подменя дисковете с 500 GB. Порових се в GOOGLE, намерих 2-3 статийки - изглеждаше лесна манипулация.

Решение:
1. С помощта на fdisk (команда p) проверих точните размери на всеки от дяловете, и след това с помощта на PartitionMagic създадох абсолютно същите дялове на двата нови диска - освен sda5 (sdb5), който разширих до максимално запълване на свободното пространство. Форматирах разделите за SWAP, а другите оставих UNFORMATTED

2. Изпълних командите

Примерен код

mdadm --fail /dev/md0 --remove /dev/sdb2 mdadm --fail /dev/md1 --remove /dev/sdb1 mdadm --fail /dev/md2 --remove /dev/sdb6 mdadm --fail /dev/md3 --remove /dev/sdb5 swapoff /dev/sdb3

3. Изключих сървъра, и подмених /dev/sdb с новия 500 GB

4. Включих сървъра, и с помощта на fdisk промених типа на разделите по следния начин (команда t):

Примерен код

/sdb1 - fd (Linux RAID autodetect) /sdb2 - fd /sdb4 - 5 (Extended), защото PartitionMagic го създаде с тип 4 /sdb5 - fd /sdb6 - fd /sdb7 - 83 (Linux native)

Форматирах /sdb7 като ext3 файлова система - команда mke2fs -j /dev/sdb7, след което изпълних следните команди, като изчаквах всяка от тях да завърши синхронизирането (периодично проверявах с cat /proc/mdstat)

Примерен код

mdadm /dev/md0 --add /dev/sdb2 mdadm /dev/md1 --add /dev/sdb1 mdadm /dev/md2 --add /dev/sdb6 mdadm /dev/md3 --add /dev/sdb5

5. Закоментирах редa в /etc/fstab за монтирането на /var (това е нужно, за да мога по-късно да разширя старата файловата система до размера на новия дял)

6. Изключих сървъра, извадих /dev/sda, на негово място сложих току-що записания 500 GB диск, а вместо /dev/sdb сложих втория (все още празен) 500 GB диск

7. Включих сървъра в еднопотребителски режим. За GRUB това се прави по следния начин:

Примерен код

1. по време на началното зареждане се натиска произволен клавиш 2. в резултат се появява менюто за избор на ядро 3. със стрелките се избира желаното ядро (моето беше SMP) 4. натиска се клавиш "е", появяват се параметрите за зареждане на ядрото 5. със стрелките се отива на реда, на който е посочено ядрото         kernel /vmlinuz-2.6.11-1.1369_FC4 ro root=/dev/md0 6. натиска се отново клавиш "e", за да влезе в режим на редактиране 7. накрая на реда се добавя интервал и думата "single" (или само "s") 8. натиска се ENTER, за да излезе от режим на редактиране 9. натиска се клавиш "b", за да започне зареждане на избраното ядро

8. При стартирането се появяват грешки, че липсват директории /var/lib и /var/run, но може смело да се игнорират. По същия начин както и за предния диск с fdisk промених типа на разделите, след което форматирах /dev/sdb7

9. Последователно изпълних следните команди, като изчаквах всяка от тях да завърши синхронизирането (периодично проверявах с cat /proc/mdstat)

Примерен код

mdadm /dev/md0 --add /dev/sdb2 mdadm /dev/md1 --add /dev/sdb1 mdadm /dev/md2 --add /dev/sdb6

Нарочно не написах последната команда mdadm /dev/md3 --add /dev/sdb5, както беше препоръчано в ръководствата, които намерих в GOOGLE - защото това не даде резултат.
Правилната поредица от команди е

Примерен код

mdadm --stop /dev/md3 mdadm --create /dev/md3 --level=1 --raid-devices=2 /dev/sd[ab]5

Последната команда е най-важна в цялото това упражнение, защото без нея resize2fs няма да може да свърши нищо - RAID масивът си остава със старата големина, въпреки че се намира в нов и по-голям раздел.
Изпълнението й е доста бавно, за разлика от mdadm --add - 132 минути срещу 26 минути за HOT-ADD.

10. След като всички RAID масиви бяха синхронизирани, изпълних командата resize2fs /dev/md3
Точно заради нея по-горе закоментирах монтирането на /var в /etc/fstab. При първото й изпълнение тя поиска да пусна e2fsck -f /dev/md3 - направих го.

11. Махнах коментара за монтирането на /var от /etc/fstab, промених правата на /tmp и /var/tmp да бъдат 0777 и рестартирах

12. Всичко тръгна нормално. За всеки случай реших да настроя GRUB да може да зарежда и от /dev/sdb (ако случайно се наложи):

Примерен код

grub device (hd0) /dev/sdb root (hd1,0) setup (hd1) quit

13. Готово - df би трябвало да показва, че /var е с новата големина

Проблема се оправи - обнових Squirrel до 1.4.13 и Dovecot до 1.0.10, и настроих Postfix да използва Dovecot за Local Delivery Agent (LDA) - пуснах също и ManageSieve сървър.
Вече всичко е наред - има SERVER SIDE SORTING и THREADED VIEW.

[eth0 - 192.168.0.1/24eth1 - 192.168.2.1/24eth2 - 78.90.xx.yy/24]

Привет на всички.
Наскоро (сряда, 5-ти) МЕГАЛАН смениха софтуера на някои свои рутери от ЛИНУКС на BSD. Явно неговия TCP стек е по-стриктен от този на Linux, и веднага "цъфна" 1 проблемче. След половин ден ровене в Гугъл се пообразовах малко и успях да го реша. Сега споделям опита си - може на някой да му е от полза.
По подразбиране ЛИНУКС отговаря на ARP заявки относно всеки дефиниран локален IP-адрес, независимо през кой интерфейс е дошла заявката. Това води до разпространение на вътрешни адреси (обикновено 192.168 и 172.16, но важи и за всички останали) по външната мрежа.
Например, моята конфигурация беше такава:

eth0 - 192.168.0.1/24
eth1 - 192.168.2.1/24
eth2 - 78.90.xx.yy/24

И когато получаваше ARP заявки за 192.168.0.1 през ETH2, системата ми отговаряше на тях - а това не е редно, защото трябва да отговаря само ако заявката е дошла през ETH0.
Понеже съм с 2.6 ядро, това лесно се коригира в SYSCTL:

Примерен код

sysctl -w "net.ipv4.conf.all.arp_announce=2" sysctl -w "net.ipv4.conf.all.arp_ignore=2"

Вместо all може да специфицирате конкретен интерфейс (eth0/1/2...)
За повече подробности (описание на стойностите за ARP_ANNOUNCE и ARP_IGNORE) може да прочетете ТУК

IPset ме съмнява повече, подозирам че не е много скалируемо.
Предполагам, че при GeoIP са помислили, че базата данни няма да е много мъничка '>