# zoneadm list -vc
ID NAME STATUS PATH BRAND IP
0 global running / native shared
13 ZONE-01 running /zones/ZONE-01 native shared
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool/zones/ZONE-01 14.3G 219G 14.3G /zones/ZONE-01

# zoneadm -z ZONE-01 halt
# zonecfg -z ZONE-01
zonecfg:ZONE-01> set zonename=ZONE-02
zonecfg:ZONE-02> commit
zonecfg:ZONE-02> exit
# zoneadm -z ZONE-02 move /zones/ZONE-02
# zfs rename rpool/zones/ZONE-01 rpool/zones/ZONE-02
# zoneadm -z ZONE-02 boot

Посмотреть файлик в виде 16-ричного дампа можно командой od (octal dump)
od -x filename

в 8-ричном виде
od filename

в виде символов
od -c filename

отступить от начала (-j) байт и вывести определенное кол-во данных (-N)
cat filename | od -j 1024 -N 4096 -x > outfile.txt

Понадобилось тут автоматизировать проверку web-приложения из командной строки. Суть такая — заходим на страницу, логинимся, затем идем на страницу поиска, там вводим запрос, нажимаем кнопку «найти», попадаем на страницу с результатом и ищем там определенную фразу. Все как бы просто и понятно, но ввод значений в форме поиска реализован через ajax. Чтобы понять, что отравляет броузер на сервер и что получает ставим Firefox + аддон HttpFox .
По результатам исследования был найден и подрихтован почти полностью переписан подходящий скриптик.
Особенности:
Куки и User-agent сохраняются в пределах всего сеанса.
В массиве анонимных хэшей @Urls нужно заменить ссылки url, отправляемые данные form, и expect ожидаемые данные на полученных страницах. Соответственно, по массиву идем и последовательно получаем страницы с сайта.
В expect ожидаемых данных можно использовать регулярные выражения и круглые скобки для выборки определенных данных. То что выбралось в круглых скобках ($1,$2 итд) сохраняется в переменных $e1,$e2 итд. Например получаем на странице строку «blalala uid=123456», ищем в ней uid
expect=>q(blalala uid=(\d+))
а затем подставляем ее в отправляемые данные
form=>'data=blalabla&uid=${e1}'

Для чего можно использовать этот скриптик? Для проверки связки сервер приложений-база данных, для массовой автоматической регистрации пользователей, для спама из командной строки ну итд
Дружно качаем check_web_app.pl

В Solaris 11 с созданием новой среды загрузки (Boot Environments BE) все очень просто (в более ранних версиях использовалась LiveUpgrade ). Не нужно отдельных дисков (используется zfs), есть специальная команда с понятным синтаксисом.

Итак, создать новую BE
# beadm create newBE

Посмотреть список всех BE (со всеми снэпшотами, точками монтирования, датами создания и прочим)
# beadm list -a

Посмотреть список всех BE в виде пригодном для машинного разбора
# beadm list -aH

Примонтировать BE и залить на нее пакаджи
# beadm mount newBE /a
# pkg -R /a install package-name

Активировать конкретную BE
# beadm activate newBE

Удалить BE
# beadm destroy newBE
# beadm destroy -F newBE

Список флагов BE, выводимых по команде beadm list
R – Active on reboot.
N – Active now.
NR – Active now and active on reboot.
“-” – Inactive.
“!” – Unbootable boot environments in a non-global zone are represented by an exclamation point.

Ссылки в тему

В Solaris 11 появилась новая система управления пакаджами IPS (Image Packaging System) .
Смысл такой — есть хранилище в котором находится образ системы (ну точнее пакаджей, из которых она состоит). Обновить систему можно только из хранилища.

Если нужно быстро обновить систему из iso-шки
mount -F hsfs {full_path_to}/sol-11-1111-sruN-incr-repo.iso /mnt
pkg set-publisher -G '*' -g file:///mnt/repo solaris
pkg update
umount /mnt

Если у нас несколько систем, то логично создать хранилище
Читать полностью »

После аварийного пропадания питания, сервера с ILOM (Sun/Oracle t5440, t3-1, t3-4 итд) автоматически не включаются. Чтобы это исправить, в системном контролере выставляем

set /SP/policy HOST_LAST_POWER_STATE=enabled
set /SP/policy HOST_POWER_ON_DELAY=enabled

ЗЫ Если автозагрузка не установлена, то еще добавить
set /HOST/bootmode script="setenv auto-boot? true"

В последних версиях VxVM научился обнаруживать zfs ну и соответственно теперь может «делать каку»
# vxdisk list
DEVICE TYPE DISK GROUP STATUS
c0t5000CCA0125F2E84d0s2 auto:ZFS - - ZFS
c0t5000CCA01268CBECd0s2 auto:ZFS - - ZFS

При обновлении VxVM до версии 5.1SP1RP2 появляется сообщение:
Читать полностью »

