Host.Community | hcom.link

Всем привет.

Задача такая.

Имеется система Ubuntu 12.04 LTS, на которой необходимо создать некоторую папку, куда могут писать все, находящиеся в локальной сети. Клиенты — Windows. Очевидно, что надо делать под Самбу.

Также необходимо обеспечить удалённый доступ к этой папке по SFTP.

Реализовано так:

1. Поднят SFTP, как указано здесь: solderintheveins.co.uk/2011/03/ubuntu-sftp-only-ac…

Маленькое изменение:
Subsystem sftp internal-sftp -u 0000

Здравствуйте, етсь у меня сервер на дебиане, на нем стоит exim4, вся почта редиректится на один ящик, т.е. можно отправлять письма на ***domain.com и все они складываются в одно место. Домен хостится на godaddy, чтобы правильно шла почта, сделал такие записи:

A (Host)
@ IP

CNAME (Alias)
imap @
mail @
pop @
smtp @

MX (MailExchanger)
0 @ @

В exim-конфиге есть пункт:

Имеется сервер на FreeBSD 8.0 с Apache 2.2.23, PHP 5.4.10 и nginx 1.2.6. Соответственно, сначала стоит nginx, за ним Apache. Проблема в том, что стабильно раз в несколько дней падает Apache после ротации логов. Ротация логов выполняется с помощью logrotate с примерно таким конфигом:
"/usr/home/mysite/logs/*.log" "/var/log/*-error.log" "/var/log/*-access.log" { su root www daily rotate 7 compress ifempty missingok nomail prerotate /usr/local/www/awstats/tools/awstats_updateall.pl now -awstatsprog=/usr/local/www/awstats/cgi-bin/awstats.pl endscript postrotate /usr/bin/killall -HUP httpd endscript sharedscripts }

После ротации в старом error.log:
[Mon May 13 00:01:03 2013] [notice] SIGHUP received. Attempting to restart

В новом:
[Mon May 13 00:01:03 2013] [notice] Digest: generating secret for digest authentication… [Mon May 13 00:01:03 2013] [notice] Digest: done [Mon May 13 00:01:05 2013] [notice] Apache/2.2.23 (FreeBSD) PHP/5.4.10 configured — resuming normal operations [Mon May 13 00:01:06 2013] [notice] child pid 88614 exit signal Segmentation fault (11), possible coredump in /usr/local [Mon May 13 00:01:06 2013] [notice] child pid 88613 exit signal Segmentation fault (11), possible coredump in /usr/local [Mon May 13 00:01:06 2013] [notice] child pid 88612 exit signal Segmentation fault (11), possible coredump in /usr/local… [Mon May 13 00:02:48 2013] [notice] child pid 88818 exit signal Segmentation fault (11), possible coredump in /usr/local [Mon May 13 00:02:49 2013] [notice] child pid 88884 exit signal Segmentation fault (11), possible coredump in /usr/local [Mon May 13 00:02:49 2013] [notice] child pid 88883 exit signal Segmentation fault (11), possible coredump in /usr/local [Mon May 13 00:02:50 2013] [notice] caught SIGTERM, shutting down

В /usr/local/ создается файл httpd.core весом около 16 мегабайт.

Если после этого просто запустить Apache — он начинает дико жрать оперативку и проц. Если перезагрузить весь сервер — все работает нормально.

Как это можно исправить? Куда вообще копать?

Здравствуйте, коллеги и товарищи.

Имеем веб-сервер на CentOS 6.3 для хостинга ряда сайтов на Drupal (в основном, седьмой версии), куда накатан традиционный LAMP + nginx в роли обратного прокси. В качестве прекомпилера для PHP использовался APC. На сервере порядка 100 живых сайтов, высокой нагрузки — нет.

Большинство сайтов на веб-сервере появилось недавно, до этого было 5-6 сайтов и всё работало хорошо (с тем же самым APC). Но когда пришло много сайтов (при этом все новички — слабые, по 100 хостов в сутки) мы начали замечать периодические тормоза: один и тот же сайт загружался то нормально, то с затупом (и однозначно затуп воспроизвести не удавалось). Но когда сайты начали выстреливать нотисами типа Unable to allocate memory for pool… — виноватого нашли, им оказался APC (т.е., наверное, не он сам, а наши несовершенные дефолтные конфиги, но тем не менее).

Ситуация развивалась вот так:

Всем доброго здравия и с праздничками.

Имеется проблемка следующего характера. Раньше на сервере(колокейшн) был прикреплен 1 ip, таким вот образом в /etc/network/interfaces
auto eth0 iface eth0 inet static address A.A.A.B netmask N.N.N.N gateway A.A.A.A

