-
Fototrend
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
válasz
urandom0
#33955
üzenetére
Az Arch elvileg nem volt közvetlen érintett, mert a supply chain attack fejlesztő berakta feltételnek, hogy csak akkor kerüljön be a kártékony patch, ha deb, vagy rpm build megy. Szerencsére viszonylag hamar észrevették, szóval csak a Debian Sid, fedora rawhide és társai voltak érintettek.
De kemény story, igen. Sajnálom, mert az lzma a kedvenc tömörítési eljárásom. Így biztosan meg fog inogni az emberek hite a szoftver amúgy elképesztő képességeiben.
-
válasz
inf3rno
#32435
üzenetére
Hogyne, van jó pár kiegészítő: [link] Én Fedora alatt is Windowsos Chromeot "hazudok" vele, de leginkább azért, mert csomó webapp el sem indul enélkül böngészőben, pedig menne rendesen.
Ugyanakkor ezernyi más módja van a fingerprintingnek, amin esetleg a user.js tud segíteni: [link] Ennek én sok ideig a relaxed verzióját használtam, de viszonylag sok kényelmi áldozattal jár a használata. Pl a böngészőm nem mentett előzményeket stb.
-
-
#32108
Mr Dini
addikt
MasterMark
#32107
válasz
MasterMark
#32107
üzenetére
Kósza ötlet: "screen -dm ..." és akkor elvileg nem fog csatlakozni interaktívan. De ez mire kell pontosan? Valami keepalive? Bár én is preferálom a screent, a minicom is lehet alternatíva, ha máshogy nem megy.
Egyébként a háttérbe küldés bashban tudtommal &. A ; több parancs egy sorba írásánál használatos, a || után írt parancs meg akkor fut le, ha az előtte álló parancs hibával lépett ki. De feltételezem, hogy az & furán működik a screen esetében.
-
Világos. Linux topikba írtál, így azt feltételeztem, hogy Linuxot szeretnél bootolni virtual diskről, amire egyébként a Ventoy a linkelt pluginnel képes a pluginnel (mezei virtualbox diskre gondolok). Amúgy valóban inkább arra találták ki, hogy USB telepítő isokat lehessen (sokat) egy pendrivera rakni, majd ezek közül a ventoy bármelyiket bebootolja, nem kell mindig kiírni az éppen aktuálisan telepítendő rendszert bootolható pennek. Nyilván úgy gondoltam az elképzelést egyébként, hogy nem usb stickre kerül a másodlagos rendszer, hanem PXE-n töltöd be a Ventoy-t, majd az indítja a virtual diskes rendszert.
Az adott pluginnak van egyébként windows verziója is, de ahogy olvasom, csak win7+t képes betölteni, a winxp elvileg még nem rendelkezik a megfelelő virtual disk driverrel.
Bare metal xp telepítés nem játszik semmiképp?
-
A Ventoy, ezzel a pluginnel nem játszik?
-
Üdv!
Nemrég tértem át Arch Linuxra a laptopomon is, eddig Fedorát használtam. Kb a teljesen szűz telepítés óta tapasztalom, hogy néha a leállítás nagyon sok időt vesz ígénybe. Látszólag a KDE Plasma azonnal kilövődik és megáll a kijelző egy ^@ áradatot mutató kijelzőn, illetve egy villogó kurzoron. Mást nem ír ki, de a ^@ száma látszólag véletlenszerű. Van, hogy percekig áll ebben az állapotban és csak utána áll le. tty-t a megszokott ctrl+alt+fX kombinációkkal már nem tudok ilyen állapotban váltani, hogy megnézzem, mi is történik.
Ami érdekes, hogy van, hogy kb 20 program van nyitva és így állítom le a gépet, ami azonnal le is áll, van, hogy a bekapcsolt állapot kb 5 percig tart, megnézem a leveleimet és kikapcsolom a gépet és 5 percig áll le...
I/O-ra gyanakodtam, de egy friss NVMe SSD van a laposban, nehezen hinném el, hogy ez a bottleneck. Esetleg az xfs fájlrendszer lehet a gond? A rootfs és a /home is XFS.
Melyik logot érdemes nézegetni, hogy mi történhet ilyenkor pontosan? journalctl-t a jelenség utáni első boot során?
Illetve a másik gondom, hogy a laptopban csak USB 3.0 portok vannak, ezt látszólag fel is ismeri a rendszer, illetve nyilván maguk a fizikai portok is kékre vannak festve, jelezve, hogy tényleg 3-as USB-ről van szó. Van egy USB-s ethernet adapterem, amit gigabites hálóra kötve a max letöltés 340 Mbit/s, míg a feltöltés 285 Mbit/s mindig. Telefonról/pendriveról/külső HDD-ről másolva is olyan 30-31 MB/s-sel tudok olvasni és 27-28 MB/s-sel írni. Gondolnám, hogy ez hardver limit, de nem tűnik annak. Windows-szal ugyanezzel a setuppal simán jön a gigabites net az adapterrel.
Az adapter egy noname valami, lehetne feltételezni, hogy az ő linux támogatásával van a gond, de gyanús, hogy minden más eszköz is kb ugyanazon a sebességen hasal el. Még nem próbáltam a pendrive/HDD sebességtesztet windowson, de ha kell, megcsinálom azt is.
Elvileg van USB 3.0 támogatás a kernelben és ez látszik is:
$ zcat /proc/config.gz | grep XHCI_HCDCONFIG_USB_XHCI_HCD=yMi hiányozhat? dmesgben nincsen semmi error ezzel kapcsolatban.
Köszi!
-
Tiszteletem!
Végső kétségbeesésemben ide írok, hátha valaki okosabb itt, mint én. A történet annyi, hogy van egy rootolt LG Smart TV-m, amelynek sikerült kidumpolni a rootfs-ét, illetve a gyártótól rendelkezem a kernel forrásokkal, illetve egy x86_64 kompatibilis toolchainnel. A TV maga armv7 soft float.
Szeretnék appokat fordítani a TV-re, de a canadian cross compile megoldás a toolchainnel x86_64 vasról nem éppen kézenfekvő. Sokkal kényelmesebb lenne fordítani egy natív gcc-t a toolchain segítségével, majd az egészet felrakni a TV rootfs-ébe és oda chrootolva nem közvetlenül a TV-n, de egy kicsi ARM szerveren buildelni. Szóval ez az elképzelés.
A gyakorlatban nem sikerült a desktopomon futó Arch Linuxról, vagy a szerveren futó Fedoráról buildelni, egy régi ubuntu chrootot használtam, ami ráadásul 32 bites. A célnak viszont megfelel. Ami viszont érdekes, hogy nem akar lefordulni a gcc, amikor a make végigszalad az összes függőség mappáján, akkor a libgcc-nek valamiért nem adja át a gcc gyökerében lévő configure által konfigolt környezeti változókat és emiatt, mivel nem talál pár fejlécet a libgcc make, le se fordul. Nyilván kézzel lehetne korrigálni, de nem ez lenne a szép megoldás.
Erről a linkról letölthető a chroot, amiben dolgoztam: [link]
A chrootba belépve kellenek a környezeti változók a buildeléshez:
. /opt/webos-sdk-x86_64/1.0.g/environment-setup-armv7a-neon-webos-linux-gnueabiMajd a következő sorokkal próbálok fordítani:
cd /root/gcc-build
CC="arm-webos-linux-gnueabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=softfp --sysroot=/opt/webos-sdk-x86_64/1.0.g/sysroots/armv7a-neon-webos-linux-gnueabi" CXX="arm-webos-linux-gnueabi-g++ -march=armv7-a -mfpu=neon -mfloat-abi=softfp --sysroot=/opt/webos-sdk-x86_64/1.0.g/sysroots/armv7a-neon-webos-linux-gnueabi" ../gcc-6.2.0/configure --prefix=/opt/webos-sdk-x86_64/1.0.g/sysroots/armv7a-neon-webos-linux-gnueabi --with-mpfr=/opt/webos-sdk-x86_64/1.0.g/sysroots/armv7a-neon-webos-linux-gnueabi --host=armv7a-linux-gnueabi --target=armv7a-linux-gnueabi --build=x86_64-linux-gnu
make -j8ÉS egy kis idő után ezt a hibát dobja: [link]
Ha belenéz az ember a létrejött build mappában a libgcc config.logja tényleg mintha teljesen ignorálná a build változókat és a külső configure flageket. Nem értem mit rontok el.
Van ötlet esetleg? Nagyon jó lenne, ha sikerülne lebuildelni.
Köszi!
-
Szintén Telekom. Lakossági ügyfélként anno felhívtam őket, hogy oldják már fel a 25-ös port blokkját (alapból csak a telekom smtp-t lehetett vele elérni), mert kellene "munkához", a kérést 24 órán belül teljesítették is. Az más kérdés, hogy utána lemondtam az otthoni mailszerver ötletéről, mert fix IP-t csak céges előfizetés mellé adnak, anélkül meg, dinamikus poolból származó IP címről normális mailszerver nem fog emailt fogadni. Illetve a reverse dns/ptr sem beállítható, anélkül még kevesebb klienst érsz el sikerrel.
Végül feldobtam egy mailcow docker containert egy $3 VPS-re, ahol eleve adott volt a fix IP, meg a reverse dns. Igaz, ezt se használnám elsődleges emailnek, mert ha épp ég a datacenter (pl OVH), vagy bármilyen maintenance történik a VPS provider részéről, lemaradok pár emailről. Van jó pár olcsó email szolgáltatás, amik garsntálják a 99.99% SLA-t, ezekben próbálok bízni...
-
Üdv!
Adott egy Fedora Server-t futtató dedikált vas. Bár a hoszting adna IPv6-ot, egyelőre az általuk adott IPv6 cím egyáltalán nincs belőve, így a szerver csak IPv4-en csatlakozik. Egyelőre nem volt rá szükség.
Viszont most jól jönne egy nagyobb IPv6 blokk, mivel beüzemeltem egy proxyt rajta és azt vettem észre, hogy ha minden kérés egyetlen IP címről hagyja el a vasat, akkor a google meg az összes nagyobb oldal egy idő után captchával kezdi el bombázni a usereket. Tehát az a terv, hogy hozzáadok a proxyhoz egy nagyobb IPv6 blokkot és minden proxy user kap majd egy dedikált címet, vagy az egész round robin lesz (még nem döntöttem el). Mivel a hoszting csupán egyetlen IPv6 címet ad, így a tunnelbroker felé kezdtem el kacsintgatni. Annyit érdemes tudni a szolgáltatásról, hogy ingyen adnak egy /48 IPv6 blokkot kérésre egy sit tunnellel. Egy /48 valószínűleg bőven elég lenne számomra, így ez tökéletesnek tűnik. Szeretném felrakni, viszont az általuk javasolt parancsok nem megfelőek számomra:
modprobe ipv6ip tunnel add he-ipv6 mode sit remote 216.66.66.66 local <szerveremipv4cime> ttl 255ip link set he-ipv6 upip addr add 2001:470:1f08:412a::2/64 dev he-ipv6ip route add ::/0 dev he-ipv6ip -f inet6 addrUgyanis itt egyrészt a /64 blokkot rendeli az interfészhez, nekem pedig a /48 kellene. Így egyszerűen az "ip addr add" sorban a /48-at adtam meg helyette. És ez így működik is szépen. Futtattam még egy
sysctl -w net.ipv6.ip_nonlocal_bind=1ésip -6 route replace local <48asipv6blokkom> dev loparancsokat és a proxy már tudja is használni a teljes range-t. Igen ám, viszont a default route miatt a teljes rendszer ipv6-os forgalma a tunnelen keresztül fog zajlani, amit nem szeretnék, mivel a tunnel jóval lassabb, mint a fizikai interfészem, illetve csak a proxyn belül van szükségem az IPv6-ra, más programokkal felesleges.Gondolkoztam, hogy a default route helyett hogyan tudnám megoldani, hogy csak bizonyos programok számára legyen a sit tunnel elérhető. Van egy megoldásom, amit a VPN-ek esetében szoktam használni, hogy csinálok egy felhasználót és annak a forgalmát irányítom egy adott interfészre. Valahogy így néz ki a parancssorom hozzá:
adduser ipv6id ipv6 # uid: 1004, gid: 1005 az esetembenmodprobe ipv6ip tunnel add he-ipv6 mode sit remote 216.66.66.66 local <szerveremipv4cime> ttl 255ip link set he-ipv6 upip addr add 2001:470:1f08::2/48 dev he-ipv6ip -6 rule add uidrange 1004-1004 table he-ipv6ip -6 rule add default dev he-ipv6 table he-ipv6Ennek mennie kellene és az ipv6 user forgalmának elviekben a tunnelt kéne preferálnia, de a gyakorlatban, mintha az uidrange feltétel nem működne ipv6-tal. Ugyanez a módszer ipv4-gyel remekül működik.
Mit tudok tenni? Gondolkoztam VM-men, de az nagyon béna megoldás, illetve network namespace-n/vrf-en, de azt nem sikerült összehozni...
Illetve van egy wireguard VPN kliensem. Meg tudom csinálni, hogy a sit forgalmat VPN-nen keresztül bonyolítom le? Vagy a wireguard L3-on működik, a sit pedig "lentebb van"?
Köszönöm!
-
-
válasz
f_sanyee
#30401
üzenetére
Nem csak a partíciós tábla változott, hiszen a Windows partíció létre lett rajta hozva. Elvileg a testdisk megoldja ezt és átméretezi az NTFS-t. Csak azért aggódom, hogy ha meg mégsem, akkor lehet, hogy utána photorec-kel se állítom majd helyre a fájlokat egyenként... De egy repartition csak nem okoz nagy galibát.
-
Üdv!
Történt, hogy a számítógép használatban kevésbé rutinos családtag leformázta a merevlemezét egy véletlen folytán, Windows recovery disk rossz helyre ment ezzel legyalulva a partíciókat és egy FAT32-t hagyott a windows telepítő fájloknak. Kértem, hogy ne írjon rá többet és csatolja le, így nagy adatvesztés a Windows telepítőn kívül nem történhetett. Csak a partíciók vesztek el.
Futtattam rajta egy testdisket, meg is találta a vélhetően hiányzó NTFS partíciót:
A kérdésem az, hogy merjem-e futtatni a testdisket, hátha visszaállítja a partíciókat? Vagy egyenest vegyek egy másik 2 TB HDD-t és photorec-kel próbáljam meg menteni a dolgokat? Csak a képekre lenne szüksége, viszont félek, hogy a partíciók létrehozása csak még több kárt okozna. Tudom, az lenne a legoptimálisabb, ha egy másik HDD-re tükrözném ennek a tartalmát és úgy kisérleteznék, de csak ezért nem akarok beruházni ennyi HDD-be.
Ui.: bocs, ha egy picit off, természetesen Linux alól próbálom helyreállítani a lemezt egyébként...
-
válasz
samujózsi
#29482
üzenetére
Fedora szerver nem jöhet szóba? Hatalmas az image, de nagyon jól teszi a dolgát nálam (dedikált szerverek). Selinux van, de nem kötelező használni. Stabil és friss csomagok vannak, csak egyszer futottam bele, hogy a grubot kiadták hibásan, ezért nem frissült a kernel lista.
Vagy az, vagy Alpine, vagy Ubuntu Server.
-
-
Elvileg, ha nem adom hozzá a permanent flaget, akkor azonnal életbe lép a cucc a következő reloading. Ha a permanent flaget használom, akkor kell manuális reload.
De megoldottam az app oldaláról, így a kérdés tárgytalan.
-
Üdv!
Sehogy nem bírok rájönni, hogyan tudnék egy bizonyos portot forwardolni, majd elérhetővé tenni a neten firewalld-vel. Ezekkel a parancsokkal próbálkoztam:
firewall-cmd --add-masquerade --zone=FedoraServerfirewall-cmd --zone=FedoraServer --add-forward-port=port=32400:proto=tcp:toport=42300firewall-cmd --add-port=42300/tcp --zone=FedoraServerA cél az lenne, hogy a 32400-on futó Plex szerverem kintről a 42300-en legyen elérhető ideiglesen. Viszont ez nem működik. Fedora 31.
Ami még rettentő érdekes, hogy az iptables is üres:
iptables -LÖtlet?
-
Sziasztok!
Nginx-et próbálok belőni egy NAS-on webDAV kiszolgáló gyanánt, fel és letöltésre. Tökéletesen megy a letöltés része, a szöveges fájl létrehozás/szerkesztés is ok intézőből, de ha nagyobb fájlokat másolok, tölti egy darabig, aztán timeoutol. Ezeket a konfig paramétereket próbáltam beállìtani:
proxy_max_temp_file_size 0;
proxy_buffering off;
client_body_temp_path /tmp;
client_body_timeout 0;
client_max_body_size 0;
server_names_hash_bucket_size 256;Mi hiányozhat még? Köszi!
-
-
Üdv!
Adott egy TS3 (TeamSpeak) szerver amely egy igen erős szerveren lett installálva. A probléma csak az, hogy ezt a vasat szeretnénk a DoS-tól megkímélni, s erre a célra van is egy jó DDoS védelemmel felszerelt budget VPS-em. A cél pedig az lenne, hogy reverse proxyzom az egész forgalmat.
A probléma csak az, hogy a TS a 9987-es UDP portot használja a hanghoz, amit az általam ismert programok közül csak az nginx képes proxyzni. Adott egy ilyen konfig:
stream {
server {
listen 9987 udp;
proxy_pass ts3_stream_backend;
#proxy_timeout 1s;
#proxy_responses 1;
error_log /var/log/nginx/ts3.log;
}
upstream ts3_stream_backend {
server <origin_szerver_ip_volt_itt>:9987;
}
}Ezek után a port rendben elérhetővé válik, netcattal szépen látom is, hogy nyitva, fogadja a csomagom. Viszont a TS nem hajlandó proxyzva csatlakozni. Direkt IP természetesen gond nélkül megy. A kikommentezett részt próbáltam alkalmazni, az sem segített.
Hogy tudnám mégis megoldani?
Köszönöm!
-
Van egy VPS-em OVH-nál, régen egy webappot futtatott, ma már azt sem, csak megvan.
Ma reggel beléptem és ez fogadott loadnak:96.09 96.03 96.01 1/496 18989
Ám a szerver egyáltalán nem tűnt leterheltnek, sőt! gyakorlatilag mindent azonnal le is futtatott. Hogy lehetséges ez?
-
válasz
Frawly
#28172
üzenetére
Ok, desktop. De ez nem az oprendszer típusától függ, hogy most van-e GDE vagy sem. Hanem egész egyszerűen azért, mert az otthoni hálózatok nagyja eleve NATolva van. Ott is van iptables, csak a routeren. De feltételezem, hogy a kolléga nem desktopon tervez PHP, webszerver, FTP kombót futtatni, hanem valami VPS vagy akármilyen szolgáltatáson.
(#28173) vargalex
Én a VPS/dedikált szerver világban élek. Ott a legesleggyakoribb lépés, hogy a szerverednek saját külső IPv4-es, illetve nemritkán IPv6-os címe van, s alapból minden ki van engedve a netre. Az a használóra van bízva, hogy használ-e tűzfalat, vagy sem.
-
válasz
Frawly
#28168
üzenetére
Linuxon nem nagyon használnak az emberek tűzfalat
Hát azért én inkább mondanám, hogy de. Egy épeszű konfig általában tartalmaz tűzfalat, amiből a kerneles iptables/mostmár nftables messze a legjobb választás vélményem szerint. Ez az ufw is csak egy iptables wrapper, nem teljesértékű tűzfal, csak iptables szabályokat hoz létre.
Az FTP meg fetételezem a passzív kapcsolódás miatt nem ment a kérdezőnek. vstfp konfigban a passzív porttartományt is elérhetővé kell tenni. De ahogy olvasom ez a probléma már megoldódott.
Ahogy az én korábbi failoveres anomáliám is. Volt egy olyan ötletem ma, hogy a gazdagép gateway-t fogom használni. Hát megy is.
-
válasz
Frawly
#28159
üzenetére
Az egész fizikai szerveremhez egyetlen egy hálókártya tartozik, ez DHCP-n kap egy statikus IP-t, amin megy a net. Egyébként OS oldalon a NIC az eno1 interface-t kapta meg, illetve van egy bridge rajta, a vmbr0, amit a Proxmox hozott létre. Feljebb posztoltam konfigot róluk.
Viszont e mellé vettem még egy statikus IP címet, ami szintén ugyanazon hálókártyához tartozik, de a DHCP sosem osztja ki neki. Ezt az OVH úgy hívja, hogy failover IP, amit két módon, IP aliasing, illetve IP bridging-gel lehet használni. Ennyi a setup.
-
-
válasz
bambano
#28154
üzenetére
Az a része az openswitch miatt van, Proxmox specifikus: [link]. Működik is.
Kiszedtem a gateway-t, most a failover IP-t használná, mint gw (automatikusan ezt állította be).
rp_filter szintén kikapcsolva a hoszt vmbr0 interfacen, sajnos nincs net így sem.
+ Van egy bridge specifikus leírásuk is, engem ugyan nem segített ki. [link] Pedig tegnap egy délutánon át próbálkoztam. Illetve ez itt dettó ugyanaz a setup, végigmentem a lépéseken, mégse megy.
Szerk: egyébként fura nekem ez a teljesen valid IPv6 cím, amit meg simán megkap.
Mégsem lehet pingelni azt sem. -
válasz
bambano
#28152
üzenetére
Teljesen jogos. Dedikált vas egy OVH datacenterben, tehát nem, nem VPS. Fizikailag egy hálókártyával van felszerelve, amihez lehet kapni failover IP címeket. Van is egy leírásuk aliasingra itt.
A failover IP lényege, hogy ha időközben másik szerverre költöznék náluk, a failover IP-ket megtarthatom, s csak az eredeti, hálókártyához ingyen kapott (vagyis az alap árban benne szereplő) IP-met bukom, azaz a Proxmox hoszt IP-jét. Ezt nem bánom, csak a VM-ekhez szeretném ezeket a failover IP-ket társítani. Így vehetek két ugyanolyan vasat tükrözéssel, s csak az IP-ket kell áttennem a msáik vasra.
Egyébként az alap konfigot úgy kaptam, hogy a Proxmox fut közvetlenül a vasra telepítve (én tettem fel). Az eno1 interface pedig magától létrejött, DHCP-n kapja meg a hálózaton a saját statikus IP címét.
Ez most az interfaces fájlom még nem megosztott, jelenleg is működő része:
allow-vmbr0 eno1
iface eno1 inet dhcp
ovs_type OVSPort
ovs_bridge vmbr0
auto vmbr0
iface vmbr0 inet manual
ovs_type OVSBridge
ovs_ports eno1Feltételezem, hogy ezek a failover IP címek pedig VLAN címek, tehát mindenképp csak egy NIC-em van, azon kell kimennie mindennek.
tehát összebridgeled a virtuális gép külső interfészét (amit a hoszt os-en látsz belőle) a gazdagép fizikai ethernet kártyájával, erre a bridge-re teszed rá a valamilyen ip-t, és a virtuális gépen belül teszed be a fix ip-t.
Pontosan ezt próbáltam korábban. A vmbr0 a bridge ebben az esetben a gazdagépen, ezt adtam meg a VM kártyájának, meg megkapta a vMAC címet. A telepített Fedora pedig megkapta a statikus IP-t, gateway-t, subnetet, DNS-t. Eredmény: nincs net.
-
válasz
bambano
#28150
üzenetére
A végső cél az lenne, hogy a Proxmoxos virtuális gépeim saját IP-t kapjanak, ne kelljen a NAT-tal kínlódni. Így nincs port forward anomália, s a 80-as portot is tudom használni per VM szabadon (nem kell egy reverse proxy mindenhez).
De úgy végképp nem akart összejönni, ezért szerettem volna elsősorban tesztelni a hoszt OS-on, hogy hátha tudok csinálni egy másik interface-t, amin lesz net. Így legalább láthatom, hogy működhet a dolog.
A másik indok pedig, hogy szerverek költöztetésénél az alapon kapott statikus címem is elúszik, a failover pedig örökre az enyém, havidíj nélkül. Ha költözni akarok, ezeket lehet mozgatni másik hosztra, s nem kell a DNS-től kezdve mindent átíratni, hogy az új szerveren is menjen (tervben van egy cluster építése, ami több nodeból áll).
-
válasz
bambano
#28148
üzenetére
Közben gondolkodtam a szituáción, s arra a következtetésre jutottam, hogy mivel plusz hálókártya nem járt az IP mellé, illetve a szerver hálózata mellé sávszélesség korlátozás is jár, amit egyszerű lenne kijátszani több IP rendelésével, valószínűleg arról van szó, hogy változatlanul egy hálókártyám, s egy eno1-es interface-m van. Az IP pedig VLAN IP. Tehát valahogy azt kéne tudnom elérni, hogy ugyanazt a hálókártyát használja mindkét interface. Ha jól értem, ezt hívják IP aliasingnak, amikor egy NIC több IP-t kezel.
iface eno1:0 inet static
address <kapott IPv4 címem>
netmask 255.255.255.255
hwaddress ether <kapott virtual MAC>
gateway <kapott IPv4 előtagja>.254Majd próbáltam egy
ifup eno1:0parancsot, eredmény: Link exists.ip addr flush dev eno1:0 && ifup eno1:0és az egész kapcsolat lehalt. Csak a KVM segített.Hogy tudnám akkor ezt most mégis összehozni?
-
-
Újabb anomáliába ütköztem ezzel a szerverrel, mégpedig az IP kapcsán. Vettem hozzá egy statikus IP-t (ha működik, akkor egy egész blokk be van tervezve), a cél pedig az lenne, hogy a Proxmox virtuális gépeim mind saját IP-t kapjanak. A szerver konfig oldalon volt egy olyan opció, hogy virtuális MAC hozzáadása IP-hez, ezt ki is választottam, kaptam is egyet. Majd próbaképp a Proxmox rendszeren létrehoztam egy interfészt (/etc/network/interfaces):
auto vmbr1
iface vmbr1 inet static
address <kapott IPv4 címem>
netmask 255.255.255.255
broadcast <ipv4 címem előtagja>.254
bridge-ports none
bridge-stp off
bridge-fd 0networking kapott egy restartot, de a teljes szervert is próbáltam, eredmény:
vmbr1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet <kapott IPv4 címem> netmask 255.255.255.255 broadcast <kapott IPv4 címem>.254
inet6 <valahonnan beszerzett valid IPv6 cím> prefixlen 64 scopeid 0x20<link>
ether <vMAC cím, amit kaptam> txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5 bytes 446 (446.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Eddig jó, viszont
curl --interface vmbr1 google.comtimeoutra fut, ping IPv4, IPv6 címen az interface-ről indítva szintén nem működik, traceroute semmi... Pingelni sem tudom a kapott IPv4-es címem más eszközről.Ezek után próbálkoztam Proxmox-szal, tehát a hoszt OS-on lelőttem a vmbr1-es elérést, majd a virtuális gépem az elsődleges interface-re kapott bridge-t, a proxmox konfigban a virtuális MAC címet megadtam. Fedora Server telepítéskor pedig kézzel kitöltöttem az IP, broadcast és netmask mezőket a fenti példának megegyezően, ezutén rebootoltam. Eredmény, ifconfig szintén mutat egy IPv6-os címet (nem ugyanaz, de hasonló), viszont a broadcast cím nem 254-re végződik, hanem konkrétan az IP címmel egyezik meg, hiába adtam meg a gateway-t pontosan. Net, ping, DNS feloldás, semmi sincs. Akár az előző esetben. Bár itt TX és RX csomagokat is mutat az ifconfig kimenet.
Nem vagyok egy nagy hálózati guru, és itt el is vesztettem a fonalat. Ötletem sincs, hol szúrhattam el a dolgot. Már csak arra tudok gondolni, hogy a proxmox-os gép tűzfala kavarhat be, aholis iptables + ufw aktív. ufw teljesen alap beállításokon van, tehát az SSH kivételével minden IN forgalmat blokkol.
Mit csinálhatok rosszul?
-
válasz
Mr Dini
#28142
üzenetére
Igazság szerint napok óta szenvedek ezzel, cégnél egy tucat sysadmint végigkérdeztem, senki nem látott még ilyet. A végére annyira nem volt ötletem, hogy mindkét diszken csináltam egy dd-s formázást. Újra az egész procedúrát, s láss csodát, működik!
Ötletem sincs miért, de nem lehet panaszom. A dd mindent megold!
-
Üdv!
RAID1 beállítással kínlódok Debian alatt. A vasban van 4 egyforma típusú, méretű HDD amiből az sdb és sdc párost szeretném összefűzni. Alapból mindkettőn volt egy GPT tábla, illetve egy 512 MB méretű EFI partíció. Ezeket fdisk-kel töröltem, majd adtam neki egy
mdadm --create --verbose --raid-devices=2 --level=1 /dev/md0 /dev/sd{b,c}parancsot, hagy' szóljon! mdadm szólt, hogy vigyázzak, ugyanis nem üres a diszk, ennek ellenére y-nal megerősítettem a kérelmet.Majd egy
mkfs.ext4 /dev/md0, illetve egy csatolás utáni meggyőződés során meggyőződtem róla, hogy a tömb működik.Adtam neki egy
mdadm --detail --scan | tee -a /etc/mdadm/mdadm.confés egyupdate-initramfs -uparancsot is, fstabba beleírtam a csatolási pontot és rebootoltam. Reboot után kötet sehol, journalctl szerint a csatolás timeoutolt, s mdadm verbose kimenetre azzal bombáz, hogy Expected magic <uuid>, got 00000000. Nagyon régen csináltam RAID kötetet, de ilyesmi anomáliára nem emlékszem.Mit csinálok rosszul?
-
Mangle. marking, routing rendben megy. A szabályt kivéve remekül megy a user forgalma a VPN-re.
És az OUTPUT chain-be megy, mert a DROP esetén, ami az OUTPUT-ban van is látom kérések esetén, hogy mennek oda csomagok. A kérdés csak, hogy miért a DROP kapja el.
-
-
Üdv!
Van két iptables szabályom az OUTPUT chainben, azonban nem igen akarnak úgy működni, ahogyan én szeretném.
0 0 ACCEPT all -- * tun0 0.0.0.0/0 0.0.0.0/0 owner UID match 1069
0 0 DROP all -- * !lo 0.0.0.0/0 0.0.0.0/0 owner UID match 1069Adott az 1069 UUID-jú user, aminek megjelölöm minden csomagját, és routeolom a forgalmát VPN-re. Gyakorlatilag ez alapján próbálkoztam: [link]
Viszont akármit csinálok, mindig a DROP rule alkalmazódik, hiába van a tun0 előbb. Úgy tudtam, hogy mindig az első rule számít. Vagy nem?
-
Sziasztok!
Egy minimális, Busybox alapú initrd ramdisket gyártok épp, melynek célja ténylegesen csak egy speciális eszköz rootfs-ének indítása lenne. Vagyis nem más, mint egy switch_root parancs futna le rajta.
A kernel támogatja az EXT2-t, illetve az USB-t is, viszont a device node-ok érthető módon nem jönnek létre, hiszen jóformán csak egy busyboxos bin mappám van, illetve a sys és proc fel van csatolva. Így viszont nem tudom a teszt pendriveom - melyen a rootfs van - azonosítani...
A findfs természetesen üres kimenettel tér vissza. Így csak egy rescue shell-t tudok indítani.
Hogy tudnám megoldani?
Szerk.:
Ez a parancs hibát dob egyébként:
mount -n -t devtmpfs devtmpfs /dev -
Rendben, magic number probléma elhárítva!
Ténylegesen a gcc okozta a galibát.Most egy másik fw-vel próbálkozom, aminek az initrd fájlja 35,7 MB. Ezt kicsit nehézkes lenne a ramba tölteni, majd bootolni vele u-boot alól minden alkalommal...
Fogtam, felcsatoltam, majd kibontottam a teszt pendriveom rootfs cimkéjű partíciójára. Viszont initrd nélkül nem tudom használni a root=LABEL=rootfsbootargs argumentumot... UUID alapján is próbáltam azonosítani, sajnos az sem ment. Hogyan tudnék initrd nélkül bootolni közvetlenül az USB HDD-mről?Illetve megpróbáltam tömöríteni ezt a monstrumot. Egy cpio és egy gzip tömörítés után kaptam egy 8.8 MB-os fájlt. Faragtam belőle egy uInitrd-t, a szemlátomást betölti az u-boot rendben a fájlt. Csak a hiba továbbra is fennáll, innen gondolom, hogy valami mégsem jó...
Mit tudok tenni?
-
Sziasztok!
Megkaptam az ARMv5 NAS-omhoz a GPL forrást, s szeretnék kezdeni valamit vele. Konkrétan kernel modult szeretnék vele forgatni...
Tesztelésképp lefordítottam a még untouched kernelt, s megnéztem a modulok magic number-jét. Ezt az eredményt kaptam, azaz eltér a kettő (az első az élő rendszerből kihalászott modul readelf kimenetje). Így nem működhetnek a modulok, jól sejtem? Hogyan lehetséges ez, ha a gyártó elvileg ugyanazt a GPL forrást adja ki, amivel Ő is fordít?
Köszönöm a válasz(oka)t!
-
Modulnál viszonylag ritkán látok configure szkriptet, vagy autoconf-ra utaló nyomokat... A klónozott github forráson sincs fent configure (vagy configure.ac/in). Ezt simán egy make paranccsal kéne leforgatni, csak valamiért nincsen Makefile a kernel fejlécek arch/powerpc64/ mappájában, amire viszont a modulnak szüksége lenne.
-
#26382
Mr Dini
addikt
MasterMark
#26378
válasz
MasterMark
#26378
üzenetére
Szia!
Első ránézésre nem egyezik a kernel verzió a linux-headers verzióval (a jelenlegi ...104-es, a linux-headers meg ...37-es kernelhez van).
Add ki ezt, ha a generic nem megy:
sudo apt-get install linux-headers-$(uname -r)Igazából fogalmam sincs mit csinálok, ez amúgy a jó kernelre való fordítás lenne, vagy mi a manó ez?
Ha jól látom, akkor egy Realtek USB wifi dongle modult & fw.-t módosítanál, aztán forgatnál le az aktuális kernelhez, majd telepítenéd.
-
Sziasztok!
Adott egy Apache webszerver, aminek az egyik feladata egy domain kiszolgálása lenne. Íme a konfig részlet:
<VirtualHost *:12345>
DocumentRoot "/var/www/ext"
ServerName domain.tld
SSLEngine on
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>
<VirtualHost *:12346>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>Az 12345-ös port ki volt téve alapértelmezetten a külső 80-as és 443-as portokra. Viszont, hiába van ott a rewrite, nem irányít át HTTP-ről HTTPS-re, hanem dob egy Bad request hibát, ami magáért beszél. Az SSL miatt csak a HTTPS címen jön be a tényleges tartalom, így át kell írni kézzel a címet.
Viszont, ha az 12346 címet teszem ki a 80-as portra, a korábbi 12345 pedig marad a 443-on, akkor működik a rewrite. Csak nekem ez olyan félmegoldás szerű. Szeretném egy belső portról/vhostról megoldani.
Mi lehet a gond?
Köszönöm!
-
válasz
#59070464
#26269
üzenetére
Szia!
Például így:
cd /tmp/; wget https://updates.signal.org/android/Signal-website-release-4.12.3.apk
unzip -xq ./Signal-website-release-4.12.3.apk -d ./apk
keytool -printcert -file ./apk/META-INF/CERT.RSATudtommal azért így adják meg, mert minden aláírt APK fájl rendelkezik egy META-INF/*.RSA fájllal, amihez a privát kulcs csak a fejlesztőnek van meg (azaz más nem tudja legyártani ugyanezt). Gyakori, hogy meg van adva, pont a klónok elkerülése végett.
-
Sziasztok!
Van egy repository-m, ahol GPG kulccsal van alátámasztva, hogy az MD5-öket tartalmazó fájl valóban tőlem származik-e. Egy beágyazott eszközökre módosított slapt-get csomagkezelő az alany egyébként.
Namost, a probléma ezzel az, hogy a
slapt-get --add-keyshatására sikeresen települnek a kulcsok a /root/.gnupg/ mappába, illetve az adott user home könyvtárába, s minden megy is szépen, mígnem jön egy reboot. Ugyanis a /root/ ezeken az eszközökön csupán ramdisk, szóval nem hosszú életű. Tudom-e fixálni valahogy a gnupg esetében, hogy ne a home könyvtárat, hanem valami mást használjon mindenképp?Most azt a workaroundot használom, hogy .profile-ban rögzítettem egy alias-t, ami a slapt-get kiadása esetén fölülírja a HOME változót egy olyan mappára, ami reboot után is marad érintetlen. Ez a megoldás működőképes, de jobban érdekelne egy GnuPG-s megoldás is az sem baj, ha újra le kell fordítani.
Remélem érthetően definiáltam a problémát...
Köszönöm!
-
Sziasztok!
Nagy nehezen fordítottam egy vsftpd-t a beágyazott linuxot futtató NAS-omra. Az elérési utak itt teljesen máshogy vannak. Szóval seddel, illetve kézzel igyekeztem mindent beállítani pöpecre. Engedélyeztem az SSL támogatást is, merthogy a cél egy FTPS szerver létrehozása lenne majd.
Csináltam egy alap FTPS konfigot, majd létrehoztam egy test nevű usert, melynek a shellje a nologin lett, s átállítottam a home mappáját is megfelelően. Ezt követően megpróbáltam csatlakozni... A kulcs rendben megérkezik a kliensre, látszólag minden rendben, viszont a login elhasal egy 530 Login incorrect hibával.
Néztem az Arch packages weboldalon, hogy a pam csomag az egyik függősége. Nos, van ilyenem telepítve, de csak one-hand build, azaz anno csupán a radius szerver fordításhoz készítettem teljesen alap konfigurációval. Csak a header fájlok megléte miatt kellett. A vsftpd fordítása során viszont nem láttam sehol pam-ra utaló részt, illetve egy függősége sem utal erre:
0x00000001 (NEEDED) Shared library: [libcrypt.so.0]
0x00000001 (NEEDED) Shared library: [libdl.so.0]
0x00000001 (NEEDED) Shared library: [libc.so.0]
0x00000001 (NEEDED) Shared library: [libutil.so.0]
0x00000001 (NEEDED) Shared library: [libssl.so.1.0.0]
0x00000001 (NEEDED) Shared library: [libcrypto.so.1.0.0]
0x00000001 (NEEDED) Shared library: [libssp.so.0]Egyébként én ha lehet szeretném enélkül a pam nélkül használni a vsftpd-t. Lehetséges ez valahogyan? Ha nem, akkor mit tehetek?
Köszönöm!
-
Sziasztok!
X szervert forgatnék ARM platformra cross compilerrel. A hoszt gép egy Ubuntu 14.04 x64 LTS és az arm-linux-gnueabi-gcc-t használom (meg persze a linkert, art stb.-t hozzá).
Viszont itt elakad a make:
CCLD xkbcomp
/usr/lib/gcc-cross/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/bin/ld: warning: libxcb.so.1, needed by /home/pisti/Asztal/Xorg-Pi/storage/.kodi/addons/service.Xorg/root/usr/local/lib64/libX11.so, not found (try using -rpath or -rpath-link)
/home/pisti/Asztal/Xorg-Pi/storage/.kodi/addons/service.Xorg/root/usr/local/lib64/libX11.so: undefined reference to `xcb_get_file_descriptor'
/home/pisti/Asztal/Xorg-Pi/storage/.kodi/addons/service.Xorg/root/usr/local/lib64/libX11.so: undefined reference to `xcb_connect'
/home/pisti/Asztal/Xorg-Pi/storage/.kodi/addons/service.Xorg/root/usr/local/lib64/libX11.so: undefined reference to `xcb_generate_id'
/home/pisti/Asztal/Xorg-Pi/storage/.kodi/addons/service.Xorg/root/usr/local/lib64/libX11.so: undefined reference to `xcb_connect_to_display_with_auth_info'
/home/pisti/Asztal/Xorg-Pi/storage/.kodi/addons/service.Xorg/root/usr/local/lib64/libX11.so: undefined reference to `xcb_writev'
/home/pisti/Asztal/Xorg-Pi/storage/.kodi/addons/service.Xorg/root/usr/local/lib64/libX11.so: undefined reference to `xcb_poll_for_reply64'
/home/pisti/Asztal/Xorg-Pi/storage/.kodi/addons/service.Xorg/root/usr/local/lib64/libX11.so: undefined reference to `xcb_wait_for_reply64'
/home/pisti/Asztal/Xorg-Pi/storage/.kodi/addons/service.Xorg/root/usr/local/lib64/libX11.so: undefined reference to `xcb_poll_for_event'
/home/pisti/Asztal/Xorg-Pi/storage/.kodi/addons/service.Xorg/root/usr/local/lib64/libX11.so: undefined reference to `xcb_get_maximum_request_length'
/home/pisti/Asztal/Xorg-Pi/storage/.kodi/addons/service.Xorg/root/usr/local/lib64/libX11.so: undefined reference to `xcb_take_socket'
/home/pisti/Asztal/Xorg-Pi/storage/.kodi/addons/service.Xorg/root/usr/local/lib64/libX11.so: undefined reference to `xcb_wait_for_event'
/home/pisti/Asztal/Xorg-Pi/storage/.kodi/addons/service.Xorg/root/usr/local/lib64/libX11.so: undefined reference to `xcb_disconnect'
/home/pisti/Asztal/Xorg-Pi/storage/.kodi/addons/service.Xorg/root/usr/local/lib64/libX11.so: undefined reference to `xcb_connection_has_error'
/home/pisti/Asztal/Xorg-Pi/storage/.kodi/addons/service.Xorg/root/usr/local/lib64/libX11.so: undefined reference to `xcb_get_setup'
/home/pisti/Asztal/Xorg-Pi/storage/.kodi/addons/service.Xorg/root/usr/local/lib64/libX11.so: undefined reference to `xcb_parse_display'
collect2: error: ld returned 1 exit status
make[2]: *** [xkbcomp] Error 1Ötletem sincs, miért hiányolja azokat a libeket, mivel direkt mikor először kiírta a hibát, kézzel leforgattam az xcb-t és telepítettem is a /home/pisti/Asztal/Xorg-Pi/storage/.kodi/addons/service.Xorg/root/usr/local/lib64/ mappába...
Mi lehet a probléma? Mert ott a lib, de mégsem látja.
Köszi!
Szerk.: Mi ez az rpath? Mindjárt ránézek!
-
válasz
Mr Dini
#25012
üzenetére
Megvan a megoldás!
A tgt mailing listen megmondták a tutit. A CHAP authentikácíót ilyen formában nem csípi az open-iscsi initiator. Szóval újrakonfigoltam a targetet CHAP userek nélkül, és láss csodát, megy!Viszont a Windows beépített initiatorja képes CHAP kapcsolódásra, így azt is le tudtam tesztelni, megy szuperül. Már csak arra kéne rájönni, hogy az open-iscsi login parancsába hogyan lehet beleszőni a user és pass paramétereket (a konfig fájlban megoldás nem opció sajnos).
-
Üdv!
Most egy iSCSI targetet szerettem volna feltenni a NASomra... Mindenek előtt leszögezem, hogy nagyon kezdő vagyok a témában, még csak most kezdem felfogni, hogy hogyan működik...
No, tehát a hw egy ARM NAS, a targetet pedig a tgt (saját fordítás) tartja kézben.
Az első kérdésem ezzel kapcsolatban, hogy ha kilövöm a tgtd-t, majd újra elindítom, akkor miért tűnik el a már kész konfig? Ez normális? Vagy csak valami bugos és rá kéne nézzek a forrásra ismét?
2. Létrehoztam egy alap iSCSI targetet, amihez a LUN egy fizikai pendrive lett. Illetve csináltam két user-t. Az egyik outgoing, a másik egy sztenderd. Aztán open-iscsi-vel próbáltam felcsatolni a meghajtót az Ubuntu-s PC-mre, de az Ubuntu ezt dobja:
sudo iscsiadm -m node --login
Logging in to [iface: default, target: iqn.<titkos>:<titkos>, portal: 10.0.0.27,3260] (multiple)
iscsiadm: Could not login to [iface: default, target: iqn.<titkos>:<titkos>, portal: 10.0.0.27,3260].
iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure)
iscsiadm: Could not log into all portalsÉs ilyen a dmesg az initiatornál (Ubuntu gépen):
[ 1558.954228] scsi host6: iSCSI Initiator over TCP/IP
[ 1558.963626] connection6:0: detected conn error (1020)És itt látható a target konfigja.
Mi lehet a gond?
Nagyon köszönöm!
-
Hello!
Véletlenül felraktam a lowlatency kernelt is a Desktop Ubuntu-mra és most nem bírok tőle megszabadulni. purge nem segített, a kernel meg az initramfs ott maradt... Hogyan tudnám teljesen kukázni?
Köszi!
-
-
#24990
Mr Dini
addikt
szőr Artúr
#24975
válasz
szőr Artúr
#24975
üzenetére
Szerintem a probléma az, hogy a bedugott pendrive device node-ja, azaz pl /dev/sdb nem jön létre valamiért és emiatt nem látszik a pendrive partíciója az fdisk kimenetben és ezért nem megy a mount sem.
De. hogy miért viselkedik így a kolléga Ubuntu-ja, arról lövésem sincs...
-
válasz
Jester01
#24789
üzenetére
Nem tudtam rájönni fél nap alatt sem... Valószínű, hogy olyan hálózati dolgot használok, ami linuxon vmiért nem megy...
qemu nem rossz ötlet, köszönöm!
Vagy a droidot is vboxban.
Sajnos az nehézkes... Az Android studio AVM kezelőjét használom. VB alatt nem hiszem, hogy menne az adb gazdagépen pl.
Akkor a kvm-re nincs megoldás?
-
Üdv!
Egy olyan gondom lenne, hogy egy Androidos programot fejlesztek egy 64 bites 14.04-es Ubuntu Desktopon. Van a programomnak egy szerverprogramja is, ami csak Windowson fut (wine, mono nem indítja sajnos, pedig .NET-ben írtam), szóval párhuzamosan kéne fusson egy Droid emulátor és egy virtualboxos Windows. Külön megy is, viszont a droidnak is kell a kvm_intel modul a virtualboxnak meg nem, és ahogy látom nem akar a VB elindulni, ha az Android fut és a kvm_intel modul be van töltve... Az egyik mindig hibát dob...
Hogy tudnám egyszerre használni a kettőt?
Köszi!
-
Üdv!
HDD titkosításra mit ajánlotok? Olyan kéne, amivel linux, Win és Mac alól is lehetne valamit kezdeni.
Létezik ilyesmi?
Ha igen, akkor van olyan, melyhez nem szükséges külön kernelmodul? Csak mert nincs sok kedvem kernelt cserélni az u-boottal megint és a jelenlegi kicsit hadilábon áll a modulokkal... Ettől függetlenül persze ilyen is érdekelne!
Köszi!
-
Az fstab sem segített, így újraraktam az egészet és a friss rendszeren belőttem egy backupot.
Köszi mindenkinek!
-
Leírásom nincsen, nem is tudom, hogy létezik-e ilyesmi... Google első oldal nem talált...
Tehát az Androidban 4.4 óta létezik a SELinux. A kitkat esetében még alap esetben ki volt kapcsolva, de az 5.*-tól már alapból engedélyezett.
Én annyit csináltam, hogy az android system.img-t felcsatoltam a /mnt alá és elhelyeztem oda a su binárist, majd, hogy az emulátor következő bootkor ne haljon meg, mivel a su binárison nincsenek rajta a megfelelő selinux beállítások, megpróbáltam egy chcon-t végrehajtani. De meglepődve tapasztaltam, hogy nincs fent a chcon. Így utánaolvastam és azt írták, hogy a selinux csomagot kell feltennem. Fel is tettem és ezután kezdődött az anomália... :/ Hogy nem indul be a rendszerem.
Nekem mostmár mindegy, hogy sikerül-e rootolni azt az emulátort, vagy nem, csak kapjam vissza kompletten a rendszert!
Örök hálám!
-
Mert az emulált droidom (AVD), amit az Android Studioval hoztam létre szerettem volna rootolni. És a su binárist kellett volna korrigálnom SELinux szempontból.
A bootos, csatolásos dolgot meg megoldottam. Nincs külön partíción. Egyedül annyit kellett tennem, hogy mountolnom kellett a /dev-et, a /run-t, a /sys-t és a /tmp-t, aztán ment minden. Csak a rendszert nem bírom élesben bebootolni.
-
válasz
Mr Dini
#24687
üzenetére
Chrootbol probaltam letorolni, majd ujra visszatenni a selinux csomagot, de ezt dobja:
semodule deferred processing now taking place
Error opening /etc/selinux/ubuntu/contexts/files/file_contexts.local: No such file or directory
libsemanage.sefcontext_compile: sefcontext_compile returned error code 255. Compiling /etc/selinux/ubuntu/contexts/files/file_contexts.local
libsemanage.semanage_install_active: Could not copy /etc/selinux/ubuntu/modules/active/file_contexts.homedirs to /etc/selinux/ubuntu/contexts/files/file_contexts.homedirs. (No such file or directory).
/usr/sbin/semodule: Failed!
dpkg: error processing package selinux (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
selinux
E: Sub-process /usr/bin/dpkg returned an error code (1)Es rebootnal csak annyit ir, hogy nem tudja elerni a /root/selinux mappat, mert read only a fajlrendszer...
Pedig chrootbol lehet hasznalni...
Szerk.: masodik nekifutasra ezt kapom:
root@ubuntu:/# apt-get install selinux
Reading package lists... Done
Building dependency tree
Reading state information... Done
selinux is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 50 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
E: Can not write log (Is /dev/pts mounted?) - openpty (2: No such file or directory)
Setting up selinux (1:0.11) ...
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-38-generic
Found initrd image: /boot/initrd.img-4.4.0-38-generic
Found linux image: /boot/vmlinuz-4.4.0-36-generic
Found initrd image: /boot/initrd.img-4.4.0-36-generic
Found linux image: /boot/vmlinuz-4.2.0-42-generic
Found initrd image: /boot/initrd.img-4.2.0-42-generic
Adding boot menu entry for EFI firmware configuration
done
* Starting SELinux autorelabel [ OK ]
Processing triggers for initramfs-tools (0.103ubuntu4.4) ...
update-initramfs: Generating /boot/initrd.img-4.4.0-38-genericDe a hiba ugyanaz...
-
Üdv!
Android fájlrendszer módosítást kellett eszközölnöm, ahol (az androidon) aktív a SELinux természetesen.
Így feltettem az Ubuntu 14.04 Trusty LTS 64 bites desktop rendszeremre a SELinux csomagot, a szokásos apt-get install selinux paranccsal, de hibával elszállt a telepítés. Aztán toltam neki egy rebootot és onnantól nem áll fel a rendszer.... A grub bejön, aztán csak villog az alsókötőjel, aztán egyszer csak kiböki, hogy a /usr/.../selinux mappa nem létezik (sajnos nem írtam fel a pontos elérési utat).
Na, szuper, tégla lett a frissen belakott rendszer!
Szóval gyorsan bootoltam egy Live rendszert és chrootból letöröltem a purge paranccsal, de ott is dob egy errort, hogy a kernelt nem tudta frissíteni... Gondolom, mert a chrootba nincs felcsatolva a /boot, csak azt nem tudom, h azt hogy kéne kivitelezni....
Mi lehet a gond?
Köszi!
-----------
Par info:
Error a selinux torlesnel:
dpkg: error processing package linux-image-4.2.0-27-generic (--remove):
subprocess installed post-removal script returned error exit status 1
Errors were encountered while processing:
linux-image-extra-4.2.0-27-generic
linux-image-4.2.0-27-generic
E: Sub-process /usr/bin/dpkg returned an error code (1)Es az fdisk azon resze, mely ay Ubuntue:
Device Boot Start End Blocks Id System
/dev/sda1 2048 1357421969 678709961 83 Linux
/dev/sda2 1357422592 1367187455 4882432 82 Linux swap / Solaris -
Sziasztok!
Ubuntu-n szeretnék futtatni egy .NET-es exe-t wine-nal. Próbáltam mono-val, de ezt dobja:
Unhandled Exception:
System.InvalidProgramException: Invalid IL code in .: (): IL_0037: brtrue.s IL_0048
[ERROR] FATAL UNHANDLED EXCEPTION: System.InvalidProgramException: Invalid IL code in .: (): IL_0037: brtrue.s IL_0048Mit tudok tenni?
Köszi!
-
#24539
Mr Dini
addikt
Tóniszomszéd
#24538
válasz
Tóniszomszéd
#24538
üzenetére
Ez oke, de a pendriveom mi lesz? /dev/sda1? (marmint a root= parameternel)
Najó, asszem teszek a partícióra Label-t, ha mashogy nem megy...
-
#24537
Mr Dini
addikt
Tóniszomszéd
#24536
válasz
Tóniszomszéd
#24536
üzenetére
U-bootot hasznalok, abbol is valami nagyon regit...
Ott nem hiszem, hogy lehet UUID alapjan root=-ot allitani...
De lehet, h az a gond, hogy az uInitrd nincs betoltve. Most probalom ugy is. De mar egy ket perce ezt irja:
Marvell>> bootm 0x800000 0xf00000
## Booting image at 00800000 ...
Image Name: Linux-4.4.0-kirkwood-tld-1
Created: 2016-08-29 12:18:53 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3168283 Bytes = 3 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
OK
## Loading Ramdisk Image at 00f00000 ...
Image Name: initramfs-4.4.0-kirkwood-tld-1
Created: 2016-02-19 7:33:04 UTC
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 7179871 Bytes = 6.8 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel. -
Hi!
Probalok bebootolni egy Debian kernel-t U-boot-tal, de a rootfs-t (ami pendrive-n csucsul) nem tudom neki megadni...
Hogy kene?
Ime egy pastebin a jelenlegi allapotrol. (sorry, mini ablakban volt nyitva a minicom, ezert a vege lemaradt... de a lenyeg latszik igy is)
Koszi!
-
#24499
Mr Dini
addikt
Tóniszomszéd
#24498
válasz
Tóniszomszéd
#24498
üzenetére
Mint írtam (csak a kombóra nem emlékeztem jól), ha olyan történne, h a GUI nem jön be, akkor pl ubi esetében nyomsz egy Alt+F2-t, bejelentkezel és kapsz egy ugyanolyan terminált, mint amit a GUI ad be Neked a Ctrl+Alt+T kombóra.
Szerintem ebben már lehet konfigot túrni, pl mcvel és a rossz csomagokat is le tudod húzni.
-
#24493
Mr Dini
addikt
Tóniszomszéd
#24492
válasz
Tóniszomszéd
#24492
üzenetére
Hello!
Szerintem az egész futó rendszert lebackupolni lehetetlen egy HDDre...
Max valami bootolható backup software tudná lementeni All in a rendszered.
De ha csak pl a rootfs-t szeretnéd menteni, akkor azt két linux gép között, pl rsynccel tudod megtenni, vagy duplicity-vel.
Én egyébként gyártottam egy diskless ubuntut, felraktam pxere és ezt a pxe-s rendszert használom itthon. Backup is van, az egész pxe szerver mappát rsync áttolja naponta a nasomra, így ha valami gáz lenne, akkor vissza tudom tenni a tegnapi állapotot. Jó, nyilván ez egy kicsit overkill, de így nem kell aggódnom, jogy kifogyok a laptop HDD-k tárkapacításából!
Egyébként, ha a win vált be, mi ösztönzött a váltásra?
Ui.: ha elrontod a rendszert pl az nvidia telepítéssel, akkor asszem Ctrl+F2-vel át tudsz lépni parancssorba és ott, ha elég ügyes vagy, le tudod szedni a rossz csomagokat.
Ránézek erre a hupra!
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Köszi a válaszokat!
Akkor a napi futtatást fogom választani és ellenőrizni a szkript elején, hogy mikor kell lefutnia. Szerintem nem fogok at-vel szórakozni, hanem egy fájlból (a konfigja) kiolvasom az előző futtatás dátumát, összehasonlítom a mostanival és ha még nincs 80 nap, akkor simán exitelek...
Systemd-m sajnos még nincsen, egy kernelverzió választ el tőle, hogy lehessen...
-
Üdv!
Noob kérdés, de a crontab tud 80 naponta futtatni egy szkriptet? Vagy max 31 nap lehet?
Reboot után újraszámolódik a 80 nap, vagy mindenképp az előző lefutáshoz számítja az időt?
Köszi! -
válasz
Mr Dini
#24414
üzenetére
Juhé! Az volt a gond, hogy kézzel, azautoreconf --install-lal gyártottam le az automake-s cuccokat, nem pedig az autogen.sh-t használtam. Noob report! Így már lefordul.Ja korai öröm volt
, file-al ránézve ez egy x64-re fordított bináris lett, tehát nem vette figyelembe a --host=mipsel-openwrt-linux-t. Megadtam neki a CC-t kézzel, de ezt dobja:mipsel-openwrt-linux-gcc -DPACKAGE_NAME=\"Automatic\" -DPACKAGE_TARNAME=\"automatic\" -DPACKAGE_VERSION=\"0.8x\" -DPACKAGE_STRING=\"Automatic\ 0.8x\" -DPACKAGE_BUGREPORT=\"http://forum.dsmg600.info/t2291-%5BREL%5D-Automatic-funplug-0.5.html\" -DPACKAGE_URL=\"\" -DPACKAGE=\"automatic\" -DVERSION=\"0.8x\" -DSTDC_HEADERS=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_FCNTL_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_FORK=1 -DHAVE_VFORK=1 -DHAVE_WORKING_VFORK=1 -DHAVE_WORKING_FORK=1 -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=0 -Dmalloc=rpl_malloc -DHAVE_STDLIB_H=1 -DHAVE_REALLOC=0 -Drealloc=rpl_realloc -DRETSIGTYPE=void -DHAVE_STAT_EMPTY_STRING_BUG=1 -DHAVE_STRFTIME=1 -DHAVE_DUP2=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_LOCALTIME_R=1 -DHAVE_REGCOMP=1 -DHAVE_STRERROR=1 -DHAVE_STRSTR=1 -I. -I../include/ -I/usr/include/libxml2 -g -Wall -W -Wdeclaration-after-statement -O0 -funroll-loops -c -o ../src/automatic.o ../src/automatic.c
In file included from ../src/automatic.c:62:0:
../include/web.h:24:23: fatal error: curl/curl.h: No such file or directory
#include <curl/curl.h>
^
compilation terminated.Hát igen, nincs a Staging dir-ben curl. Hogy tudnám pótolni? Simán lefordítom?
Nah, közben ez is megoldva!
Igen, csak le kellett fordítani. -
Nah megint egy érdekes dologba futottam bele. Kérésre szerettem volna lefordítani az Automatic-ot, de gyanítom egy automake frissítés miatt nem úgy viselkedik, ahogy szeretném...
Ezt kapom, amikor lefuttatom a
make-t.Nyitok egy ticketet Giten is, bár a fejlesztő nem valami aktív mostanában...
Részlet:
make[1]: Entering directory `/home/pisti/Asztal/Automatic/src'
Makefile:692: ../src/.deps/automatic.Po: No such file or directoryValamiért ../src/-vel kezdődik, ./helyett...
Hogy lehetne megoldani?
-
válasz
bambano
#24403
üzenetére
Hát...
src/util] gcc -Wmissing-prototypes -Wformat -DHAS_PCRE -I/ffp/include -DNO_NIS -c dict_nis.c
In file included from dict_nis.c:33:0:
sys_defs.h:1260:2: error: #error "unsupported platform"
#error "unsupported platform"
^
sys_defs.h:1319:2: error: #error "define HAS_FCNTL_LOCK and/or HAS_FLOCK_LOCK"
#error "define HAS_FCNTL_LOCK and/or HAS_FLOCK_LOCK"
^
sys_defs.h:1323:2: error: #error "define DEF_MAILBOX_LOCK"
#error "define DEF_MAILBOX_LOCK"
^
sys_defs.h:1327:2: error: #error "define INTERNAL_LOCK"
#error "define INTERNAL_LOCK"
^
sys_defs.h:1335:2: error: #error "define USE_STATFS or USE_STATVFS"
#error "define USE_STATFS or USE_STATVFS"
^
sys_defs.h:1345:57: error: unknown type name 'size_t'
extern const char *inet_ntop(int, const void *, char *, size_t);
^
In file included from dict_nis.c:55:0:
mymalloc.h:17:1: warning: parameter names (without types) in function declaration
extern char *mymalloc(ssize_t);
^
mymalloc.h:18:32: error: unknown type name 'ssize_t'
extern char *myrealloc(char *, ssize_t);
^
ymalloc.h:21:38: error: unknown type name 'ssize_t'
extern char *mystrndup(const char *, ssize_t);
^
mymalloc.h:22:37: error: unknown type name 'ssize_t'
extern char *mymemdup(const char *, ssize_t);
^
In file included from dict_nis.c:56:0:
vstring.h:22:18: fatal error: vbuf.h: No such file or directory
#include <vbuf.h>
^
compilation terminated.
Makefile:132: recipe for target 'dict_nis.o' failed
make: *** [dict_nis.o] Error 1
Makefile:46: recipe for target 'update' failed
make: *** [update] Error 1 -
-
válasz
vargalex
#24397
üzenetére
Az Arch-os tuti, hogy nem uClibc-n fordult, lásd a PKGBUILD-et hozzá. Én nem látok ott tiltást az rpc-re.
Egyébként ha az openWRT-t nézzük, akkor ez azt jelenti, h ha egy Glibc-s (Ubunturól) Cross-compile-olom a cuccot, akkor működőképes lesz? Szerinted nem fogja hiányolni a headert? Mert van toolchainem, GPT kernel source tree-m, de feleslegesen nem akarok szenvedni...
-
Üdv!
Sajnos jönnöm kell megint egy kérdéssel...
Mailszerver-t szeretnék gyártani a nasomra, de fordításnál elhasal azzal, hogy nincs
rpcsvc/ypclnt.hfájlom. Nos igen, asszem ez pont egy Glibc-s header és a nason uClibc dolgozik (sajnos).Valakinek sikerült már uClibc-re feltenni (fordítással) a postfix-et? ARMv5 platform, ha ez számít.
A
makevége pedig:gcc -Wmissing-prototypes -Wformat -DHAS_PCRE -I/ffp/include -g -O -I. -DLINUX2 -c dict_nis.c
dict_nis.c:42:27: fatal error: rpcsvc/ypclnt.h: No such file or directory
#include <rpcsvc/ypclnt.h>
^
compilation terminated.
Makefile:132: recipe for target 'dict_nis.o' failed
make: *** [dict_nis.o] Error 1
Makefile:46: recipe for target 'update' failed
make: *** [update] Error 1
Makefile:15: recipe for target 'update' failed
make: *** [update] Error 2 Köszi! -
válasz
vargalex
#24386
üzenetére
Szuper, köszönöm!
(sikerült)Elképesztő, hogy mennyit változott ~6 év alatt a dolog... Utoljára ugyanis ott csináltam ilyesmit.
Ui.: m'ért van az, hogy erről az lvm átméretezésről egy cikk sem ír a Gugliban, ha rákeresek? Mindegyik csak a VB-s VDI átméretezésig jut el.
-
Üdv!
Van egy virtuális ubuntu-m (virtualbox) a melóhelyemen. Ha valami sürgős fordítani valóm van, akkor ezen szoktam ügyködni, illetve az Android appjaim forráskódját tárolom itt.
Viszont balga módon csak 40 gigát adtam neki alapból és ez pik-pak elfogyott. Szóval kénytelen voltam terminálból átméretezni a virtuális hdd-t. Ez sikerült is, a VB mutatja is a nagyobb méretet. Aztán bootoltam egy GParted Live-val a gépet és kiterjesztettem az sda lemezt a teljes területre. Majd reboot után (már az Ubiba) a root könyvtár/csatolás ugyanúgy 40 giga... Csak a Disks nevű tool mutatja a kiterjesztett méretet...
Mit kéne csinálnom vele?
Fontos lenne az adatvesztés skippelése (kihagyása)!
Köszi!
-
válasz
Keeperv85
#24322
üzenetére
Nem pont ezt írtam másodiknak.
Ha ezt dobja, akkor a Minted alatt nincs rá policy fájl alapból, vagy nem tud hozzáférni a usered. Root alól esetleg?
Ha a
sudo seinfo --allkiadod, akkor ki kell, h dobja az összes komponensét, ha ott nem látsz semmit, vagy hiányzik a Neked megfelelő, akkor kézzel kell létrehozni... -
-
Sziasztok!
Androidra (arm) próbálok clamAV-t gyártani, de nem akar összejönni.
Itt írok róla picit részletesebben.
Szerintetek mi lehet a gond?
-
válasz
Jester01
#24298
üzenetére
Működik is. Csak ha nincs beállítva az LD_LIB... változó, akkor azt mondja, h a libc.so.1-et nem tudta betölteni. Viszont, ha beállítom a /opt/lib-re a változót, akkor megy. Viszont a /opt/lib mappában is csak libc.so.0 van, egyes sehol sincs... Szóval nem értem, h akkor hogy működik mégis...
Meg se jelent a nat listában. Fura ez a Fedora na.
Ténylegesen a gcc okozta a galibát.
Fogtam, felcsatoltam, majd kibontottam a teszt pendriveom rootfs cimkéjű partíciójára. Viszont initrd nélkül nem tudom használni a 
Bár az lsusb -t kimenetedből számomra inkább az előbbi, modulprobléma tűnik valöszínűbbnek.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone i5 10600KF 16/32/64GB RAM RX 7600 8GB GAMER PC termékbeszámítással
- LG 48C3 - 48" OLED evo - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - A9 Gen6 CPU
- REFURBISHED - HP USB-C Dock G4 docking station (L13899-001)
- Dymo LabelWriter 400 - Hőpapíros címkenyomtató
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest