Rozpakowanie plików .scexe ze stron HP

Chcąc rozpakować plik .scexe ze stron HP, który zawiera na przykład firmware do Virtual Connectów, należy wykonać ten plik z parametrem, który określa ścieżkę.

chmod u+x CP026095.scexe;
./CP026095.scexe --unpack=/home/vcfw/;

Jako wynik polecenia otrzymamy:

CP026095.xml
Entry.bsh
HpsumCli
PackageDesc.xml
cp_data.xml
vcfwall441.bin

Zablokowane porty w Virtual Connect

->show port-protect
Port Protection Features
=======================
Protection    State
Capability
=======================
networkLoop   Enabled
pauseFlood    Enabled

Ports in Network-Loop or Pause-Flood Detected Error Condition
==============================================================
Server   Port  Interconnect Port  Protect Type  Profile
==============================================================
enc0:11  1     enc0:1:d3         pauseFlood    -- --
enc0:11  1     enc0:1:d3:v1      pauseFlood    PRD-1G-VM-03
enc0:11  1     enc0:1:d3:v2      pauseFlood    PRD-1G-VM-03
enc0:11  2     enc0:2:d3         pauseFlood    -- --
enc0:11  2     enc0:2:d3:v1      pauseFlood    PRD-1G-VM-03
enc0:11  2     enc0:2:d3:v2      pauseFlood    PRD-1G-VM-03

Usuniąć blokady można poleceniem

reset port-protect

Wyświetlanie połączeń VirtualConnect wraz z ich filtrowaniem używając CLI

Wyświetlić pełną listę uplink portów w module virtual connect można z użyciem polecenia

show uplinkport

Jednak przy analizie problemów lub chcąc wyświetlić dany typ połączenia, możemy chcieć odfiltrować część danych. Można filtrować

po wszystkich polach będących nazwami kolumn, czyli standardowo:

===========================================
ID  Enclosure  Status  Type  Speed  Used By
===========================================

A robi się to banalnie prosto

show uplinkport "Used By"="SiecTestowa1"

Filtry można też łączyć ze sobą, w rozumieniu koniunkcji, czyli coraz bardziej zawężając obraz

show uplinkport "ID"="enc0:1" "Used By"="Stacking"

 

Konto SFTP z chrootem z użyciem OpenSSH-Server na CentOS/RHEL6

Konta SFTP-only możemy chcieć użyć, gdy mamy zainstalowany na serwerze SSH (prawie zawsze) i udostępniamy dane  innemu systemowi, który loguje się i pobiera je (i ewentualnie usuwa), a nie chcemy instalować dodatkowej aplikacji jak FTPd czy HTTPd.

Zakładamy, że logowanie odbywa się automatycznie z użyciem klucza i bez hasła. Nazwa użytkownika na serwerze zdalnym to: copy z UID 2000, a grupa to sftponly z GID 2000. Serwer z SFTP to 10.7.18.2, a klient, z którego będziemy się logować to 10.7.18.1

Na pierwszy ogień musimy skongfigurować demona SSH, aby posiadał następujące wpisy:

Subsystem       sftp    internal-sftp
AuthorizedKeysFile      .ssh/authorized_keys
AllowUsers copy@10.7.18.1
Match user copy
        ChrootDirectory %h
        ForceCommand internal-sftp
        AllowTCPForwarding no
        X11Forwarding no

Oraz żeby nie posiadał takiego wpisu lub podobnego

#Subsystem      sftp    /usr/libexec/openssh/sftp-server

Następnym krokiem jest utworzenie katalogu, gdzie chcemy mieć katalogi w chroot, ja utworze katalog chroot w głównym drzewie

mkdir /chroot

Po utworzeniu katalogu a przed utworzeniem użytkownika warto utworzyć osobną grupę dla użytkownika

groupadd -g 2000 sftponly

Teraz naszym zadaniem jest utworzenie użytkownika z shellem ustawionym na /bin/false i z katalogiem domowym w wybranym miejscu.

adduser -u 2000 -g 2000 -s /bin/false -d /chroot/copy copy

Konto zostało utworzone z następującymi prawami dostępu

ls -ald /chroot/copy/
drwx------. 2 copy sftponly 4096 Mar  3 12:32 /chroot/copy/

Muszą one zostać zedytowane tak, aby właścicielem katalogu domowego konta chrootowanego był root i trzeba trochę poluzować dostępy

chown root /chroot/copy
chmod 755 /chroot/copy

Jeszcze musimy stworzyć katalog na klucze, nadać mu odpowiednie uprawnienia i wkopiować klucze publiczne, które będą mogły logować się do systemu, żeby skopiować jakieś dane za pomocą sftp

mkdir /chroot/copy/.ssh
chown root:root /chroot/copy/.ssh

Teraz czas na wkopiowanie klucza publicznego i ustawienie mu odpowiednich uprawnień

echo 'AAAA...== user@maszyna' > /chroot/copy/.ssh/authorized_keys
chown root:root /chroot/copy/.ssh/authorized_keys
chmod 644 /chroot/copy/.ssh/authorized_keys

Po tych operacjach możemy zrestartować SSHD

service sshd restart

Jeżeli wykorzystujemy selinux w trybie enforcing, to musimy jeszcze skonfigurować dla plików i katalogów odpowiednie konteksty z użyciem aplikacji semanage dostępnej w pakiecie

policycoreutils-python

Same ustawienia kontekstów

semanage fcontext -a -t home_root_t "/chroot(/.*)?"
semanage fcontext -a -t user_home_t "/chroot/copy(/.*)?"
semanage fcontext -a -t ssh_home_t "/chroot/copy/.ssh(/.*)?"
restorecon -FFrv /chroot

Po wykonaniu powyższych operacji konto copy powinno umożliwiać łączenie się do niego ze wskazanego klienta za pomocą komendy

sftp -o "IdentityFile=/sciezka/do/klucza/prywatnego" copy@10.7.18.2

Po zalogowaniu powinniśmy zobaczyć następujące okno

Connecting to 10.7.18.2...
sftp>

Jeżeli tak nie jest i system odrzuca połączenie lub prosi o hasło warto rozpocząć rozwiązywanie problemu od włączenia SSHD na serwerze w trybie debug poprzez dodanie do /etc/ssh/sshd_config wpisu

LogLevel DEBUG

i zrestartowanie usługi

service sshd restart

A po stronie klienta użyć sftp z opcją -v lub -vv

sftp -v -o "IdentityFile=/sciezka/do/klucza/prywatnego" copy@10.7.18.2
sftp -vv -o "IdentityFile=/sciezka/do/klucza/prywatnego" copy@10.7.18.2

Po stronie serwera logi czytać można wykorzystując taila

tail -fn0 /var/log/secure

Zmiana portu administracyjnego w GlassFish v4

Standardowym portem administracyjnym w GlassFishu jest tcp/4848. Z różnych powodów może zajsć potrzeba jego zmiany.
Jest to bardzo proste, gdyż z pomocą przychodzi aplikacja do zarządzania GlassFishem: asadmin. W przykładzie zmienię port 4848 na 4949.

glassfish4/bin/asadmin set configs.config.server-config.network-config.network-listeners.network-listener.admin-listener.port=4949
glassfish4/bin/asadmin stop-domain
#killall java # tylko jeżeli stop-domain nie wykona się poprawnie lub nie będzie chciała wystartować instancja
glassfish4/bin/asadmin stop-domain

Instalacja MIB SNMP w systemie CentOS/RHEL 6

Zacznijmy od początku.
Co to jest MIB? Jest to skrót od Management Information Base, a sam MIB jest prostą bazą w której są zapisane informacje o obiektach, a każdy obiekt to jakaś informacja.
MIB są wykorzystywane przez SNMP, za pomocą którego można z urządzeń odczytywać i otrzymywać informacje, a także je konfigurować.

Za przykład instalacji nowego MIBa posłuży nam powernet412 umożliwiający obsługę urządzeń APC Symmetra z kartą ap9617/ap9618/ap9619.

Instalacja narzędzi SNMP i bibliotek

yum -y install net-snmp-libs net-snmp-utils

Pobranie pakietu MIB ze strony producenta i zapisanie go w odpowiedniej ścieżce

wget ftp://ftp.apc.com/apc/public/software/pnetmib/mib/412/powernet412.mib -O /usr/share/snmp/mibs/powernet412.mib.txt

Utworzenie konfiguracji MIB, lub dodanie tego pliku do istniejącej już konfiguracji

echo 'mibfile /usr/share/snmp/mibs/powernet412.mib.txt' >> /usr/share/snmp/snmp.conf

Warto przeglądnąć jakie identyfikatory obiektów istnieją w pliku, w tym jest ich dużo, nas interesuje coś, co obsługuje UPS-a:

grep 'OBJECT IDENTIFIER' /usr/share/snmp/mibs/powernet412.mib.txt

Na koniec komenda do snmpwalk, aby skorzystać z identyfikatora ups dla tej karty zarządzającej

snmpwalk -v 1 -c public 10.1.66.5 ups

Jak wyświetlić informacje SMART z dysków podłączonych do kontrolera RAID?

Dzisiaj przedstawiam to na przykładzie kontrolera LSI MegaRaid. To, czego nam potrzeba, co aplikacja MegaCli bądź MegaCli64, która służy do zarządzania kontrolerami LSI z command line.

MegaCli64 -pdlist -aALL | grep 'Device Id'
Device Id: 6
Device Id: 7

Jako wynik otrzymaliśmy identyfikatory urządzen – dysków, te numery wykorzystamy w smartcl:

smartctl -a /dev/sda -d megaraid,6
smartctl -a /dev/sda -d megaraid,7

U mnie działa.

PrzemyÅ?aw Tarnawski – Infrastructure Expert