LINUX.ORG.RU

Сообщения Nagisa

 

popen и двойные кавычки

из сишной программы я вызываю openssl sha1 <имя файла> (как ни странно это самый быстрый вариант ибо openssl хорошо оптимизирован)

строка вызова формировалась так:

sprintf(shellcmd,"openssl sha1 '%s'",filename);

все было хорошо пока не появились файлы вида:

хрень 'янь'.инь.rar

те содержащие одинарные кавычки

из командной строки катит такая форма

openssl sha1 "хрень 'янь'.инь.rar"

тк popen использует sh -c то я проверил конструкцию:

sh -c "openssl sha1 \"хрень 'янь'.инь.rar\""

я соответственно опробовал конструкцию формирования

sprintf(shellcmd,"openssl sha1 \\\"%s\\\"",filename);

но увы Ж( получаю обрывы строки на пробелах в имени файла

прошу подсказать как же тут победить вызов ?

 ,

Nagisa
()

Не могу установить Centos7/8 Oracle linux 7/8

Есть железка, на ней давно стоял Centos6

железка самосбор GA-990XA-UD3 / 32RAM / FX-6350 ну винты по 18TB (отключать пробовал - оставил одну SSD и результат тотже)

Хочу поставить что-то более современное решил проверить Centos7 - на этапе инсталляции валится пробовал PXE boot / DVD boot - никак

при этом Centos 6 ставится без проблем и с PXE и DVD

пробовал Oracle Linux 7/8/9 все валятся

DVD https://pic.maxiol.com/?v=1668580960.3232235619.c7dvd1.jpg&dp=2

https://pic.maxiol.com/?v=1668580973.3232235619.c7dvd2.jpg&dp=2

PXE https://pic.maxiol.com/?v=1668580992.3232235619.c7pxe1.jpg&dp=2

https://pic.maxiol.com/?v=1668581004.3232235619.c7pxe2.jpg&dp=2

данную проблему получилось победить включив IOMMU в сетапе

однако, встала другая проблема - инсталятор не видит ни одного SATA диска !

 

Nagisa
()

не могу победить «error while loading shared libraries: libclntsh.so.11.1: cannot open shared object file: No such file or directory»

дано - Centos7

Суть проблемы: ошибка при запуске приложения которое использует OCILIB

error while loading shared libraries: libclntsh.so.11.1: cannot open shared object file: No such file or directory

как известно и описано много раз надо установить переменные окружения, а именно LD_LIBRARY_PATH, но вот засада - у меня все уже установлено!

ORACLE_HOME=/u02/app/oracle/product/11.2.0/client_2; export ORACLE_HOME
ORACLE_BASE=/u02/app/oracle; export ORACLE_BASE
ORACLE_TERM=xterm; export ORACLE_TERM
ORACLE_SID=obase; export ORACLE_SID

TNS_ADMIN=$ORACLE_HOME/network/admin; export TNS_ADMIN
ORACLE_DOC=$ORACLE_HOME/doc; export ORACLE_DOC
NLS_LANG=AMERICAN_AMERICA.CL8MSWIN1251; export NLS_LANG

LD_LIBRARY_PATH=/usr/local/lib:$ORACLE_HOME/bin:$ORACLE_HOME/lib; export LD_LIBRARY_PATH

и я как бы не первый раз устанавливаю(собираю) это ПО, причем оно собирается нормально (видит OCILIB).

итак, что было проверено

  1. пути проверены, Oracle client по указанному пути есть, файлы есть
  2. переменные окружения установлены
  3. при пересборке OCILIB - она явно видит Oracle Client-а через установленные переменные окружения
  4. пробовал указывать путь до Oracle HOME явно при configure
  5. проверил нет ли еще одного файла libclntsh.so или libclntsh.so.11.1
  6. симлинк libclntsh.so верно указывает на libclntsh.so.11.1
  7. пробовал разные версии OCILIB ничего не меняется - при запуске ошибка

попробовал установить переменную

LD_RUN_PATH=/usr/local/lib:/u02/app/oracle/product/11.2.0/client_2/lib;  export LD_RUN_PATH

это немного поменяло ситуацию, а именно приложение запускается и потом не может инициализировать OCI (!) те суть не меняется

проверяю

 ldd snmp2ora
        linux-vdso.so.1 =>  (0x00007ffff7981000)
        librt.so.1 => /lib64/librt.so.1 (0x00007ffbcc06a000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ffbcbe4d000)
        libocilib.so.4 => /usr/local/lib/libocilib.so.4 (0x00007ffbcbbdb000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007ffbcb8d3000)
        libm.so.6 => /lib64/libm.so.6 (0x00007ffbcb5d0000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ffbcb3ba000)
        libc.so.6 => /lib64/libc.so.6 (0x00007ffbcafec000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ffbcc28c000)
        libclntsh.so.11.1 => /u02/app/oracle/product/11.2.0/client_2/lib/libclntsh.so.11.1 (0x00007ffbc8581000)
        libnnz11.so => /u02/app/oracle/product/11.2.0/client_2/lib/libnnz11.so (0x00007ffbc81b4000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007ffbc7faf000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00007ffbc7d95000)
        libaio.so.1 => /lib64/libaio.so.1 (0x00007ffbc7b93000)

# ls /u02/app/oracle/product/11.2.0/client_2/lib/libclntsh.so.11.1
/u02/app/oracle/product/11.2.0/client_2/lib/libclntsh.so.11.1

вот реально не понимаю где тут проблема зарыта ? все же просто - всегда устанавливал LD_LIBRARY_PATH и все всегда работало без вопросов!

 ,

Nagisa
()

Centos7 + iptables + iproute2 и 4 внешних канала: проблема с доступом к локальным сервисам

Выделено из темы Проблемы с настройкой маршрутизации в Centos7 - 3 внешних канала для более точной формализации проблемы

Дано Сервер с Centos7 x86-64, куча сетевых карт.

основная функция - маршрутизатор + NAT + FW + openvpn; а также локальные сервисы - почта, bind и прочее; внешних каналов 4шт, один основной и 3 дополнительных;

в локальной сети есть сервера c сервисами доступ к которым идет через NAT;

для реализации данного функционала настроен iptables+iproute2

доступ через NAT работает без проблем и тут всё хорошо. проблема с доступом к локальным сервисам через резервные каналы

изучение документации дало понимание того, что многое скрыто - ну вот как пример: проход первого пакета транзитом (наименования цепочек буду сокращать)

man:pre  
nat:pre
man:for
fil:for
man:post
nat:post
всё по схемам

а вот второй и следующие идут уже по сокращенному пути:

man:pre  
man:for
fil:for
man:post
теперь к проблеме

отправляю запрос к локальному сервису на 4й резерв он проходит

man:pre
nat:pre 
и все - исчезает!

те он должен появится в man:input, но видимо на этапе routing declision он убивается

цель понять почему и как это исправить

подробная информация о конфигурации

табличка резерва

ip route add DDD.DDD.DDD.0      dev ens1f1 src DDD.DDD.DDD.24   table T4 >/dev/null
ip route add 192.168.0.0/24   dev enp3s0 src 192.168.0.1    table T4 >/dev/null
ip route add 127.0.0.0/8      dev lo                        table T4 >/dev/null
ip route add default via DDD.DDD.DDD.1                        table T4 >/dev/null
main
ip route add  AAA.AAA.AAA.AAA    dev ens2f0 src AAA.AAA.AAA.1   >/dev/null
ip route add BBB.BBB.BBB.BBB       dev ens2f1 src BBB.BBB.BBB.1 >/dev/null
ip route add DDD.DDD.DDD.DDD       dev ens1f1 src DDD.DDD.DDD.1    >/dev/null
ip route add CCC.CCC.CCC.CCC/29 dev ens1f0 src CCC.CCC.CCC.CCC  >/dev/null
ip route add default via  CCC.CCC.CCC.CCC metric 99 >/dev/null
из негативных факторов которые могут вмешиваться в маршрутизацию - на сервере установлен openvpn-сервер его для теста выключал, но проблема не решалась.

вопрос - как проводить дальнейшую диагностику ? те как отловить почему пакет был убит на routing declision ?

таблицы raw и security имеют политику accept аналогично и ebtables arptables не установлено

тк сейчас на 4ом канале-резерве нет ничего критичного то я могу проводить на нем любые эксперименты. что опробовал

1. DNAT на локальные интерфейсы - пофиг. пакет не доходит до man:input

2. явное указание

ip rule add to   DDD.DDD.DDD.24    fwmark 0x400 table T4 >/dev/null
ip rule add from DDD.DDD.DDD.24    fwmark 0x400 table T4 >/dev/null

тоже пофиг

Касаемо самой настройки iproute2 - опыт есть, те у меня до этого все работало на Centos4 с 2005ого, но вот сейчас что-то поменялось. прошу помочь найти где зарыта собака.

 , ,

Nagisa
()

Centos 7 - черный экран после апдейта

Дано: HP DL380G5 наливаю CentOS-7-x86_64-DVD-1611.iso все без проблем ставится, нормальный логон и графика и текст и ssh

делаю yum update и после рестарта получаю: [img]https://pic.maxiol.com/thumbs/centos7bug.png[/img]

и нет никакого приглашения логона!

самое паршивое, что и Ctrl+Alt+F2 дает черный экран с курсором при этом через ssh сервер доступен

поиск в инете дал «gdm black screen after upgrade from 7.3 to 7.4» https://access.redhat.com/discussions/3220351?tour=8 те именно моя ситуация

но интересующая статья «gdm fails to start with blank screen in Red Hat Enterprise Linux 7 » https://access.redhat.com/solutions/2197261 закрыта

описанный способ в первой статье - выбрать другое ядро при старте не помог.

соответственно вопрос - как решить эту проблему ?

переустанавливать уже пробовал, дело именно в апдейте те ставил CentOS-7-x86_64-DVD-1503-01.iso и тоже после апдейта черный экран

 ,

Nagisa
()

Проблемы с настройкой маршрутизации в Centos7 - 3 внешних канала

Маленькая предыстория: был сервак с настроенными правилами - 3 внешних канала, openvpn, локалка с серваками все было хорошно, но сервак устарел - он налит в 2005ом Centos 4

на новую железку был налит Centos7 и тут начались проблемы: а именно проблема с пробросом портов на дополнительные каналы

те есть канал основной - оптика и есть пара медных резевов внутри локальной сети есть сервера, порты которых выставляются наружу к примеру ip 10.10.10.100 - маршрутизируется на основной канал
ip 10.10.10.101 - маршрутизируется на резерв 1
ip 10.10.10.102 - маршрутизируется на резерв 2
ну и обратно - порт 80 резерва 1 идет на 10.10.10.101:80 итд

  • 1. исходящие пакеты прекрасно уходят с сервера, маршрутизируются и выходят с нужного интерфейса ответы приходят на нужный интерфейс и тут начинается мистика

    те на интерфейсе (tcpdump) пакет есть
    далее в таблице MANGLE:PREROUTING тоже есть
    далее отрабатывается правило
    -A PREROUTING -m state --state ESTABLISHED,RELATED -j ACCEPT
    но вот в NAT:PREROUTING пакетов уже нет

  • 2. обработка входящего соединения на пробрасываемый порт
    MANGLE:PREROUTING - есть
    NAT:PREROUTING - есть
    отрабатвается правило с DNAT на локальный сервер
    далее пакеты теряются те не приходят ни в MANGLE:INPUT ни в MANGLE:FORWARD
  • 3. обработка входящего соединения на порт обрабатываемый локально - тут все проходит без проблем

если по п2 можно предположить, что пакеты куда-то зароутились с концами, то пропадание пакетов по п1 вообще не понятно тк согласно документации после MANGLE:PREROUTING идет NAT:PREROUTING

соответственно вопросы

  • что поменялось в iptables и iproute2, что ранее рабочая конфигурация отказывается работать и таким странным образом?
  • куда копать - те как устранить эту проблему ?

 , ,

Nagisa
()

RHEL4U4 х86-64 на ASUS M2N32-WS rebooting problem

Собираю небольщой сервак RHEL4U4 х86-64 на ASUS M2N32-WS (CPU 6000+) и получаю проблему - немогу ребутнуть сервер те после завершения всех процессов получаю вис с последней надписью rebooting sysytem

в логе ядра вижу матюки на ACPI

с обновлением биоса проблема - самая свежая прошивка (1703) виснет при детекте Apaptec-овского RAID-контроллера соотвественно залита предидущаяя - 1601

кто-то имеет опыт решения такой проблемы ?

ps: рядом стоит RHEL4U4 х86-64 на ASUS A8V - работает как часы и никаких танцев с обновлением биоса

>>>

Nagisa
()

RSS подписка на новые темы