Sometimes it’s needed to get hardware information on your Linux desktop or server using the command line only. Of course, you can do everything via CLI in Linux. Here just some reminders for myself how to do it.

Most of the information you can get using the following three commands:

  • lspci - list all PCI devices
  • lshw - list hardware
  • dmidecode - DMI table decoder

Using multiple keys to these CLI tools you can get everything you need.

It's not a full guide. It's just a list of commands to quickly identify what hardware do you have. I recommend executing all commands with root privileges to get more information.

1. What CPU do I have?

1.1. I think, almost everybody knows the command to get CPU information about your CPU. Here is just a friendly reminder:

# cat /proc/cpuinfo

2. How to get your GPU information?

2.1. A very short information:

# lspci | grep -i --color 'vga\|3d\|2d'

01:00.0 VGA compatible controller: ***

2.2.Need more details about your GPU?

# lspci -v -s 01:00.0

2.3. In the case of Nvidia GPUs you can collect some use `nvidia-smi` tool to get some information:

 

$ nvidia-smi

3. Motherboard

3.1. If you need just a model name:

#dmidecode -s baseboard-product-name

3.2. If you’re too lazy to google your motherboards specs, you can do it via the command below:

# dmidecode -t baseboard

4. RAM

Everybody knows `free` utility. It’s one of the easiest ways to see how many free or used memory you have. To determinate what actually RAM do you have you can use ‘dmidecode` or `lshw` utilites.

4.1. dmidecode:

# dmidecode --type 17

4.2. lshw:

# lshw -short -C memory

5. How to get your HDD or SSD hardware info?

For Linux, it doesn’t matter you’ve got SSD or HDD. To get their hardware information such a serial or model number, configuration and capabilities you can use the same software.

5.1. hdparm - get/set SATA/IDE device parameters

# hdparm -I /dev/sda

5.2. If you need to know more about your storage controllers and storage devices, just type the following command:

# lshw -class disk -class storage

6. Network Controllers Info (NIC)

Last but not least, there are two commands to get the information about your NICs.

6.1. lspci:

# lspci | egrep -i --color 'network|ethernet'

6.2.  lshw:

# lshw -class network

 


What is LIO target? Linux-OI Target is a Linux SCSI target introduced in a kernel v.2.6.38 and supports different fabrics modules like FibreChannel, iSCSI, iSER, etc. It works in a kernel space, so it’s faster than tgtd which is used in Cinder by default. Why do we still use tgtd instead of more faster LIO in Cinder by default? It’s only because we have to support rolling upgrades and we don’t know how to migrate from TGTd to LIO in a such way and pass Grenade successfully.

We’ve got non-voting gate-tempest-dsvm-full-lio-ubuntu-xenial job for a while. Due to some of my performance tests results it’s really faster than tgtd. So, how can you use it?

It’s pretty easy with LVM + Devstack. Everything you need is to add 'CINDER_ISCSI_HELPER=lioadm' to your localrc/local.conf.

If you have already configured Cinder+LVM it’s easy too to switch to the new target driver. I mean that you don’t have any in-use volume now but you have Cinder with LVM configured and running. Just follow these steps:

1) first of all, you have to install ‘rtslib-fb’ package using pip:

# pip install rtslib-fb

or using OS package manager:

# apt-get install python-rtslib-fb 

2) stop tgt:

# sudo service tgt stop

3) change /etc/cinder/cinder.conf to use LIO driver:

Set ‘iscsi_helper = lioadm' instead of ‘iscsi_helper = tgtadm

 

4) restart cinder and enjoy it!

 


Посмотрим какие сетевые интерфейсы бывают и какие есть на конкретном хоте. Делается это командой “ifconfig” или “ip link show”. У каждого тут будет разный список, в моем случае, команда “ip link show” выводит следующее:

 

Рассмотрим подробнее типы интерфейсов:

lo - local loopback interface, виртуальный интерфейс, который присутствует в ядре, отвечает на адрес 127.0.0.1. Весь пакеты, отправленные на него будут автоматически отправлены обратно на тот же интерфес(адрес), с какого отправили.

ethХ (eth0, eth1 и т.д.) - Ethernet LAN интерфейсы, локальная сеть.

ethX.Y - VLAN интерфейсы

wlanX - беспроводное подключение, Wi-Fi.

vmboxnetX, vmnetX - виртуальные интерфейсы VirtualBox и VmWare соответственно.

brX - bridges, бриджи, мосты. Понятно из названия, более мощный аналог hardware bridges. Соединяет два сегмента ethernet на канальном уровне (2-й уровень модели OSI)

pppX - Point to Point Protocol, PPP VPN соединения, часто подключение 3G-модемом.

tap - полностью виртуальный интеряфейс, который симулирует работу ethernet устройства и работает на каналном уровне, используется для создания мостов.

tun - также полносью виртуальный интерфейс, который работает на сетевом уровне модели OSI, используется для маршрутизации.

tr (Token Ring), sl (Serial Line Internet Protocol) и plip (Parallel Line Internet Protocol) используются гораздо реже (последние лет 5 я их не видел в “живой природе”), поэтому подробно рассказывать о них не вижу смысла.


 


Переодически сталкиваюсь с этой проблемой и приходится гуглить. Решил, записать, что бы проще искать.

Собственно, проблема выглядит так:

File "/home/e0ne/src/project/.venv/app/lib/python2.7/locale.py", line 496, in getdefaultlocale
return _parse_localename(localename)
File "/home/e0ne/src/project/.venv/app/lib/python2.7/locale.py", line 428, in _parse_localename
raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: UTF-8

Проблема заключается в том, что для текущего сеанса шелла(bash, etc) не настроена системная локаль. Ошибка позникала как под Linux(Ubuntu, RHEL-based), так под Mac OS. Фиксится просто:

Добавляем в ~/.bashrc следующие строки:

export LANG="en_US.UTF-8"
export LC_COLLATE="en_US.UTF-8"
export LC_CTYPE="en_US.UTF-8"
export LC_MESSAGES="en_US.UTF-8"
export LC_MONETARY="en_US.UTF-8"
export LC_NUMERIC="en_US.UTF-8"
export LC_TIME="en_US.UTF-8"
export LC_ALL=

Вместо "en_US" нужно(можно) подставить нужное значение. Таже, можно выполнить эти строки в шелле и это будет работать до конца сеанса.


 

Никогда не знаешь, где упадет OpenStack(c) 
Я, в процессе очередного дебагга.

Те, кто читает мой твиттер (@e0ne), должны знать, что в последнее время я работаю с OpenStack’ом, а именно занимаюсь(конечно, не один я) попытками его запуска на Red Hat Enterprise Linux (RHEL), CentOS, Scientific Linux, etc. Т.к. все это построено на базе полной и непросветной enterpise в виде RHEL, то сборка нового дистрибутива, как правило, у меня начинается со сборки именно под эту ОС. 

Вот я и хочу поделиться своими впечатлениями от сборки последней версии OpenStack’а под RHEL. Началось все с попытки запустить чуть менее чем полностью поломанную версию essex-1. Потом все продолжилось с версией essex-2. Основные моменты, которые мешали мне радоваться жизни - переделки в glance, связанные и security, которые на время поломали работоспособность EC2 API. 

Проект Glance - это услуги по отбору, регистрации и поиску виртуальных «machine images» (VMI). В рамках Glance используется RESTful API, что позволяет делать запрос метаданных VMI и выполнять поиск фактического образа (VMI). (http://openstack.ru/openstack_glance.html)

И тут я решил попробовать запустить все из последней версии исходников, с master’а...

После небольших усилий инстансы (виртуалки) начали запускаться, но были проблемы с сетью. Команда “killall dnsmasq”, подсказанная моим коллегой, решила часть проблем, а именно - выдачу IP адреса виртуальной машине. Далее в логах при загрузке неворуженым глазом были замечены такие проблемы:

 

Что означало, что запущенный инстанс не может получить данный от Metadata Server’а. Т.к. Metadata Server нормально работал в Diablo, то сразу вспомнились 2 вещи:

 

 

Далее по аналогии с Nova API был создан файл /etc/init.d/openstack-nova-api-metadata, который предназначался для запуске сервиса Metadata Server’а. Metadata Server, на первый взгляд, успешно запустился, то я попытался запустить снова инстанс, что мне привело к предыдущей ошибке. Логи Metadata Server’а немного испугали:

 

Мозг сразу начал представлять кошмары, связанные с выводом strace, linux kernel debugger’ом и так далее. Вовремя опомнившись, я полез в Google. Поиск по “exit code 134” ничего полезного не дал. А вот поиск по “iptables-restore buffer overflow” дал нужный результат в виде двух багов iptables: http://bugzilla.netfilter.org/show_bug.cgi?id=641 иhttps://bugzilla.redhat.com/show_bug.cgi?id=545600. Довольно-таки стандартное, на сколько мне известно, переполнение буфера, вызванное функцией strcpy, которую, к слову, не очень-то и рекомендуют использовать. Подробности в этом комментарии: https://bugzilla.redhat.com/show_bug.cgi?id=545600#c6

 

 

Т.к. обновление iptables в RHEL 6.1 - не самая приоритетная для меня задача, то я решил зайти с другой стороны - посмотреть что же делает OpenStack для получения такого результата.

 

 

https://github.com/openstack/nova/blob/master/bin/nova-api-metadata

Metadata Server запускается таким же способом, как и другие REST-сервисы Nova, поэтому проблему нужно было искать где-то дальше. Об этом же говорили и логи, и ошибка, связанная с iptables.

https://github.com/openstack/nova/blob/master/nova/network/linux_net.py

 

Метод metadata_accept() отрабатывает без ошибок и падает все в iptables_manager.apply().

 

Т.к. данный метод используется далеко не в одном месте

 

 

то ошибка где-то в передаваемых параметрах. В качестве параметров к iptables-restore у меня передавалось такое:

 ip-restore-full.jpg

 

 

Зная о баге в iptables и то, что падало все только при запуске Metadata Server’а, то получилось быстро найти нужную команду, которая все ломала:

iptables-restore <<EOF
*nat
:nova-api-metadata-POSTROUTING - [0:0]
-A POSTROUTING -j nova-api-metadata-POSTROUTING
COMMIT
EOF

len(‘nova-api-metadata-POSTROUTING’)==29, что вместе с символом конца строки в языке С давало нам 30 символов и при копировании их в массив из 29 символов давало нам переполнение буффера (см. ссылки на баги выше). Хорошо, проблема найдена, теперь нужно ее устранить. Для этого находим код, где у нас генерируется имя chain’а:

chain1.jpg, chain2.jpg

 

где:

binary_name = os.path.basename(inspect.stack()[-1][1])

Таким образом проблема была в имени исполняемого файла. Переименовав “/usr/bin/nova-api-metadata” в “/usr/bin/nova-metadata ” все заработало. Вопрос лишь в том, насколько долго оно будет работать с таким “фиксом”? 

Более правильное решение нужно делать исправляя код OpenStack’а и/или обновляя iptables. Также интересно как это себя ведет на других RHEL-based дистрибутивах(версия iptables) и ubuntu, но это уже проверю завтра, а пока поставил качаться нужные образы дистрибутивов...

[Update]

Баг с iptables проверен после установки чистой ОС после установки всех апдейтов с помощью команды "yum update" на следующих ОС:

  • RHEL 6.1 x86_64 - iptables v1.4.7, buffer overflow detected
  • RHEL 6.2 x86_64 - iptables v1.4.7, buffer overflow detected
  • CentOS 6.1 x86_64 - iptables v1.4.7 buffer overflow detected
  • CentOS 6.2 x86_64 - iptables v1.4.7 buffer overflow detected
  • Scientific Linux 6.1 x86_64 - iptables v1.4.7 buffer overflow detected
  • Fedora 15 x86_64 - testing in process
  • Fedora 16 x86_64 - testing in process