Red Hat, Fedora, CentOS

Sziasztok!

Az a problémám, hogy a preuninstall script-je beteg az egyik csomagnak, így aztán nem tudom leszedni. Ilyenkor mi a teendő?
[root@gépem ~]# package-cleanup --dupes
Loaded plugins: presto, refresh-packagekit, rpm-warm-cache
vala-0.16.0-4.fc17.x86_64
vala-0.16.1-1.fc17.x86_64
[root@gépem ~]# yum erase vala-0.16.0-4.fc17.x86_64
Loaded plugins: langpacks, presto, refresh-packagekit, rpm-warm-cache
Resolving Dependencies
--> Running transaction check
---> Package vala.x86_64 0:0.16.0-4.fc17 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package       Arch            Version                  Repository         Size
================================================================================
Removing:
 vala          x86_64          0.16.0-4.fc17            @updates          8.2 M

Transaction Summary
================================================================================
Remove  1 Package

Installed size: 8.2 M
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Check
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Error in PREUN scriptlet in rpm package vala-0.16.0-4.fc17.x86_64
  Verifying  : vala-0.16.0-4.fc17.x86_64                                    1/1 

Failed:
  vala.x86_64 0:0.16.0-4.fc17                                                   

Complete!
[root@gépem ~]# rpm -e vala-0.16.0-4.fc17.x86_64
/usr/share/man/man1/valac-0.16.1.gz has not been configured as an alternative for valac.1.gz
error: %preun(vala-0.16.0-4.fc17.x86_64) scriptlet failed, exit status 2
error: vala-0.16.0-4.fc17.x86_64: erase failed
[root@gépem ~]# rpm -e --force vala-0.16.0-4.fc17.x86_64
rpm: only installation and upgrading may be forced

Sziasztok!

Egy DHCP szerverhez szeretnék beállítani monitorozást, munin-nel egy CentOs 6 szerveren (az a gyanú, hogy túl sok kliens van, és elfogynak a címek).
Sajnos a repo-ban lévő dhcpd3 modul nem igazán használható, viszont találtam egy "plugint" ami pont azt csinálja a mi nekem kell, de sajnos elég önfejűen van megírva.
Van egy shell script a /usr/share/munin/plugin/dhcpd-munin_ amire ugye mutatnak linkek a /etc/munin/plugins/ -böl, és ez a script hív egy perl scriptet, ami az érdemi munkát végzi.
Ez utóbbi perl script olvassa a /etc/dhcp/dhcpd.conf és a /var/lib/dhcpd/dhcp.leases fájlokat. Ha kikapcsolom a selinux-ot, akkor ez így működik is. De azt ugye nem kéne. Hol és mit kell beállítani, hogy a script tudja olvasni mindkét fájlt.
Ráadásul a selinux ki-be kapcsolgatását sem tolerálja, mert visszakapcsolva csinálni akar boot-kor egy autorelabel-t amibe aztán belefagy. Relabel nélkül viszont pont a dhcpd lett defektes. A restorecon-nal sikerült helyrehozni, de attól is lefagyott (újraindítás után jónak tűnik). A szerver Hyper-V alatt fut virtuálisan, bár ennek nem kéne számítania.

Üdv mindenkinek,

Sajnos nem vagyok CentOS expert ezért szeretnék segítséget kérni.

Dell PERC H200 Adapter monitorozását szeretném megoldani CentOS release 5.8 (Final) alatt.
Nem találtam mpt-status-t vagy ahhoz hasonló eszközt. Milyen egyéb módon lehetne lekérdezni a raid állapotát?

A válaszokat előre is köszönöm.

Hali,

szuz redhat6-ra felraktam a spacewalk 1.7-et. Azota nem erem el a rhel6 repojat.

Tortenesek:
rhn_register
yum install libaio - mukodik
yum install spacewalk-oracle - lefutott, belottem spacewalk-ot
Spacewalk-on felvettem +1 usert es (irrelevans)
yum install sssd-client - mar nem toltodott le, mert nem eri el a rhel repot
yum clean all
yum check-update
Error: Cannot retrieve repository metadata (repomd.xml) for repository: rhel-x86_64-server-6. Please verify its path and try again

