Hirdetés
- Samsung Galaxy S24 - nos, Exynos
- Kiderült, mekkora aksi van az iPhone 16-okban
- Mobil flották
- iPhone topik
- Motorola Edge 50 Ultra - szépen kifaragták
- Samsung Galaxy S22 Ultra - na, kinél van toll?
- Redmi Note 13 Pro+ - a fejlődés íve
- Fotók, videók mobillal
- Telekom mobilszolgáltatások
- Honor Magic5 Pro - kamerák bűvöletében
Hirdetés
-
Érkezik a Redmi Watch 5 Lite
ma Szeptember 25-én Indiában lesz az aktivitáskövető premierje, és lehet, hogy marad is azon a piacon.
-
Megújult a Glorious GMMK klaviatúracsaládja, és már van benne analóg modell is
ph A GMMK 3 többféle méretben, házanyaggal, hagyományos és mágneses switch-ekkel, vezetékkel, illetőleg anélkül egyaránt választható.
-
Jövő év elején jön a most bejelentett Like A Dragon: Pirate Yakuza in Hawaii
gp Kalóz jakuzák Hawaii-on, azaz újabb őrület vár ránk február végétől.
-
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
-
samujózsi
senior tag
válasz kovaax #28654 üzenetére
Jó kérdés, valahogy nálam a process/app tevékenység felderítés, nekem nem tetsző hozzáférési kísérletek listázása = audit.
Jobban lehet/tudom szabályozni, hogy mit, hogyan.
Pl nem kell vesződni azzal, hogy kié volt adott pillanatban az a pid, aki a bejegyzést generálta, mert lekérdezhető, amennyire még fel tudom idézni.[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Jim Tonic
nagyúr
Nem figyeltem a frissítéseket, illetve eddig nem is tűnt fel, de mikor jött a Sambára ennyire komoly fejlesztés? Szenvedtem a 30-40MB/s sebességgel, tegnap meg feltűnt, hogy 102 körül mozog. Végre. Vagy 10 éve szívtam ezzel, mindegy volt, mit hogyan állítottam be.
Alcohol & calculus don't mix. Never drink & derive.
-
vargalex
félisten
-
inf3rno
nagyúr
válasz Jim Tonic #28656 üzenetére
Az SMB nem volt karbantartva nagyon hosszú ideig. Én is próbáltam írni nekik még évekkel ezelőtt, hogy ugyanmár állítsák be normálisan a chunk méretet, mert túl kicsire vették a default-ot, és kritikán aluli volt a sebesség miatta azt hiszem Ubuntuban. Eljutottam egészen a bug report oldalukig, ahol nem lehetett semmit beküldeni, gondolom mert az utolsó, aki távozott a projektből lekapcsolta a villanyt. Lehet, hogy felkarolta most valaki, aki hajlandó is foglalkozni vele. A CIFS mounttal egyébként ment eddig is a 100.
[ Szerkesztve ]
Buliban hasznos! =]
-
Dißnäëß
nagyúr
válasz haddent #28607 üzenetére
Az esetek többségében - kivétel mindig lesz, lehet nem is kevés - a mögöttes folyamatok sem mindegy, milyenek.
Például egy ~100+ "gépes" (VM-ek és konténerek vegyesen) teljes IT stack-et Azure-ben felépítve és üzemeltetve az erőforrás igénye sem összemérhető egy on-premise private cloude-éval, a hozzá adott csilliárd analitikáról és automatizálhatóságról meg n+1 nézetről nem is beszélve.
És aki azt mondja, nem tökéletes, meg itt-ott beteg, szar, izé ? Hát én még private cloud-ból sem láttam olyat, amibe nem lehet belekötni.
De a folyamatok mögötte akkoris... private cloud-nál vagy urambocsá, annak "elődjénél", az on-premise (akár DC-ben is) lévő üzemeltetésnél waterfall gigaprojektek verekednek iszonyú hiperdilettáns ITIL-helpdesk-szolgáltatási szinteken és xyz Service Management / Ticketing tool-okon keresztül mind hardver erőforrásért, mind élőember (know-how) erőforrásért, és mire elér valami egy úgy-ahogy értékelhető stádiumba, már újra kéne tervezni lassan a projektet, mert a világ odakint közben fordult kettőt. Egy tényleges public cloud mögött pedig (jó esetben, ha alkalmazható, de nem kötelező) egy agilis csapat valamiféle formája van, relatív nagy sebességű reakciókkal változó üzleti igényekre, amiket rendszerben is le tudnak követni és nem úgy, hogy feladom ticket-be a Change Request-et, vagy L1 felveszi nagylassan-tökhanyagul az incidens ticket-et és onnantól várunk heteket, néhol hónapokat hogy történjen valami a hülyebuta-erőforráshiányos-nagyájtín a háttérben, hanem kb. behúzza PO a sprintbe, valamilyen prio-val ellátja oszt a devops összeüti neki öt kattintással, mondjuk egy új UAT környezetet, mert (ahogy az lenni szokott) a tesztelők épp elfogytak egy új feature tesztelésére tervezett környezetből, "mert azon még az xy release-be menő akármi egyéb fut " épp a Tosca-val, Katalonnal, vagy kőbaltával fullmanuálban. Ez agilisben egy szó szerint agilisen, gyorsan reagálva történve van lekezelve, hozzá egy ezzel kompatibilis Azure-ös pár kattintásos dologgal, amikor fogom az egyik korábban összeállított template-et (vagy az élest "replikálom", ez a legjobb, konzisztens lesz a teszt, abból pikkpakk beröffen egy újabb környezet (legyen az VM vagy konténer), felkonfigolódik, igény esetén még a frissítések is lejönnek rá, hálózat, környezeti változók, minden fiszfasz kialakul és ready to serve. Ott már nincs az, hogy az üzemeltető alvállalkozó embere túrja egy hétig meg konfigolgatja, aztán úgyis elakad, úgyis hívja Bélát a fő architektet, aki morogva de kisegíti, közben eltelt 7 nap.. Ez élőben úgy néz ki, hogy gomb megnyom, közben kimegyünk kajálni a közeli kínaiba, és mire visszaérünk, az infrás átkurjant az asztal fölött a tesztelőnek, hogy nyomhatjátok, közben JIRA-ban az erre kanban board-on felvett standalone issue-t gyorsba bekommenteli és cső, Done.
Szóval a public cloud szvsz nem CSAK magáról a technológiáról szól, hanem a mögé tett folyamatok gyorsaságról is. Arról nem beszélve, hogy ha a 100 gépből 20-30 teszt és ezek lefutnak és van kis levegő "semmittevés" teszt oldalon, ha épp nem kell az erőforrás, lelövi az ember és a stopper megáll: nem fizet érte az ember. Ha pedig kell, akár csak pár órahosszára is, akkor megint "play gomb" és mehet a boogie, pár plussz dolcsiért.
Összességében a private cloud-ban megoldott public cloud-os tech sima mezei installációként még nem adja mindazt a plusszt, amit tényleg ad egy public cloud. Persze ha nagyon kapálózik az ájtí főfejes, jöhet az MS felajánlani, hogy helybe letelepíti az ezsört az összes funkciójával együtt on-premise, csilingel is a kassza, ez szép megoldás lesz (és mindenki jól jár hehe, szép kis ország).. , csak ha 100 gép helyett 20-ra mondjuk nincs szükséged, mivel Nálad a host, az attól még bekapcsolva marad és fogyaszt, van egy költsége, míg a public cloud-ban a leverage effekt érvényesül, azaz tojsz magasan ezekre, ha nem használod az aktuális gépet pár órára vagy napra, lelövöd és kész, annyival kevesebb a költséged is, a többi meg a provider dolga (PaaS és ház a szilícium völgyben azért előrébb vannak tőlünk pár évvel). Az más, és mindenki döntse el magának, hogy a működő gépekért elkért költségbe beárazza-e a cloud szolgáltató e költségeket szétterítve - hogyne, nem hülye. De azért összességében még mindig van, amikor éves szinten több tíz millióval (!) jobban térül egy fully fledged Azure installáció, legyen az kicsi vagy nehézsúlyú k*sok gépes birkózó, mint egy on-premise private cloud csilliárdért, ami ennek tizedét sem (!!!) tudja... ahol a beszerzéstől az IT vezéren vagy CEO fővezéren át sokak kapnak vastag borítékot a beszállítótól, hogy ugyanmár, vegyétek a mi hardverünket és tessék-lássék supportunkat, segítünk, jóleszaz, egy kis Cisco ide, egy kis F5 oda, egy rack ide, egy EMC amoda, jólvan, buksisimi... A kassza meg csilingel..
Mondom ezt elfogultságmentesen kő linux pártiként és kicsit (de nem vakon) anti M$-esként.
Baszottul csak előre van út, szerintem. Erősen felhasználásfüggő, mi mire kell és megfelelő, nem jó mindenre sem egyik, sem másik megoldás, de azért a public cloud-ot nem tudnám most úgy leírni és lehúzni, mint ahogy akárcsak 2 éve is néztem rá.
A motyók több mint felét már egy ideje cloud szolgáltatóknak gyártják és ők is veszik, illetve lassan ők lesznek abban a helyzetben, hogy keresztbe-kasul bevásárolnak beszállítókból, maguknak ...
Át kell állni fejben, nincs mese.
Kígyó vére, béka hája, pók levedlett ruhája.. kondéromban lepke sül, kívánságom teljesül !
-
inf3rno
nagyúr
válasz samujózsi #28659 üzenetére
Nálam az volt a konkrét gond, hogy az ubuntu nautilus nevű fájl kezelője alapból SMB-t használt, és amikor fstabban beállítottam, hogy CIFS menjen a meghajtóra, akkor nem volt hajlandó jelszót kérni. Muszáj volt fstabban megadnom a jelszót, ami nem biztonságos megoldás, de csak így tudtam kihasználni a hálózat teljes sebességét. Azt hiszem SMB-vel is volt olyan könyvtár vagy beállítás, amivel lehetett jó sebességeket elérni, de valamiért mégis alapból baromi lassú volt amit a nautilus használt. Irtam először a gnome fejlesztőinek, ők irányítottak a nautilus-hoz. Irtam nekik, mondták, hogy ez nem az ő bajuk, hanem valami egységes fájlrendszer könyvtárat használnak, aminek már fogalmam sincs mi volt a neve, írjak oda. Irtam oda is, ők azt mondták, hogy az SMB kliens hibája, amit használnak, írjak inkább nekik. Aztán az SMB kliens oldalán már nem lehetett hiba bejelentést tenni, úgyhogy téma letudva. Kb. olyan életérzés volt, mint a garanciális meg a hivatali ügyintézések. Megkérdeztem a fájlrendszereseket, hogyha ennyire gány az SMB kliens meg nincs karbantartva, akkor miért azt használják valami másik könyvtár helyett, vagy miért az a default, de választ nem kaptam. Nem lettem valami nagy ubuntu fan azt kell, hogy mondjam. Próbáltam C-ben megtákolni, hátha, de nem az én nyelvem.
[ Szerkesztve ]
Buliban hasznos! =]
-
samujózsi
senior tag
válasz inf3rno #28663 üzenetére
Bocs, nem ezért kérdeztem. A windows környezetet évekkel ezelőtt száműztem az életemből és még akkorról maradt meg bennem, hogy talán a superuseren vagy askubuntun feltett sambás kérdésre az volt a válasz, hogy azt már CIFS-nek hívják, a samba felejtős, deprecated stb.
De a jelek szerint ez nem igaz. Vagy nem úgy...Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
sonar
addikt
Lehet, hogy mégis csak létezik vmi:
OpenSnitch – an Application Firewall for LinuxNem teszteltem csak belefutottam
A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!
-
-
bucihost
senior tag
Sziasztok! "nohup sh x.sh &" Megy, létrehozza a nohup.out-ot. viszont valamiért gondol egyet és csinál a pár megás logból több(100) gigát. Gondoltam rá, hogy cron-nal csinálok egy backupot máshova, a logot meg törlöm vagy ürítem. A mentés oké, törlés oké létre is jön az új log file. Viszont szabad hely nem szabadul fel... csak reboot után. Ezt valahogy ki lehet küszöbölni, hogy törlés után fel is szabaduljon a hely?
-
samujózsi
senior tag
válasz bucihost #28672 üzenetére
Ugye másolod, nem mv nohup.out x.x módszerrel csinálod?
Ha így van, a másolás után próbálj egy "echo >nohup.out" parancsot! Nem lesz teljesen konzisztens a végeredmény, ha nem tudod az x.sh futását felfüggeszteni, de talán nem lesz túl nagy az adatvesztés. Bocs, nem tudom mobilról formázni.[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
senior tag
válasz bucihost #28674 üzenetére
Kilövöd a nohup.out-ba író processzt és nem szabadul fel?
Milyen fájlrendszer van alatta?Bocs, el kell mennem, ha délutánig nem lesz aki tud segíteni, megpróbálok utánanézni. Az echo-nak elvben illene felszabadítani a helyet, legalábbis ext4 esetén, szóval tényleg furcsa.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
haddent
addikt
válasz Dißnäëß #28662 üzenetére
Ezzel nem teljesen értek egyet. Abban igazad van, hogy egy szolgáltató szolgáltat, ebből él. Tehát ha hiba van, kérés, igény bármi, akkor szólsz és ugranak rá, mert ha nem elvesztenek és elesnek a megélhetésüktől. Abban is igazad van, hogy mivel ők nem egy-kettő netán 100 instancet üzemeltetnek, hanem (száz)ezreket, vagy többet, ezért minden felgyorsul. Nagyobb csapat, egy helyen lévő hiba mindenhol javítódik, stb stb..
Na ezért nem szabad egy problémát megoldani többször, tipikus rabbit hole. Tudni kell keresni, mert 99%, hogy bármi jut eszedbe, már van rá megoldás és jobb, mintha te nekiállsz gányolni egy kis csapattal.Azzal nem értek egyet, hogy ezt lényegében részrehajlóan csak 3rd party hostinggal lehet elérni. Egyrészt elvből kiröhögöm még az olyan Azuret is, amit on-premise kihoz az m$ és ledob a pincédbe. Nálunk a cégnél van ilyen, ehh.. továbbra is az futkos ott amit az m$ akar, ki tudja mi.. Ezzel max. azt lőttük ki, hogy nem megy ki a public netre és nem tudják fizikailag elvinni az m$ telephelyéről. Ezek azért ma már megoldott dolgok szerintem, nem ezen van a hangsúly.
Nem rossz dolog ez, de az agile is kötött, főleg egy kommersz cégnél. Ami sokaknak tetszik (a mazohista hülyék ), épp ez, az előnye is, hogy kötött, az az óriási hátránya is. Míg egy open source projektnél ilyen nincs, ráadásul ott van előtted a programkód, nincs turpisság meg susmus. Szerintem a legjobb választás egy olyan open source implementáció ami mögé már kiépült egy kommersz cég, aki azonban nem az eladásból, hanem a supportból él. Ott megvan a napi szintű pörgés és a community ereje, viszont nem csak a gugli és stackoverflow marad, ha beüt a gatya.. Mindkét világ jósága.
Az, hogy a legtöbb cég és kedves kollega 20-25 évvel le van maradva pedig nem azt jelenti, hogy az törvényszerűen csak úgy működhet. Mondom ezt úgy, hogy ELTE -n tanultam papíron formális matematikai nyelven ciklust meg programkódot írni és C/C++ hívő vagyok, csak nem hülye Simán kiépíthető egy poc/teszt és egy live környezet. Előbbi akár napi szinten automatizálva rángatja a frissítéseket és verziókat, Jenkins CI build + test, amint pass át is csapja livera. Mindezt mondjuk Dockerrel megspékelve gyönyörűen logolható, nyomonkövethető és fenntartható környezetet kapsz ami oda-vissza véresre veri az akár onpremise akár public monumentális nevetséges őskövületi szarokat akik már csak a nevükből élnek, mert más előnyük nem maradt
Igen, az itt felsorolt megoldások merőben más gondolkodásmódot és szakembereket követelnek meg, mint az összekattintgatom egérrel microsoft jajjdejó megvan a winserver 2016 tanúsítványom elvégeztem a tanfolyamot dege#*menővagyok, de én ebben hiszek. Elismerem és elfogadom a te véleményed is, szerintem kicsit elkanyarodtunk és olyan mélységben tárgyalunk ahol nem feltétlen van megoldás és/vagy objektív igazság, hitvallás kérdése
[ Szerkesztve ]
-
Fecogame
veterán
mstmp használatával sikerült megoldanom a Gmail-ból email küldést (ssmtp-vel nem ment).
A ~/.msmtprc fájl tartalma:
account gmail
tls on
auth on
host smtp.gmail.com
port 587
user user@gmail.com
from user@gmail.com
password xxxxxxxxxxxxxxxxx
Amit szeretnék elérni, hogy az elküldött emailemnek legyen tárgya.
Most ezzel a paranccsal tudok emailt küldeni, viszont nincs tárgya:
echo "prohardver" | msmtp -a gmail user@gmail.com
Az alábbi parancs pedig hibát dob:
echo "prohardver" | mail -s "tárgy" user@gmail.com
mail: Cannot open mailer: No such file or directory
mail: cannot send message: No such file or directory
Hogyan lehetne megoldani, hogy legyen tárgya az emaileknek? A mail parancs "megjavítása" lenne a legjobb megoldás
Lassú a mobilinterneted? 4G/LTE antennák, közvetlenül raktárról ---> http://bit.ly/LTE_Antennak
-
samujózsi
senior tag
-
#68216320
törölt tag
Van egy Ubuntu 18.04 szerver-em, ami az előbb kapott egy áramkimaradást. 2db HDD 2-2 partícióval két RAID1 tömbben van. Valahogy le tudnám ellenőrizni, hogy rendben van-e a RAID?
cat /proc/mdstat nen mutat problémát, de gondoltam valami korrektebb ellenörzés jó volna.
Esetleg resync? md0 a root (/) alá van csatolva, az md1 adatpartíció (4TB) -
#68216320
törölt tag
Segítenél értelmezni a kapott eredményt?
Én nem látok semmi problémát.
EXT4 fájlrendszer/dev/md0:
Version : 1.2
Creation Time : Tue Feb 19 10:33:01 2019
Raid Level : raid1
Array Size : 9757696 (9.31 GiB 9.99 GB)
Used Dev Size : 9757696 (9.31 GiB 9.99 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Wed Oct 9 13:24:49 2019
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : resync
Name : SERVER:0
UUID : ffe5b372:5373598e:701c5824:9e944667
Events : 1121599
Number Major Minor RaidDevice State
2 8 18 0 active sync /dev/sdb2
1 8 2 1 active sync /dev/sda2
/dev/md1:
Version : 1.2
Creation Time : Tue Feb 19 10:34:11 2019
Raid Level : raid1
Array Size : 3896925184 (3716.40 GiB 3990.45 GB)
Used Dev Size : 3896925184 (3716.40 GiB 3990.45 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Wed Oct 9 12:56:30 2019
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : bitmap
Name : SERVER:1
UUID : f5ab782c:c11aa09c:3f7398cc:a1a4fdd8
Events : 21341
Number Major Minor RaidDevice State
2 8 19 0 active sync /dev/sdb3
1 8 3 1 active sync /dev/sda3
[ Szerkesztve ]
-
-
Frawly
veterán
Na, most lett elegem ebből a linuxos random seed baromságból. Egyre jobban belassítja a bootot Archon, hosszú extra másodperceket jelent bootidőben.
Valamelyik itteni ubuntus topik hatására használtam egy ideig a haveged csomagot, ami ezt hivatott orvosolni, azzal gyorsabb is lett, de a régi bootidőt az sem hozta vissza teljesen. De egy idő után az újabb kernelekkel belassult (1 perc fölé majdnem) az is, úgyhogy eltávolítottam, nem volt más választásom.
Most viszont anélkül is egyre hosszabb a bootidő, systemd-analyze blame a system-random-seed.service-re hivatkozik, 8-10 mp. között van Próbáltam ezt systemctl disable módszerrel letiltani, de hasztalan, minden bootkor elindul csakazért is.
Hogy lehetne az egész Linuxból, kernelből, systemd-ből gyökeresen kitiltani ezt a random-seed baromságot, egyszer és mindörökre??? Nem az NSA-nak titkosítok államtitkokat, adataimat vagy külső hardveres titkosítással védem (SSD ATA jelszó), vagy egy másik gépen már legenerált kulccsal és hash-el ellátott LUKS titkosítással. Nem kell ez a random seed baromság egyáltalán, örökre meg akarok szabadulni tőle. Erre valakinek ötlete?
-
-
Frawly
veterán
válasz sh4d0w #28690 üzenetére
Kösz a linket, azt tudom, hogy ez micsoda, mire való. Nagyon elszomorítana, ha nem tudnék tőle megszabadulni. Nem igaz, hogy valami kernelparaméter nincs erre, hogy az egész random-seed-es baromságot abbahagyná, és végre lehet lehetne tiltani a system service-t is.
Lassan már érik nekem egy nem systemd-s disztróra váltás, vagy Void, vagy Gentoo. A Devuan nekem nem elég friss. A választék meg korlátozott, elég kevés systemd-s disztró maradt. Így végül lehet nem is a binárisok optimalizálása miatt váltok Gentoo-ra.
-
samujózsi
senior tag
válasz Frawly #28689 üzenetére
Nálam ez egy ubuntu szerveren jött elő. Valamelyik service (lehet, hogy saját készítésű volt) túl sok véletlenszámot használt, sajnos a részletekre nem emlékszem.
Próbáltam megkeresni, mert telesírtam vele a fórumokat, de helyette ezt találtam: [link]
Hátha valamelyik komment segít.
Illetve egy másik bug report: [link]
Ebben az az érdekes, hogy mindkettő a 243-as systemd telepítésével hozza összefüggésbe (persze lehet, hogy ugyanaz a bejelentő, csak a nick más)És a poettering által javasolt olvasnivaló is segíthet: [link]
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Frawly
veterán
válasz samujózsi #28692 üzenetére
Kösz a választ. Bootoláshoz betettem a random.trust_cpu=on kernelparamétert, de nem segített. Az első link szerint nem is csoda, mert ehhez a procinak kell támogatnia az RDRAND utasítást, az enyém (2. genes mobil Core i) nem támogatja.
Egyébként a gondot, ahogy nézem, nem is a kernel jelenti, hanem a systemd-random-seed.service. Ezt kéne kikapcsolnom valahogy.
-
Frawly
veterán
válasz haddent #28694 üzenetére
Igen, írtam is a legelső vonatkozó hozzászólásomban, hogy ezt próbáltam először. Látszólag le is tiltja, nem ír semmi hibaüzenetet, de aztán reboot után pofátlanul továbbra is ott virít ez a futó random seed service, és dicsekszik, hogy 9 mp-cel hosszabbította meg a bootot. Valahogy mindig visszamászik, hiába tiltom le
-
haddent
addikt
válasz Frawly #28695 üzenetére
Hát én letiltani tudok segíteni, csak aztán, hogy mi lesz nem tudom, fogalmam nincs kapásból ez mit csinál
De
systemctl status systemd-random-seed
-del nézd meg, hogy hol a .service, pl nálam:... Loaded: loaded (/usr/lib/systemd/system/systemd-random-seed.service ...
És konkrétan töröld ki (backup után) Vagy kommentezd ki az ExecStart -ot és rakj be egy echot a helyére vagy valamit
-
-
Fecogame
veterán
válasz Fecogame #28680 üzenetére
Megoldva
apt install msmtp msmtp-mta mailutils
nano /etc/msmtprc
account default
tls on
auth on
host smtp.gmail.com
port 587
user user@gmail.com
from user@gmail.com
password xxxxxxxxxxxxxxxxxx #https://myaccount.google.com/apppasswords
Innentől pedig már a szokásos mail paranccsal is megy az email küldés 2factoros auth-al védett email címről is.Lassú a mobilinterneted? 4G/LTE antennák, közvetlenül raktárról ---> http://bit.ly/LTE_Antennak
-
inf3rno
nagyúr
Mik a most divatos minimalista asztali disztrók. A minimalistát úgy értem, hogy nincs minden hülyeség előtelepítve. Rémlik valami, hogy van egy tök jó hasonló elvek alapján megírt, mint az Alpine szerveren, de totál elfelejtettem a nevét.
Buliban hasznos! =]
Új hozzászólás Aktív témák
Hirdetés
- Baba-Apa topic
- Ukrajnai háború
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Mikrokontrollerek Arduino környezetben (programozás, építés, tippek)
- Autós topik látogatók beszélgetős, offolós topikja
- Milyen videókártyát?
- Fejhallgató erősítő és DAC topik
- VR topik (Oculus Rift, stb.)
- Itt az új LOGOUT!
- Konzolokról KULTURÁLT módon
- További aktív témák...
- EREDETI - CHOICE - BUNDLE - STEAM KULCSOK - UPDATE!
- Office Professional Plus 2013, 2016, 2019, 2021 RETAIL licenckulcsok - MEGA Akció!
- AMD Game Bundle: Warhammer 40,000: Space Marine 2 és Unknown 9: Awakening - kaparintsd meg már most!
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Dobozos PC Játékok jó áron eladók
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen