MEJLA77: co udela 'echo -e "GET / HTTP/1.0\n\n" | nc mejla.cz 80'?

AQUARIUS: hledal jsem radu ještě v auditku o ubuntu a odvozených distribucích, ping mi radili, pak ještě traceroute, výsledky jsou tady:

traceroute -T -p80 mejla.cz

traceroute to mejla.cz (94.142.233.94), 30 hops max, 60 byte packets
1 192.168.66.6 (192.168.66.6) 13.561 ms 13.540 ms *
2 * * *
3 * * *
4 * * *
5 * * *
6 * 10.32.0.5 (10.32.0.5) 31.151 ms 32.812 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 isp3.internetsystem.cz (94.142.233.94) 33.131 ms 31.921 ms 35.079 ms


ping mejla.cz:

64 bytes from isp3.internetsystem.cz (94.142.233.94): icmp_req=51 ttl=51 time=13.2 ms
- tohle to jede pořád, jen jsou tam na konci různé časy, od cca 11 do 30 ms, většina pod 20 ms

nevím co je dig :( vím jen, že to asi provedl network-manager, nějak zakázal tu moji adresu, dostanu se na ftp, vidím všechny ostatní weby kromě svého, všichni ostatní můj web vidí...


aktuálně můj etc/hosts vypadá takhle:


# The following lines are desirable for IPv6 capable hosts



192.168.66.11 mejla # Added by NetworkManager
127.0.0.1 localhost.localdomain localhost
::1 mejla localhost6.localdomain6 localhost6
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

MEJLA77: radky, ktery jsou zakomentovany (zacinaji znakem #) posilat nemusis, ty se ignorujou. ADMIX radil dobre, zkus ping, dig, tcptraceroute...

v etc/host/deny je jen tohle:

# /etc/hosts.deny: list of hosts that are _not_ allowed to access the system.
# See the manual pages hosts_access(5) and hosts_options(5).
#
# Example: ALL: some.host.name, .some.domain
# ALL EXCEPT in.fingerd: other.host.name, .other.domain
#
# If you're going to protect the portmapper use the name "portmap" for the
# daemon name. Remember that you can only use the keyword "ALL" and IP
# addresses (NOT host or domain names) for the portmapper, as well as for
# rpc.mountd (the NFS mount daemon). See portmap(8) and rpc.mountd(8)
# for further information.
#
# The PARANOID wildcard matches any host whose name does not match its
# address.
#
# You may wish to enable this to ensure any programs that don't
# validate looked up hostnames still leave understandable logs. In past
# versions of Debian this has been the default.
# ALL: PARANOID

MEJLA77: dej sem vypis i /etc/host.deny - omezeni pristupu se dela spis tady

MEJLA77: hosts jsou v pohode, co ping, dig/host, neco v iptables?

ADMIX: dostanu se na ftp pomocí gnome commander, vidím všechny možné jiné stránky, ale pokud se chci podívat na moji - www.mejla.cz, tak mi to napíše, že stránka není dostupná :(

MEJLA77: muzes definovat "zablokoval pristup"? :)

prosím pomoc, network manager mi zablokoval přístup na moje stránky (www.mejla.cz v ubuntu 10.10), našel jsem, že mám editovat /etc/hosts - odmazal jsem řádky, kde byly informace o mé doméně, ale stejně mi to nejede :( všichni ostatní ji vidí a já vidím všechny ostatní stránky kromě své :( děkuji předem za rady.)

aktuálně můj etc/hosts vypadá takhle:




# The following lines are desirable for IPv6 capable hosts



192.168.66.11 mejla # Added by NetworkManager
127.0.0.1 localhost.localdomain localhost
::1 mejla localhost6.localdomain6 localhost6
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Coming Soon: A Faster Firefox for Linux Users | PCWorld Business Center
http://www.pcworld.com/businesscenter/article/226847/coming_soon_a_faster_firefox_for_linux_users.html

8-)

ted jsem nasel prima directivu u find a pomoci ni to budu pravdepodobne delat -daystart

KOC256, AQUARIUS: koukám, že v nemoci jedno špatně napsaný slovo se se mnou veze až dodnes :) mažu tím samozřejmě nejen logy, ale především zálohy a díky malýmu disku mi jej třetí den záloh kompletně ucpává :) některý servery naštěstí čeká přesun na virtuál, takže tam se to vyřeší "samo" :)

WIL_M: nechces praci s logama poresit pomoci logrotate? Tim byses mohl vyhnout takovejmhle konstrukcim a fungovalo by to deterministicky...

WIL_M:
cekal jsme konkretnejsi cislo :)

ty soubory vznikaji v nejake konkretnim case a mazou se az kdyz presne vyhovi podmince mazani...

BTW: je vazne takovy problem ty logy tam mit o den dele? :)

KOC256: mazání spouštím v rámci zálohovacího skriptu, na jeho konci. očividně to budu muset naplánovat v cronu na pozdější čas, ale to se mi moc nechce...

WIL_M:
jak pise PUPU... v kolik poustis to mazani?

PUPU, KOC256: pravidlo tam právě není, občas zůstanou dva, občas tři dny, ale hádám, že ten čas modifikace tam bude hrát roli, jak mi říkáte.

viz právě příklad toho, že se nesmazal třetí den, kdy běžel o půl hodiny déle než následující dva, což bude asi kámen úrazu.

-rw-r--r-- 1 root root 6398101 dub 28 03:37 20110428-mail.txt
-rw-r--r-- 1 root root 6382662 dub 29 02:57 20110429-mail.txt
-rw-r--r-- 1 root root 6401934 dub 30 02:59 20110430-mail.txt

WIL_M:
no jestli tam je jasne pravislo ze se to maze po trech a ne po dvou dnech asi bych se dukladne zamyslel jak se vyhodnoti ta podminka vuci konkretnimu datumu vs konkreztni dobe spusteni vs jkonkretnimu vztahu mezi presnym casem kdy to mazes a kdy byl log vytvoreny... jestli me chapes...

WIL_M: a pocitas 'dny' skutecne jako 24 hodin? tj pokud ten prikaz pustis o pulnoci a soubor je modifikovany v pul ctvrte, pak se pochopitelne nesmaze

KOC256:
-rw-r--r-- 1 root root 6398101 dub 28 03:37 20110428-mail.txt

maže se mi to až po třech, místo dvou dnech, což je ještě divnější :)

[root@cent ~]# lsof | grep 20110428-mail.txt
[root@cent ~]#

WIL_M:
jake ty soubory maji atributy? jsou OK? nejsou lockle?