Ismét meghalt a magyar ubuntu/debian tároló

Ubuntu Linux

Egy ideje nem elérhető a magyar Ubuntu felhasználóknak a(z) hu.archive.ubuntu.com.
Tud valaki valamit, hogy mi történt?

  • 5680 megtekintés

( ulysses v | 2011. 03. 20., v – 22:33 )

Az ftp.fsn.hu-n van ha jól tudom, elég gyakran haldoklik mostanában... A FSN.hu oldalon pedig semmi információt nem találni róla.

http://www.fsn.hu/articles/projektjeink/index.html
http://www.fsn.hu/articles/mivel_foglalkozunk/index.html
http://www.fsn.hu/articles/az_fsn_alapitvany/index.html
http://www.fsn.hu/articles/elerhetosegein/index.html

Ahhoz képest, hogy nem most kezdték, nem kapkodják el az oldal feltöltését tartalommal.

( zitev v | 2011. 03. 20., v – 23:17 )

mintha a debian is csatlakozott volna...
(ftp.hu.debian.org)

( procika v | 2011. 03. 20., v – 23:49 )

Lassan hetek óta nem jó, minden gépemet átállítottam a fő tárolókra. Mint minden, gondolom ennek az üzemeltetése is pénzbe kerül valakinek, de ha nem beszélnek róla akkor senki nem fogja megtudni mi a probléma és miben lehetne a segítségükre.

( Tyra3l | 2011. 03. 21., h – 00:53 )

hasznaljatok masik mirrort, az fsn-es halott/haldoklik. :(

Tyrael

( bikmakk | 2011. 03. 21., h – 01:05 )

Időtlen idők óta a német tárolókat használom (korábban Ubuntum volt, még akkoriban áttértem, most Debian van, már eleve). Sosem volt panasz rájuk.

( Aadaam v | 2011. 03. 21., h – 01:11 )

Ahelyett, hogy itt sirtok, valaki irna valamelyik FSN-es csokanak?

Nagyon nem vagyok otthon a hazai free software korokben, Hunger vagy timar vagy bra vagy valaki ilyes figura nem dolgozik arrafele?

Trey esetleg ismerheti oket?

Nem erdekel, szegyen-e vagy sem, valszeg eszrevettek.

Azt szeretnem, de remelem tompos mar megvalaszolta, hogy valaki alljon ide, mondja el mi a baj,

Ha nincs idejuk, esetleg csinalunk belole egy hirt ha kellene nekik ember, vagy forumtopicot, nem hiszem hogy barki ellenezne, hogy kirakjunk valamit, hogy "figyu, az FSN-nek most nem teglara, hanem sysadmin helpre lenne szuksege" - a portal meg teli van sysadminokkal.

Íme: vasárnap lerohadt a gép, reset sajnos nem segített rajta. Távolról sajnos ennyi lehetőség van.
Szerencsére van munkám, így ma csak kb. fél egyre tudtam bemenni a géphez (munkaidőben, mehettem volna este is). Két órányi szopás után 15 óra körül indult el.
Sok olyan sysadmin van a portálon, akiben annyira megbízol, hogy géptermi hozzáférést intézz neki (fizikai hozzáféréssel) egy olyan géphez, amelyről nem lenne szerencsés, ha valami kompromittált bináris kerülne ki, és hajlandó vasárnap, éjszaka, vagy munkaidő közepén a helyszínre utazni, és órákat eltölteni a javítással?
Mindezt ingyen persze.

Én kérek elnézést. :)

# dig @dnsserver ftp.hu.debian.org

; <<>> DiG 9.7.2-P3 <<>> @dnsserver ftp.hu.debian.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16399
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;ftp.hu.debian.org.             IN      A

;; ANSWER SECTION:
ftp.hu.debian.org.      3600    IN      CNAME   ftp.fsn.hu.
ftp.fsn.hu.             14400   IN      CNAME   ftp.freepark.org.
ftp.freepark.org.       0       IN      A       195.228.252.133

;; AUTHORITY SECTION:
freepark.org.           14397   IN      NS      ns.ntech.hu.
freepark.org.           14397   IN      NS      ns.fsn.hu.

;; Query time: 676 msec
;; SERVER: dnsserver#53(dnsserver)
;; WHEN: Mon Mar 21 16:22:00 2011
;; MSG SIZE  rcvd: 142

miert jo a 0 erteku TTL az "ftp.freepark.org" cimre? igy a dns szerverem nem tudja berakni cache-be a cimet es minden lekeres 100x annyi ideig tart mint kellene...

udv Zoli

Szia,

Lassan hetek óta nem jó

Lehet, hogy a kollega tulzott; tobben is azt jeleztek, a problema nem egyedi, es nem mostani; erre reagaltam. Nyilvan nem elvaras a 0.99 meg a 24 oran belul, de a "hetek" egy picit erosnek tunt.

Sz'tem 5-ot siman talalsz egyebkent ilyen emberbol itt.

Nyilvan egyebkent orulunk, hogy egyaltalan van aki csinalja, es nagyon szepen koszoni minden ubuntu/debian/ilyen-olyan modon fsn felhasznalo.

Mondjuk - minden tisztelet mellett - ha nem egy ember csinalna akkor nyugodtabb lennek - elmesz nyaralni / szoposabb munkahet van / beteg a gyerek oszt nincs debian repo egy hetig...

"megbízol, hogy géptermi hozzáférést intézz neki (fizikai hozzáféréssel) egy olyan géphez, amelyről nem lenne szerencsés, ha valami kompromittált bináris kerülne ki"

Ezzel nem teljes mertekben ertek egyet.

A felhasznalonak nem benned kell megbiznia, ezert van kulcsos hitelesites a csomagokhoz es egyeb kiadott dolgokhoz, nem?

Persze nyilvan nem szerencses az sem, ha egy mirror kompromittalodik, de azert nem ugyanaz, mintha a mirror forrasa kerul cikibe.

tompos

ezt nem tudom, csak tippeltem: tekintve hogy szakmailag nagyon keves embert ismersz el, es ez a csoport nagyban korrelal a sajat haveri korodhoz, ezert felteteleztem, hogy igen.
persze lehet hogy most ot csak azert emelted piedesztalra, hogy a tobbi hup-os olvaso szakertelmet pocskondiazhatsz ("öt bra-kaliberű ember a hupon, akiket még érdekel is ez a bohóckodás?")
de szerintem atment a mondanivalom. :)

Tyrael

mi az hogy kliens php-k?
meg hogy errefele?
sejtem hogy most meg szerettel volna alazni, de kicsit lehetnel bobeszedubb. :P
altalanossagban elmondhato, hogy a teljes rendszer biztonsaga == a rendszert alkoto reszegysegek leggyengebb elemenek a biztonsagaval.
http://www.schneier.com/blog/archives/2005/12/weakest_link_se.html

Tyrael

ahogy erzed :)
ps: probaltam rakeresni az idezetre, de ugy tunik hogy nem sikerult pontosan masolnod.
tippem szerint erre gondolsz:
http://hup.hu/node/89202#comment-1057149
ezzel kapcsolatban a mai napig fenttartom, hogy felelotlenseg a szuksegesnel magasabb prioritasokkal futtatni egy szolgaltatast, csak azert mert elmeletileg a masik szolgaltatas meg tudja vedeni.
kiveve amikor nem, pl. http://www.securityfocus.com/bid/40399 illetve a kernel bugok ellen nem tud/akar a jail vedeni.

Jails are a lightweight form of virtualization/containment premised on a shared kernel across protection domains--this means that a kernel vulnerability may allow access between protection domains. If your environment requires you to tolerate a kernel vulnerability, then you will need a non-kernel based virtualization system. Note that a very similar kind of reasoning applies to using hypervisors (such as Xen, VirtualBox, VMWare, etc) and vulnerabilities they might have: if you need to be able to tolerate a hypervisor vulnerability and maintain protection between two machines, then you can't use a hypervisor to keep them separate.

Tyrael

Tekintve, hogy (csakúgy mint a "case-sensitive" HFS+-t), úgy már az általad idézett CVE-2010-2022-t se olvastad el, továbbra sem lep meg hogy fogalom nélkül idézgeted a kezed ügyébe akadó google találatokat :) ("In the default FreeBSD jail configuration, it is not possible to break out of jails with this vulnerability")

Természetesen mindössze ennyi az elvárható, elvégre linuxot használsz.

a tortenelmi attekintesre nem reagalnek, ha nem gond.

a lenyeget nem akarod megerteni(amugy szerintem erted, csak nem akarod beismerni hogy a jailes dicsekvesed kapcsan butasagot irtal): a jail, ahogy minden nem trivialis szoftver tartalmaz hibakat, eppen ezert vakon hinni benne, hogy "dehat az megved mindentol" meg azt hajtogatni hogy "root-kent futtatom, mert freebsd-n ezt is megtehetem" eleg nagy butasag, plane amikor mar lattunk ra peldat, hogy talaltak sebezhetoseget a jailben, es a kernelben is.
http://en.wikipedia.org/wiki/Principle_of_least_privilege
ha nem kell neki root, akkor ne rootkent fusson.

Tyrael

terelsz. :)
elolvastam a linket mielott kuldtem, te viszont meg mindig nem tudtad elolvasni es vagy ertelmezni az en irasomat:

ezzel kapcsolatban a mai napig fenttartom, hogy felelotlenseg a szuksegesnel magasabb prioritasokkal futtatni egy szolgaltatast, csak azert mert elmeletileg a masik szolgaltatas meg tudja vedeni.
kiveve amikor nem, pl. http://www.securityfocus.com/bid/40399 illetve a kernel bugok ellen nem tud/akar a jail vedeni.

letezo jail bug amit linkeltem? igen
amennyiben kihasznalhato akkor ki lehet maszni a jailbol? igen
javitotta a freebsd csapat? igen

ha lett volna ennel konyebben kihasznalhato jail sechol az elmult 1-2 evbol, akkor azt linkeltem volna, de leven hogy nem volt, igy ezt linkeltem.

amit csinalsz, az mar csak tereles, raadasul magadhoz kepest eleg gyenge.

Tyrael

már vagy harmadszor idézed, és még mindig nem olvastad el /o\

The jail(8) utility does not change the current working directory while
imprisoning. The current working directory can be accessed by its
descendants.

Ez mitől jail-breaking sechole? ;)

mondjuk linuxot használsz, szóval érthető hogy nem érted az egybefüggő leírt szöveget :(

meg mindig nem olvastad el a CVE-t. /o\
http://security.freebsd.org/advisories/FreeBSD-SA-10:04.jail.asc

The jail(8) utility does not change the current working directory while
imprisoning. The current working directory can be accessed by its
descendants.

By default, the FreeBSD /etc/rc.d/jail script, which can be enabled
using the jail_* rc.conf(5) variables, is not affected by this issue.
This is due to the default jail flags ("-l -U root") used to start a
jail as these flags will result in jail(8) performing a chdir(2) call.
If the rc.conf(5) variables jail_flags or jail__flags has been
set, and do not include '-l -U root', the jails are affected by the
vulnerability.

a jail nem valtott konyvtarat, ami nem volt gaz a default init scripttel, mert az ugy inditotta a jailt, hogy megtortent a konyvtarvaltas.
ha nem valt konyvtarat a jail, akkor az aktualis konyvtaron keresztul ki tud traverzalni a jailbol a tamado.

idezek a mitre.org-rol, hatha ugy konyebben megerted:

jail.c in jail in FreeBSD 8.0 and 8.1-PRERELEASE, when the "-l -U root" options are omitted, does not properly restrict access to the current working directory, which might allow local users to read, modify, or create arbitrary files via standard filesystem operations.

maga a hiba sulyos, de a kihasznalas eselye nem tul nagy, mivel valoszinuleg kevesen hasznalnak/tak custom init scriptet.
ettol fuggetlenul biztonsagi res, es szepen fixelte is a vendor.

Tyrael

Akkor már csak azt kell végre megértened, hogy e hiba szempontjából teljesen mindegy, hogy a jailen belül hány root-ként futó processz van, ami ellen oly' lelkesen próbálsz ezzel kardoskodni :) Meg mondjuk azt is, hogy nem "custom init script" használatáról van szó, hacsak az rc.conf időközben nem lett azzá kinevezve valahogy /o\

Megnyugtatásul közlöm, hogy linuxostól ez a tudás nem elvárható.

akkor lassan, utoljara, hogy te is megertsd. :)

Akkor már csak azt kell végre megértened, hogy e hiba szempontjából teljesen mindegy, hogy a jailen belül hány root-ként futó processz van, ami ellen oly' lelkesen próbálsz ezzel kardoskodni

e hiba szempontjabol valoban mindegy, de azt hittem, hogy ezen mar tulleptunk, leirtam hogy csak azt volt hivatott bemutatni, hogy a jail sem hibatlan, es minel tobb jogosultsaga van (feleslegesen) a jailben a usernek, annal valoszinubb, hogy tudja exploitolni a sebezhetoseget amivel kimaszik a jailbol(ez ugyanigy van nem jail kornyezetben is).

Meg mondjuk azt is, hogy nem "custom init script" használatáról van szó, hacsak az rc.conf időközben nem lett azzá kinevezve valahogy /o\

ne mond mar, hogy az /etc/rc.d/jail az nem init script?
valoban a jail_* rc.conf -bol olvassa a configjat, de ettol meg init scriptrol beszelunk.
ha a "gyari" init scriptet, illetve configot hasznalod, es nem krealtal jail_flags or jail__flags valtozot, vagy csinaltal, de tartalmazza a '-l -U root' argumentumokat, akkor nem vagy sebezheto.
de ha osszetaknyoltal magadnak egy init scriptet, ami nem adja at ezeket a parametereket a jail-nek, vagy eppen "rosszul" adtad meg a jail flageket a gyari init scripthez tartozo configban, akkor rabasztal.

Tyrael

mar megint csak a tereles, meg a maszatolas.

tényleg, egész eddig csak azért verted magad hogy "megmutasd": semmi se hibátlan? és ezzel kinek mondtál újat, captain obvious?

neked:

- Volt, hogy egy root joggal futó php-met nyomták fel, még a shutdown-t is próbálták linuxos aggyal paraméterezni, természetesen sikertelenül, dehát freebsd jail-ben ez egyébként is így járás ;)
linuxon mindez elég szomorúan végződött volna. Lehet ezért nem használom?..

- miert kellett root-tal futnia btw?

- Hogy érezzem hogy freebsd-n ezt is megtehetem ;))

nem futtatunk root-tal szolgaltatast, ha nincs ra szuksege.

"osszetaknyoltal magadnak egy init scriptet" /o\

en hasznalnam a gyarit, de nehanyan csinaljak
http://www.google.hu/#sclient=psy&hl=hu&q=freebsd+jail+init+OR+startup+…

mondjuk az látszik soha életedben nem csináltál jailt

valoban nem csinaltam, de a hozzaszolasaink alapjan nem latszik rajtad a gyakorlatbol fakado tudaskulonbseg :/

Tyrael

Tehát életedben nem láttál ilyet (konkrétan ezt meg pláne), délelőtt még azt hitted hogy egy jail paramétereihez shell scriptet kell módosítani, de azért levonod a konzekvenciát hogy szerinted értesz hozzá (!), ahogy a case-sensitivity-hez, meg egyéb dolgokhoz is. Ahha. A királyi többes használata meg látom már régóta jól megy, alkalmazd is bőszen, komolyan sokkal jobban hangzanak tőle a magas igazságtartalmú okfejtéseid o/

de buta vagy. :)

Tehát életedben nem láttál ilyet (konkrétan ezt meg pláne),

http://hup.hu/node/59810#comment-624034

délelőtt még azt hitted hogy egy jail paramétereihez shell scriptet kell módosítani,

legfeljebb te voltal ertetlen :)

ahogy a case-sensitivity-hez, meg egyéb dolgokhoz is.

mar megint a tortenelem. :)
ez itt kb. annyira relevans, mint hogy a felugyelted alatt a novara hanyszor allt meg, vagy nyomtak fel.

Ahha. A királyi többes használata meg látom már régóta jól megy, alkalmazd is bőszen, komolyan sokkal jobban hangzanak tőle a magas igazságtartalmú okfejtéseid o/

neked is megvan a sajat stilusod, nekem is, en is ~ toleralom a jo izles hatarain belul a tiedet, szerintem neked is menni fog, de ha nem, akkor ignoralj nyugodtan.

Tyrael

de relevans, ha kapcsolodik a targyhoz.
az hogy egyszer ordas faszsagot mondtam nem garantalja, hogy mindig tevedni fogok.
hiszen te is tevedtel mar, es megsem dolt ossze a vilag.
ezert, ha be akarod bizonyitani, hogy konkretan itt es most tevedek, akkor abbol kell dolgoznod, amit itt es most leirtam.
nem amit multkor egy masik topicban, vagy amit te belelatni veltel az egyik hozzaszolasomba.

Tyrael

félreérted, nem azt garantálja hogy tévedni fogsz, hanem azt, hogy más témában is nyugodt szívvel fogsz 0 tájékozottsággal annyi marhaságot annyit pofázni (a te olvasatodban: teorizálás), hogy az egész komment sáv két pixel lesz.

mindig ketton all a vasar.
mivel te inditottad kettonk kozul ezt a beszelgetest, ezert ezzel a hozzaszolasommal pont ugyanannyi postot izzadtunk ki mindketten.
az hogy 0 tajekozottsaggal annyi marhasagot pofaztam ebben a szalban, az meg bizonyitasra var a reszedrol. :)

Tyrael

( freeoli v | 2011. 03. 21., h – 09:23 )

Sajnos már rég gond van vele :(

Szurkolok a megoldáshoz, mert a cím a telepítő készletekben és sok telepített rendszerben is ez van beállítva és erre nincs felkészítve a csomagkezelő.

OFF: Upgradelték seed és openrelay szerverré.

( uid_2783 | 2011. 03. 24., cs – 17:06 )

[fintorgó on]
"Egy ideje nem elérhető..."

emlékét kegyelettel megőrizzük....
[fintorgó off]

--
Aspire_3690 & bP_10.1.1
"amióta esténként kikapcsolom a mobilomat, utolérhetetlen vagyok az ágyban." - ismeretlen szerző