Otlet?

Ez "intended", vagy valamit a telepites elkonfigural?

Elore is kossz!

ESXi alá egyszer már sikerült feltennem, de most Workstation alá a fenéért nem sikerül.
Azt tudom, hogy az lenne a trükk, hogy telepítéskor a hálózatnál az automatikus kapcsolódást be kell kapcsolni, de akkor azt az üzenetet kapom, hogy "failed to activate these network interfaces: eth0".

Ha ezt nem kapcsolom be, és a konfig fájlt próbálom átírni telepítés után, akkor sem jelenik meg az eth0.

Mit kéne csinálnom, hogy menjen? Updateltem 9-es VMware Workstation trialra, de azzal sem működik.

Egy olyan nyugom van, hogy amikor elinditanam az nginx-et, a systemctl parancs mocskos sokat varakozik, majd ezt vagja az arcomba:

[root@master sites.d]# systemctl start nginx.service
Job failed. See system journal and 'systemctl status' for details

[root@master sites.d]# systemctl status nginx
Failed to issue method call: Unit name nginx is not valid.
[root@master sites.d]# systemctl status nginx.service
nginx.service - The nginx HTTP and reverse proxy server
	  Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled)
	  Active: failed (Result: timeout) since Sat, 22 Sep 2012 00:01:51 -0400; 18s ago
	 Process: 20794 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
	 Process: 20792 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
	  CGroup: name=systemd:/system/nginx.service

Sep 22 00:00:21 master.mmm.hron.me nginx[20792]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
Sep 22 00:00:21 master.mmm.hron.me nginx[20792]: nginx: configuration file /etc/nginx/nginx.conf test is successful

Amit ebbol kulon ki szeretnek emelni, az ez:

Active: failed (Result: timeout) since Sat, 22 Sep 2012 00:01:51 -0400; 18s ago

Egyebkent a logok - es a ps fax kimenete - szerint az nginx elindul, majd lelovettetik.

Erdekesseg, hogy ha nem varom vegig a timeoutot, hanem lelovom ^C -vel a systemctl -t, akkor az nginx futva marad, es minden problema nelkul megyen.

Mi a nyu okozhatja ezt? Semmi mas szervizzel nincs bajom, konkretan egy mysql multimaster clustert raktam ossze, minden egyes nyuves szervizt problemamentesen elindit a systemctl, az egy nginx-et nem. De egyebkent ezt az asztali gepemen is csinalja.

Strace-val beleneztem, a dbus-on pollingol baromi sokat, es az a rendszerhivas timeoutol el, ha jol lattam.
A dbus acelos, dbus-monitor szerint az uzenetek jonnek-mennek, a kapcsolat olyan stabil, mint a beton.

Ja, Fedora 17, 64 bit, SELinux nelkul (fel sincs rakva a tesztgepekre, az asztalin fenn van, es se enforcingba, se permissive-be nem mukodik). Nginx a default tarolokbol rakott legujabb, systemd szintugy. Semmi hakkeles nincs benne, csak ami a fedora tarolobol jott az van felrakva.

Plz help...

Update: megvan a hiba oka. Masolt konfiggal dolgoztam, es a systemctl abbol tudja, hogy egy szerviz elindult. hogy a /run/ alatt megjelenik a hozza tartozo pid file. Az en konfigom szerint az nginx azonban a /var/run ala hozta letre a pid file-t, emiatt nem erzekelte a systemctl, hogy elindult.

Sziasztok,

CentOS 5.8 + Directory Server 8.2 (LDAP)
probalok rajonni, hogy is mukodnek a kulcsok LDAP/LDAPS authentifikacio eseten LDAP kliensre.

Ha jol ertem az LDAPS a 636-os porton kommunikal, es az LDAP a 389-en.
secure 389 esetere kell a Start TLS beallitas.
Jol ertelmezem ezt?
ldap kliensen (RHEL 5.5 + openldap) ket ldap.conf letezik ldaps://xx.xx.xx.xx PLUSZ nehany TLS parameter.

A 2. kerdesem az lenne, miert vannak itt ezek a TLS parameterek, ha csupan csak ldaps 636-on kommunikal az LDAP kliens?

Beallitasok a kliensen:

cat /etc/ldap.conf
ssl on
#ssl no
tls_cacertdir /etc/openldap/cacerts
pam_password md5
uri ldaps://xx.xx.xx.xx/ ldaps://yy.yy.yy.yy/ #<----bellitva, hogy LDAPS legyen
base dc=aa,dc=aaaa,dc=com
# Added manually
nss_base_passwd ou=People,dc=aa,dc=aaaa,dc=com?one?accessentrylevel=valamixx
nss_base_group ou=Group,dc=aa,dc=aaaa,dc=com?one
tls_checkpeer no
#tls_checkpeer yes
#tls_reqcert demand #<----ezt probaltam
tls_reqcert never

cat /etc/openldap/ldap.conf
#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE dc=example, dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666

#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
TLS_CACERTDIR /etc/openldap/cacerts
URI ldaps://xx.xx.xx.xx/
BASE dc=aa,dc=aaaa,dc=com
#TLS_REQCERT allow
#TLS_REQCERT demand
TLS_REQCERT never

Hogy a kerdesem bonyolodjon:
Az LDAP szerver (xx.xx.xx.xx) replikaja egy letezo LDAP szervernek (primary yy.yy.yy.yy) es igy secondary LDAP szerverkent mukodik.
Ax LDAP xx.xx.xx.xx szerveren generalva vannak a CA Certificate a Server-Cert kulcsok.
A Public key kopirozva a kliensre a /etc/openldap/cacerts konyvtarba.

De akar ebben a konyvtarban is volt a kulcs, vagy azon kivul,
minkdet esetben be tudtam jelentkezni a kliensre LDAP felhasznalokent.
Beallitottam ekkor: TLS_REQCERT demand (hogy mindig ellenorizze a kulcsot).
Egyetlem esetben nem mukodott az autentikacio: ha /etc/ldap.conf : 'tls_checkpeer yes' erteket hasznaltam.

Tesztelve mindket esetben:
a)public key a /etc/openldap/cacerts konyvtarban volt es
b) azon kivul

Picit sok a beallitas, azt hiszem, mar en is belebonyolodtam. :-))

Tudna nekem ebben valaki segiteni?
Koszonom,

Ardi

Telepítettem egy CentOS 6.3-at, amin alapból rsyslog van, mellé iptables tűzfalat csináltam. A tűzfalban felvettem egy LOG részt, hogy lássam miket szűr ki. Az rsyslog-ba belepakoltam egy oldal ajánlása alapján, hogy külön állományba pakolja a logokat (kern.=debug /var/log/iptables, iptables loglevel debug-on).

Ami érdekes. Alapból a logba, ráadásul semelyikbe, nem kerülnek bele a bejegyzések, viszont ha kiadok egy 'service rsyslog restart' parancsot, akkor hozzáírja az általam megadott loghoz a LOG bejegyzéseket. Tehát, mivel így kerül valami a logba, a tűzfal LOG szabály megy, az rsyslog jó, mivel odakerülnek a bejegyzések, csak valamiért nem folyamatosan írja a logba, hanem csak restartra (illetve gondolom rsyslog leállás esetén).

Valami ötlet van erre miért így teszi? Én azt szeretném, hogy folyamatosan írja, vagy legalábbis záros határidőn belül. Találtam pár megoldást más log programmal (syslog-ng), de én nem szeretnék mást feltelepíteni.

Sziasztok,

Van egy php alapú informix lekérdező script aminek böngészőből le kellene futnia.

A szitu az , hogy ha a root környezeti változóiban megadom az INFORMIXDIR és INFORMIXSERVER megfelelő értékeit akkor parancssorból jól lefut.

Namost ha ugyanezt a php scriptet böngészőből nyitom meg akkor nem tud csatlakozni.
Gondolom aza baja hogy ezek a környezeti változók nincsenek beállítva.

Hogyan tudnám ezt megoldani?

Próbálkoztam a httpd.conf-ba beírni az alábbiakat de nem segített

DefaultEnv INFORMIXDIR érték
DefaultEnv INFORMIXSERVER érték

a mod_env modul aktív

CentOS 6.2
httpd Apache/2.2.15
php 5.3.3

Valami tipp esetleg?