где A.A.A.A определенный шлюз.
Дальше по запросу выделили второй IP. Да только этот IP уже находится не в подсети A.A.A.A а в подсети B.B.B.B

если дописать
auto eth0:1 iface eth0:1 inet static address B.B.B.C netmask N.N.N.N gateway B.B.B.B

То к серверу по IP A.A.A.B достучатся можно а вот по IP B.B.B.C в основном нет. Хотя если звезды правильно светят то иногда получается. Такое ощущение что оно пытается отправить ответ через первый шлюз хотя должно это делать через второй.

таблица роута такая получается
B.B.B.N 0.0.0.0 N.N.N.N U 0 0 0 eth0 A.A.A.B 0.0.0.0 N.N.N.N U 0 0 0 eth0 0.0.0.0 B.B.B.B 0.0.0.0 UG 0 0 0 eth0 0.0.0.0 A.A.A.A 0.0.0.0 UG 0 0 0 eth0

Гугл подсказывает что 2 шлюза не делается в /etc/network/interfaces, а нужно route писать. Пробовал писать… все становится еще хуже. Если прописать в interfaces gateway то так второй ip хоть иногда отвечает.

Может подсказать кто-то как повесить 2 IP с разных подсетей на 1 интерфейс. Заранее спасибо за любую помощь.

PS. Гуглил более 4 часов.

import fabric from fabric.api import * env.hosts = ['d1','d2','d3','e1','e2','e3','e4'] env.parallel = True env.use_ssh_config = True fabric.state.output['running'] = False @task def uname(): run('uname -a')

Результат:
iMac:Fabric-1.6.0 vizh$ fab uname [e1] out: Linux e1 2.6.32-5-686 #1 SMP Sun May 6 04:01:19 UTC 2012 i686 GNU/Linux [e1] out: [e4] out: Linux e4 2.6.32-5-686 #1 SMP Sun May 6 04:01:19 UTC 2012 i686 GNU/Linux [e4] out: [e3] out: Linux e3 2.6.32-5-686 #1 SMP Sun May 6 04:01:19 UTC 2012 i686 GNU/Linux [e3] out: [e2] out: Linux e2 2.6.32-5-686 #1 SMP Sun May 6 04:01:19 UTC 2012 i686 GNU/Linux [e2] out: [d2] out: Linux d2 2.6.32-5-686-bigmem #1 SMP Sun May 6 04:39:05 UTC 2012 i686 GNU/Linux [d2] out: [d1] out: Linux d1 2.6.32-5-686-bigmem #1 SMP Sun May 6 04:39:05 UTC 2012 i686 GNU/Linux [d1] out: [d3] out: Linux d3 2.6.32-5-686-bigmem #1 SMP Sun May 6 04:39:05 UTC 2012 i686 GNU/Linux [d3] out: Done.

Вопрос: как избежать вывода пустых строк, что бы получилось так:
iMac:Fabric-1.6.0 vizh$ fab uname [e1] out: Linux e1 2.6.32-5-686 #1 SMP Sun May 6 04:01:19 UTC 2012 i686 GNU/Linux [e4] out: Linux e4 2.6.32-5-686 #1 SMP Sun May 6 04:01:19 UTC 2012 i686 GNU/Linux [e3] out: Linux e3 2.6.32-5-686 #1 SMP Sun May 6 04:01:19 UTC 2012 i686 GNU/Linux [e2] out: Linux e2 2.6.32-5-686 #1 SMP Sun May 6 04:01:19 UTC 2012 i686 GNU/Linux [d2] out: Linux d2 2.6.32-5-686-bigmem #1 SMP Sun May 6 04:39:05 UTC 2012 i686 GNU/Linux [d1] out: Linux d1 2.6.32-5-686-bigmem #1 SMP Sun May 6 04:39:05 UTC 2012 i686 GNU/Linux [d3] out: Linux d3 2.6.32-5-686-bigmem #1 SMP Sun May 6 04:39:05 UTC 2012 i686 GNU/Linux Done.

Здравствуйте.

Имею следующий конфиг:

2 x IBM x3630, по 14 2Tb SATA-дисков в каждом, на каждом собран raid10 из 12 дисков, 2 в hot-spare.

Гигабитный линк между серверами.

DRBD поверх устройств raid10 (md-raid).

Производительность /dev/md127:

throughput ~ 900 MB/s

fio со следующим конфигом:
Конфиг fio[readtest] blocksize=4k filename=/dev/md/raid10 rw=randread direct=1 buffered=0 ioengine=libaio iodepth=16

выдает примерно такие цифры:
Вывод fioreadtest: (groupid=0, jobs=1): err= 0: pid=5009 read: io=38632KB, bw=3502.5KB/s, iops=875, runt= 11030msec slat (usec): min=4, max=135, avg=15.63, stdev= 4.91 clat (msec): min=1, max=149, avg=18.19, stdev=12.39 lat (msec): min=2, max=149, avg=18.21, stdev=12.39 bw (KB/s): min= 0, max= 3736, per=61.09%, avg=2139.33, stdev=1733.77 cpu: usr=1.16%, sys=2.03%, ctx=9085, majf=0, minf=36 IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=99.8%, 32=0.0%, >=64=0.0% submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0% issued r/w/d: total=9658/0/0, short=0/0/0 lat (msec): 2=0.01%, 4=0.38%, 10=21.22%, 20=49.09%, 50=26.52% lat (msec): 100=2.63%, 250=0.16%

875 иопсов при задержке в 18 мс. Меня устраивают такие цифры, всё хорошо.

fio на запись — аналогично.
Конфиг fio[writetest] blocksize=4k filename=/dev/md/raid10 rw=randwrite direct=1 buffered=0 ioengine=libaio iodepth=16

Вывод fiowritetest: (groupid=0, jobs=1): err= 0: pid=5023 write: io=169624KB, bw=3912.7KB/s, iops=978, runt= 43353msec slat (usec): min=2, max=20841, avg=10.85, stdev=101.29 clat (usec): min=15, max=169027, avg=16321.19, stdev=33566.14 lat (usec): min=267, max=169040, avg=16332.46, stdev=33566.13 bw (KB/s): min= 2936, max= 7334, per=100.26%, avg=3922.26, stdev=526.96 cpu: usr=1.02%, sys=1.50%, ctx=40727, majf=0, minf=18 IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0% submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0% issued r/w/d: total=0/42406/0, short=0/0/0 lat (usec): 20=0.01%, 250=0.01%, 500=33.40%, 750=9.47%, 1000=5.28% lat (msec): 2=18.85%, 4=13.12%, 10=1.09%, 20=0.87%, 50=1.70% lat (msec): 100=12.06%, 250=4.15%

978 iops при задержке до 17 мс. Тоже прекрасно.

Далее начинается самое интересное.

Создаю drbd-устройство со следующим конфигом:
resource r0 { device /dev/drbd0; disk /dev/md/raid10; meta-disk internal; on storage00 { address 192.168.254.10:7789; } on storage01 { address 192.168.254.11:7789; } net { max-buffers 8000; max-epoch-size 8000; } }

И получаю нечто, не поддающееся обработке разумом, а именно:

Throughput на чтение почти не деградирует (чего и следовало ожидать, чтение идёт с локальной ноды).

Throughput на запись фиксируется ровно на 60 МБ/с. Маловато, от гигабита я ожидал 110 МБ/с, тем более, что initial sync drbd-устройства происходил как раз на скорости 110 МБ/с.

Снова fio при StandAlone-устройстве. Чтение:
Конфиг fio[readtest] blocksize=4k filename=/dev/drbd0 rw=randread direct=1 buffered=0 ioengine=libaio iodepth=16

Вывод fioreadtest: (groupid=0, jobs=1): err= 0: pid=5214 read: io=154380KB, bw=3500.5KB/s, iops=875, runt= 44103msec slat (usec): min=5, max=417, avg=17.87, stdev= 5.28 clat (msec): min=1, max=209, avg=18.25, stdev=12.51 lat (msec): min=1, max=209, avg=18.27, stdev=12.51 bw (KB/s): min= 3048, max= 3840, per=100.16%, avg=3505.55, stdev=113.92 cpu: usr=1.02%, sys=2.17%, ctx=36213, majf=0, minf=37 IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0% submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0% issued r/w/d: total=38595/0/0, short=0/0/0 lat (msec): 2=0.01%, 4=0.47%, 10=21.24%, 20=48.90%, 50=26.46% lat (msec): 100=2.79%, 250=0.13%

Запись:
Конфиг fio[readtest] blocksize=4k filename=/dev/drbd0 rw=randread direct=1 buffered=0 ioengine=libaio iodepth=16

Вывод fiowritetest: (groupid=0, jobs=1): err= 0: pid=5229 write: io=2396.0KB, bw=109341 B/s, iops=26, runt= 22439msec slat (msec): min=8, max=67, avg=37.40, stdev= 9.43 clat (usec): min=440, max=741029, avg=553594.77, stdev=83784.27 lat (msec): min=40, max=783, avg=590.99, stdev=86.72 bw (KB/s): min= 6, max= 131, per=98.23%, avg=104.12, stdev=19.29 cpu: usr=0.30%, sys=0.11%, ctx=601, majf=0, minf=20 IO depths: 1=0.2%, 2=0.3%, 4=0.7%, 8=1.3%, 16=97.5%, 32=0.0%, >=64=0.0% submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete: 0=0.0%, 4=99.8%, 8=0.0%, 16=0.2%, 32=0.0%, 64=0.0%, >=64=0.0% issued r/w/d: total=0/599/0, short=0/0/0 lat (usec): 500=0.17% lat (msec): 50=0.17%, 100=0.17%, 250=0.83%, 500=14.36%, 750=84.31%

Чтение не деградировало или почти не деградировало. Запись деградировала во много раз (напоминаю, drbd находится в StandAlone-режиме)

Кроме того, присутствует страшная задержка на slat — больше 37 мс только на обработку io-запроса дисковым стеком.

Что я делаю не так с drbd? Это же ненормальное поведение, когда просто еще один слой (drbd over md) рубит производительность в сорок раз?

DRBD 8.3, ядро 3.5.0-27-generic, система Ubuntu 12.04 LTS. Планировщик io — cfq.

Помогите?

Есть старый сайт, который был перенесен на SimplaCMS. Изменилась структура URL и нужно сделать редирект со старых страниц на новые.

Файл хтаццес имеет такой вид: (редиректы в конце самом)

AddDefaultCharset UTF-8

ErrorDocument 404 /404

ErrorDocument 401 /password.php

RewriteEngine on

# Админка теперь по адресу /simpla

RewriteRule ^admin/?$ simpla [L]

# Каталог товаров

Проблема выглядит примерно так:
Есть сервер с рейд контроллером (perc H700m) на Ubuntu 12.04, я пытаюсь создать программный рейд 1 на двух дисках по 3тб, отделив через gdisk 2 раздела по 300гб и один на 500гб на каждом из дисков пытаюсь соответственно собрать массивы.
Первое что показалось странным, возможно это от того, что контроллер для того чтобы подклчюить одиночный диск как бы помещает его в рейд0.
mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1 mdadm: /dev/sda1 appears to be part of a raid array: level=raid0 devices=0 ctime=Thu Jan 1 03:00:00 1970 mdadm: partition table exists on /dev/sda1 but will be lost or meaningless after creating array mdadm: Note: this array has metadata at the start and may not be suitable as a boot device. If you plan to store '/boot' on this device please ensure that your boot-loader understands md/v1.x metadata, or use --metadata=0.90 mdadm: /dev/sdb1 appears to be part of a raid array: level=raid0 devices=0 ctime=Thu Jan 1 03:00:00 1970 mdadm: partition table exists on /dev/sdb1 but will be lost or meaningless after creating array mdadm: size set to 314441536K
То же самое и на остальных.
Массив создается, дальше я его отдаю через tgt по iscisi.
Добавляю в /etc/mdadm/mdadm.conf мои массивы.
ARRAY /dev/md0 UUID=fd798c1c:baf4f1a9:682aab93:740a5f7b ARRAY /dev/md1 UUID=3a45134d:334b408a:64bcef42:3c7faf9e ARRAY /dev/md2 UUID=a9e82c0e:384fb9b8:6eed8296:8c7eaab6
Всё работает до ребута, после ребута стартует один массив md2 и начинет его синхронизировать.
Если сделать после ребута mdadm -A --verbose /dev/md0 валится что-то вроде:
mdadm: no RAID superblock on /dev/sda1 mdadm: Cannot assemble mbr metadata on /dev/sda1 mdadm: no RAID superblock on /dev/sdb1 mdadm: Cannot assemble mbr metadata on /dev/sdb1

Прошу помощи сообщества. Есть линуксовый сервер на хецнере — с двумя SATA дисками, объединёнными в зеркало (RAID 1) при помощи mdadm. Вылетел один из дисков. После замены, пробую сделать ребилд массива. Ребилдятся все разделы кроме одного — новый диск упорно встаёт как SPARE. Это выглядит следующим образом:

=========
cat /proc/mdstat
Personalities: [raid1]
md0: active raid1 sda1[2] sdb1[1]
33553336 blocks super 1.0 [2/2] [UU]

md1: active raid1 sda2[2] sdb2[1]
524276 blocks super 1.0 [2/2] [UU]

md127: active raid1 sda5[2](S) sdb5[0]
2110014324 blocks super 1.0 [2/1] [U_]
=========

Ни гугление, ни танцы с бубном и ключами mdadm результата не достигли.
Господа и дамы, подскажите пожалуйста, как всё-таки сделать sda5 полноценным членом рейда?