MPxIO может использовать load-balance алгоритмы
round-robin
logical-block
none
Обычно, включается опция load-balance=»round-robin» в файле /kernel/drv/scsi_vhci.conf .
На массивах Hitachi USP, USPV, VSP (и других работающих в active-active режиме) это приводит к тому, что каждая scsi-команда отрабатывает на следующем контроллере, при этом происходит задержка (rotational delay на диске, система ждет пока диск сделает оборот). Особенно заметно это на последовательных операциях ввода-вывода и на страйпированых томах vxvm или svm со страйпом 16кб.
Чтобы этого избежать,
Читать полностью »

Смотри также
Когда навалом процессоров… Часть 1
Когда навалом процессоров… Часть 2
Когда навалом процессоров… Часть 3

Сегодня учимся определять процессор, который обслуживает прерывания устройств ввода-вывода. Раньше пытались определять это анализируя вывод команды intrstat, но, оказывается, что есть команда pcitool.
С ее помощью можно посмотреть, какие процессора обрабатывают прерывания с каких устройств и переместить обработку прерываний на другой процессор.

Итак, определим, на какой шине pci расположены адаптеры qlc :
# cat /etc/path_to_inst |grep \"qlc\"
"/pci@400/pci@2/pci@0/pci@1/pci@0/pci@2/SUNW,qlc@0" 3 "qlc"
"/pci@400/pci@2/pci@0/pci@1/pci@0/pci@2/SUNW,qlc@0,1" 4 "qlc"
"/pci@400/pci@2/pci@0/pci@2/pci@0/pci@2/SUNW,qlc@0" 7 "qlc"
"/pci@400/pci@2/pci@0/pci@2/pci@0/pci@2/SUNW,qlc@0,1" 8 "qlc"
"/pci@600/pci@1/pci@0/pci@4/pci@0/pci@2/SUNW,qlc@0" 2 "qlc"
"/pci@600/pci@1/pci@0/pci@4/pci@0/pci@2/SUNW,qlc@0,1" 11 "qlc"
"/pci@500/pci@2/pci@0/pci@2/pci@0/pci@2/SUNW,qlc@0" 5 "qlc"
"/pci@500/pci@2/pci@0/pci@2/pci@0/pci@2/SUNW,qlc@0,1" 6 "qlc"
"/pci@500/pci@1/pci@0/pci@1/pci@0/pci@2/SUNW,qlc@0" 9 "qlc"
"/pci@500/pci@1/pci@0/pci@1/pci@0/pci@2/SUNW,qlc@0,1" 10 "qlc"
"/pci@700/pci@2/pci@0/pci@3/pci@0/pci@2/SUNW,qlc@0" 0 "qlc"
"/pci@700/pci@2/pci@0/pci@3/pci@0/pci@2/SUNW,qlc@0,1" 1 "qlc"

Смотрим, какой процессор обрабатывает прерывания устройств на шине /pci@600
# pcitool /pci@600 -i
ino 6 mapped to cpu aa
Device: /pci@600/pci@1/pci@0/pci@4
Driver: pcieb, instance 42
ino 7 mapped to cpu 87
Device: /pci@600/pci@1/pci@0/pci@4/pci@0/pci@2/SUNW,qlc@0
Driver: qlc, instance 2
ino 8 mapped to cpu 86
Device: /pci@600/pci@1/pci@0/pci@4/pci@0/pci@2/SUNW,qlc@0
Driver: qlc, instance 2
ino 9 mapped to cpu 85
Device: /pci@600/pci@1/pci@0/pci@4/pci@0/pci@2/SUNW,qlc@0,1
Driver: qlc, instance 11
ino a mapped to cpu 84
Device: /pci@600/pci@1/pci@0/pci@4/pci@0/pci@2/SUNW,qlc@0,1
Driver: qlc, instance 11
...

номер прерывания (ino) и номер процессора (cpu) в шеснадцатеричном виде.

Перенесем прерывание ino 7 с процессора 87 на процессор ff
# pcitool /pci@600 -i ino=7 -w cpu=ff
Interrupts on ino 7 reassigned: Old cpu:87, New cpu:ff

Ну и далее — переносим все прерывания устройств ввода-вывода на один или несколько выделенных процессоров и объединяем их в процессорный сэт ( psrset ).

С недавнего времени в horcm конфигах (файлах, описывающих репликацию ShadowImage, COW или TruCopy) теперь очень просто описать Command device:

#dev_name dev_name dev_name
\\.\CMD-99999:/dev/rdsk/

Где 99999 — серийный номер вашего массива.
В более ранних версиях требовалось указывать конкретные LUN-ы, на которых располагались Command devices, что вызывало проблемы при переезде путей в SAN или, например, замене HBA. Теперь, при замене HBA, изменении номера контроллера после перезагрузки или проведении динамической реконфигурации итд — репликация продолжает работать.