- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Ez a telefon lehet a Moto G85 egy átnevezés után
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Poco X3 NFC - minden, ami kell
- Vodafone mobilszolgáltatások
- iPhone topik
- Milyen okostelefont vegyek?
- Felskálázza a Nubia a Snapdragon 8 Gen 3 órajeleit
- DIGI Mobil
- MIUI / HyperOS topik
Hirdetés
-
Rejtett díjak, nehéz lemondás: az USA pereli az Adobe-ot
it Nem csak rejtett díjakkal károsítja meg a fogyasztókat az Adobe, de az előfizetések lemondását is megnehezíti – ezért beperelte az USA kormánya.
-
Két hét múlva Samsung Galaxy Unpacked
ma A dátum július 10. A nagyszabású bemutatón hét terméket várunk, köztük az új hajlítható modelleket és a Galaxy Ring okosgyűrűt.
-
Olcsó USB WiFi AC adapter
lo Egy olcsó WiFi AC USB adapter jó szolgálatot jelenthet, ha az új router csak elvileg támogatja a 2,4 GHz-es átvitelt.
-
Mobilarena
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 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).
[ Szerkesztve ]
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
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.
[ Szerkesztve ]
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
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.
[ Szerkesztve ]
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
válasz Frawly #28156 üzenetére
Más a szituáció, itt nincs DHCP szerver, NAT se. Vagy egy NIC két IP-vel. Az egyiket a kártyához valóban DHCP cím rendel, de az egy fix "külső" IP, míg a másikat csak manuálisan lehet a VM-hez rendelni. A kérdés, hogy hogyan.
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
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.
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
-
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.
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
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.
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
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?
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
Ü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!
[ Szerkesztve ]
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
válasz bambano #28341 üzenetére
Ténylegesen csak annyi, hogy a végfelhasználók számára ne legyen visszavezethető a tényleges host IP. A kis VPS-nek remek hálózata és DDoS védelme van, jobb lenne, ha azt látnák.
OpenVPN-en gondolkoztam én is, végső soron az lesz...
[ Szerkesztve ]
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
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!
[ Szerkesztve ]
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
Ü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=FedoraServer
firewall-cmd --zone=FedoraServer --add-forward-port=port=32400:proto=tcp:toport=42300
firewall-cmd --add-port=42300/tcp --zone=FedoraServer
A 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?
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
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.
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
válasz haddent #29470 üzenetére
Pedig az iptables volt az első, amit próbáltam, pontosan így. A routeremre is ránéztem, az hogy csinálja. Semmi. Meg se jelent a nat listában. Fura ez a Fedora na.
A firewalld legalább az esetek többségében működik. Ufw-vel meg nem élek, sok mindent nem tud ugyanis.
[ Szerkesztve ]
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
válasz haddent #29474 üzenetére
Otthoni consumer router, ami tudja a port forwardot és a GUI mögött iptables van. Azt használtam puskázni. Hogy lássak egy működő példát. De pontosan az volt, mint amit írtál.
Amúgy semmi közük egymáshoz.
[ Szerkesztve ]
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
-
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.
[ Szerkesztve ]
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
Ü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...
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
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.
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
válasz f_sanyee #30403 üzenetére
Mármint adat is lett rá írva. A Windows recovery fájlok. Egyéb esetben nem lenne kérdés, megpróbálkoznék a partíciós tábla 1/1 helyreállításával. De így a testdisk egy átméretezett NTFS-t csinálna az eredeti helyett. A kérdésem, hogy ez megéri-e/működhet-e?
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
-
Ü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 ipv6
ip tunnel add he-ipv6 mode sit remote 216.66.66.66 local <szerveremipv4cime> ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f08:412a::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -f inet6 addr
Ugyanis 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 lo
parancsokat é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 ipv6
id ipv6 # uid: 1004, gid: 1005 az esetemben
modprobe ipv6
ip tunnel add he-ipv6 mode sit remote 216.66.66.66 local <szerveremipv4cime> ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f08::2/48 dev he-ipv6
ip -6 rule add uidrange 1004-1004 table he-ipv6
ip -6 rule add default dev he-ipv6 table he-ipv6
Ennek 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!
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
-
-
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...
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
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-gnueabi
Majd 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!
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
Ü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_HCD
CONFIG_USB_XHCI_HCD=y
Mi hiányozhat? dmesgben nincsen semmi error ezzel kapcsolatban.
Köszi!
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
A Ventoy, ezzel a pluginnel nem játszik?
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
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?
[ Szerkesztve ]
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
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.
[ Szerkesztve ]
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
válasz ledgeri #32431 üzenetére
Szerintem, ha bármilyen scammer meglátja, hogy tails-t használsz, vagy linuxot in general, nem is foglalkozna veled. Ezek általában Windows userekre vannak kiélezve és rávesznek, hogy lépj be a netbankodba.
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
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.
[ Szerkesztve ]
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
-
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.
Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!
Új hozzászólás Aktív témák
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Ez a telefon lehet a Moto G85 egy átnevezés után
- PlayStation 5
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Poco X3 NFC - minden, ami kell
- Kerékpárosok, bringások ide!
- DIGI kábel TV
- Autós topik látogatók beszélgetős, offolós topikja
- RAM topik
- További aktív témák...