hi,
https://access.redhat.com/solutions/3192722
Kikerul onnan az info vhova? Pl. beszivarog vhova a centos-nel?
Kene a tartalma nekem igennagyon.
Sziasztok!
Egy ideje nethserver van a nasomon, gond nélkül működik, ám most feltettem egy ügyfelemnek, és meglepve tapasztaltam, hogy csak a default domain-al lehet felhasználónak e-mail címet létre hozni.
Guglizás után azt találtam, hogy az aliasokkal lehet megoldani. Szódával elmegy.
De mi van akkor, ha a felhasználók egy része nem a default domainnal szeretne levelet küldeni?
Adott CentOS szerver a szokásos 2 havi httpd frissítésel. Ez egy fejlesztői szerver, ahol a /var/log/httpd-t ki szoktam ajánlani megtekintésre (kapnak rá Read+Execute jogot), hogy a hibákat könnyebben ellenőrizhessék. A httpd frissítések után ezek a jogok bezáródnak és újra ki kell nyitni.
Nem vagyok lusta (de!), csak kíváncsi, hogy ezt hogy illik megcsinálni?
- symlink a könyvtárra az user home-jába (vag az sem menne a jogok miatt?)
- valami log-sync, ami átpakolja a publikus logokat?
Köszönöm a láma kérdésemre adott válaszotokat.
Üdv!
CentOS7 telepítése után (1511, 1708...stb.) az extras repo nem elérhető már jó ideje.
Bármilyen telepítést, frissítést futtatok csak az extras kikapcsolásával lehet megtenni.
Másnak is ez van?
yum update --disablerepo=extras
Sziasztok!
Va 2 UPS-em az egyik sima hidraw eszközként észlelődik, a másik hidraw és input.
Hol tudom beállítani, hogy ne legyen input?
Sep 13 15:38:48 csucsuT450S kernel: usb 2-3: new low-speed USB device number 10 using xhci_hcd
Sep 13 15:38:48 csucsuT450S kernel: usb 2-3: New USB device found, idVendor=0665, idProduct=0201
Sep 13 15:38:48 csucsuT450S kernel: usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 13 15:38:48 csucsuT450S kernel: usb 2-3: Product: INNOTech UPS-IO
Sep 13 15:38:48 csucsuT450S kernel: usb 2-3: Manufacturer: INNOTech
Sep 13 15:38:48 csucsuT450S kernel: input: INNOTech INNOTech UPS-IO as /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0/0003:0665:0201.0007/input/input28
Sep 13 15:38:48 csucsuT450S kernel: hid-generic 0003:0665:0201.0007: input,hidraw1: USB HID v1.00 Device [INNOTech INNOTech UPS-IO] on usb-0000:00:14.0-3/input0
Sep 13 15:38:48 csucsuT450S mtp-probe[3304]: checking bus 2, device 10: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-3"
Sep 13 15:38:48 csucsuT450S mtp-probe[3304]: bus: 2, device: 10 was not an MTP device
Sep 13 15:38:48 csucsuT450S /usr/libexec/gdm-x-session[1056]: (II) config/udev: Adding input device INNOTech INNOTech UPS-IO (/dev/input/event19)
Sep 13 15:38:48 csucsuT450S /usr/libexec/gdm-x-session[1056]: (II) No input driver specified, ignoring this device.
Sep 13 15:38:48 csucsuT450S /usr/libexec/gdm-x-session[1056]: (II) This device may have been added with another device file.
Sep 13 15:38:48 csucsuT450S /usr/libexec/gdm-x-session[1703]: (II) config/udev: Adding input device INNOTech INNOTech UPS-IO (/dev/input/event19)
Sep 13 15:38:48 csucsuT450S /usr/libexec/gdm-x-session[1703]: (II) No input driver specified, ignoring this device.
Sep 13 15:38:48 csucsuT450S /usr/libexec/gdm-x-session[1703]: (II) This device may have been added with another device file.
Sziasztok!
Szeretném a segítségeteket kérni!
Adott egy CentOS 5.2-es Linux szerver (tudom már nem támogatott, de egyenlőre még sajnos nem cserélhető). Éveken keresztül hibamentesen működött, azonban mostanában az SMB megosztás időnként elhajítja magát.
Néztem samba log-ot és ehhez hasonló üzeneteket dob vissza. Sajnos nem jutottam vele sokra. Valakinek valami ötlet, hogy mi lehet a baj? Esetleg találkoztatok már hasonlóval?
Előre is köszönök minden segítséget!
[2017/09/08 06:21:15, 0] lib/fault.c:326(dump_core)
dumping core in /var/log/samba/cores/smbd
[2017/09/08 06:21:15, 1] smbd/service.c:1063(make_connection_snum)
__ffff_10.10.10.3 (::ffff:10.10.10.3) connect to service HABEL initially as us
[2017/09/08 06:21:15, 0] lib/fault.c:46(fault_report)
===============================================================
[2017/09/08 06:21:15, 0] lib/fault.c:47(fault_report)
INTERNAL ERROR: Signal 11 in pid 7944 (3.4.8)
Please read the Trouble-Shooting section of the Samba3-HOWTO
[2017/09/08 06:21:15, 0] lib/fault.c:49(fault_report)
From: http://www.samba.org/samba/docs/Samba3-HOWTO.pdf
[2017/09/08 06:21:15, 0] lib/fault.c:50(fault_report)
===============================================================
Sziasztok!
Eddig Debian-t hasznaltam VM-nek ESXi ala, de most atallunk Hyper-V-re. A Hyper-V tool a CentOS/Redhat vonalat tamogatja elsosorban, ezert egy CentOS-t raktam fol a tesztkornyezetbe.
A problema az, hogy az alabbi hibat dobja folyton:
Ez egy ismert jogosultsag hiba, talaltam is ra howto-t meg egy scriptet ami meg is oldja:
Script: https://gist.github.com/gildas/4b1c5e19fa8057d90d745c1754cb46b2
Problema leirasa:
SELinux Policy Needed for Hyper-V Daemons
During the installation of Linux Integration Services 4.2.2-2 the Hyper-V daemons are installed in
different device files. The default SELinux policies accept these new device files and will operate
without needing intervention. On Red Hat Enterprise Linux, CentOS, and Oracle Linux with the
Red Hat Compatible Kernel versions 6.6, 6.7, 6.8, 7.1, and 7.2 SELinux Policy can prevent the
daemons for KVP and VSS from operating.
The following sample policy can be used to allow these daemons to operate if SELinux policies
have restricted the Hyper-V daemons:
module hyperv-daemons 1.0;
require {
type hypervkvp_t;
type device_t;
type hypervvssd_t;
class chr_file { read write open };
}
14
allow hypervkvp_t device_t:chr_file { read write open };
allow hypervvssd_t device_t:chr_file { read write open };
allow ifconfig_t device_t:chr_file { read write open };
Put this policy in hyperv-daemons.te and compile it with the following command (as root or with
sudo):
# make -f /usr/share/selinux/devel/Makefile hyperv-daemons.pp
To test the module and not have it loaded automatically on boot:
# semodule -i hyperv-daemons.pp
Then, to add the modules to the SELinux “Targeted” policy and automatically load it on future
boots:
# semodule -s targeted -i hyperv-daemons.pp
If the SELinux policy is installed at the same time as installation of Linux Integration Services
4.2.2-2, a message may be seen that the device files /dev/vmbus/hv_kvp or /dev/vmbus/hv_vss
do not exist. These device files will not be created until the system is rebooted after installation
of Linux Integration Services 4.2.2-2 and this message can be ignored.
A gond az, hogy hiaba csinalom meg (vagyis csinalja meg a script) az itt leirtakat, sajnos ugyanugy jon a hiba... (annyit modositottam a scripten, hogy a 4.2-es toolt hasznalom)
Valaki esetleg talalkozott mar ezzel a problemaval?
Tiszteletem!
Nemrég hozzáláttam tesztkörnyezetben egy lvm rendszer szoftveres raid 1-re történő átültetéséhez.
Fő segítségként a linux akadémia teljes rendszer költöztetése másik diszkre című oktatóanyagát használtam.
A tesztkörnyezet egy fedora 26 szerver. Alapjáraton 1 merevlemez, boot partíció külön, root,home,swap lvm-ben.
Beraktam a gépbe további 2 db egyforma merevlemezt, a raid tömbök kialakításához.
sda - eredeti lemez
sdb és sdc a raid munkálatokhoz
Létrehoztam parteddal a kívánt partíciókat, majd mdadm segítségével létrehoztam md0 tömböt, amibe beleraktam a 2. és 3. merevlemez első partícióját, ami a boot partíció lesz.
A jelenlegi rendszer (sda1) boot partícióját átmásoltam rsync-el md0-ra, fstab-ban uuid-t átírtam, majd ténylegesen felcsatoltam /boot-ra.
A 2. és 3. merevlemezen létrehoztam szintén 1-1 partíciót, amiket beleraktam md1 tömbbe.
Ezt követően az md1 tömböt lvmhez adtam, pvcreate, vgextend, ahogy azt szokás, majd pvmove-val át is mozgattam a jelenlegi sda2-ről mindent az md1 tömbre.
Az átmozgatást követően ki is vettem vgs-ből, majd pvs-ből is az eredeti sda2 partíciót.
mdadm generálásra került az etc/mdadm.confba.
Majd itt akadtam el, mert az initramfs update-nél hibát ír ki a terminál. Fedora révén dracut -f -v parancsot adtam ki.
El kezd lefutni a parancs és olyanokat kapok hogy nem tudja telepíteni a modulokat mert nem találhatóak bizonyos parancsok (busybox, dmraid, iscsi, systemd-bootchart, némelyiket többször is)
Majd a végén: No dracut internal kernel commandline stored in the initramfs
Creating initramfs image file '/boot/initramfs-4.8.6-300.fc25.x86_64.img' done
Grubot frissítem grub2-mkconfig -o /boot/grub2/grub.cfg paranccsal, majd grub2-install paranccsal telepítem mind a kettő raides merevlemezre.
Újraindítást követően grub van, enterezést követően percekig semmi, majd bejelentkezik a dracut sűrű hibák kírása közepette.
Nem találja a bootot, nem léteznek a /dev/fedora/root,swap partíciók, stb.
Tudna valaki segíteni nekem, hogy mi lehet a probléma?
Köszönettel,
János
Sziasztok !
Van egy 64-bites gép,de 32-bites rendszer van rajta. Van valami megoldás arra, hogy lehetne lecserélni a rendszert 64-bitre? Fedora25 32bit lenne "frissítve" Fedora25 64bitre.
Köszi, ha van ötletetek erre.
Sziasztok,
Jogi okokból nem lehet egy Linux disztribúciós lemezen magát a Linuxot és a fejlesztett szoftvert szállítani, ezért az eddigi megoldás az volt (CentOS 6), hogy a linux csomagokat az első ISO-ra tettük, a szoftver komponenseit pedig a másodikra. Alapból az oprendszer 2 lemezen jött, így csak a megfelelő csomagokat kellett átpakolni a kettes lemezre.
A CentOs 7-től azonban a rendszer egy lemezen jön és akárhogy mondom neki, hogy két lemez legyen, hiába van 2 ISO a telepítő az nem találja azokat a csomagokat amik a 2-es lemezen vannak.
Elképzelhető az, hogy a 7-es verziótól már nem lehet két lemezesre készíteni az egyedi telepítőt sem?
Amit csinálok (nagyvonalakban):
- összegyűjtöm a csomagokat és a függőségeit
- elhelyezem a Linux csomagokat az egyes lemezen
- elhelyezem a saját csomagokat a 2-es lemezen
- legyártom a package listát:
cd ${DEST_SRC_DIR1}
ls Packages/* > ${BUILD_ISO_DIR}/pkglist
cd ${DEST_SRC_DIR2}
ls Packages/* >> ${BUILD_ISO_DIR}/pkglist
-aztán mehet a repo gyártás:
createrepo -q -g ${DEST_SRC_DIR1}/repodata/*comps.xml -o ${DEST_SRC_DIR1}/ -i ${BUILD_ISO_DIR}/pkglist --split ${DEST_SRC_DIR1}/. ${DEST_SRC_DIR2}/.
Végül pedig megcsinálom az ISO-kat:
sudo mkisofs -r -R -J -T -v -no-emul-boot -boot-load-size 4 -boot-info-table -V "Scientific-7.3-x86_64" -p "COMPANY" -A "${VERSION} - ${DATE}" -b isolinux/isolinux.bin -c isolinux/boot.cat -x "lost+found" -o ${DEST_ISO_DIR}/${IS
sudo mkisofs -r -R -J -T -v -V "${VERSION}" -p "COMPANY" -A "${VERSION} - ${DATE}" -x "lost+found" -o ${DEST_ISO_DIR}/${ISONAME2} ${DEST_SRC_DIR2}
Van valakinek esetleg valami ötlete, hogy miért írja ezt a telepítő?
Error populating transaction
Üdv: redman