Sziasztok!

sajt kerdezte:
: van egy slackware Linux amin fut egy ftp server. Hol tudnam megnezni,
: hogy kik leptek be, mit toltottek le stb.

Megnezed az ftp-szerver doksijat (/usr/doc/... ill. man-page), hogy 
general-e logfile-t. Ha igen, szerencsed van, ha nem, be kell lo"no:d
a syslogd nevu demont, ill. a /etc/syslog.conf file-t. Itt mindenkepp
nezd meg a man syslog.conf -t, mert ahany oprendszer, annyi syslogd.

Altalaban valami ilyesmit kell beirnod a syslog.conf-ba:
user.debug            /var/adm/logfile 
daemon.debug          /var/dam/another_logfile

A helyet altalaban tabulatorokkal kell kitolteni, es nem szokozzel.
Ez minden letezo dolgot loggolni fog, nem csak ftp-zest. Ha tul soknak 
talalod, a debug opciot lecserelheted a notice-ra, stb. Esetleg nezd meg, 
hogy a linux tamogatja-e az 
ftp.debug             /var/adm/logfile 
megoldast.

A syslogd valamelyik /etc/rc.d/rc.akarmi file-bol indul (ha nem torolted 
ki, gyarilag el is indul), es az /etc/servicesben is benne kell lennie a 
kovetkezo sornak (elvileg benne is van):
syslog               514/udp

Udv,
marky a germanhonba szakadt neme[s|csek] - 

On  4 Mar 98 at 4:02,  > wrote:

> Kedves Emberek!
> 
> Meg tudnatok mondani, hogy mi a kulonbseg, hogy mondjuk egy 64kB-os
> tombot a stack-en hasznalok, vagy malloc-al foglalom le a heap-en?

A stack-en gyorsabb, viszont azt a puffert nem tudod kiadni a rutin 
futasa utan, csak a rutinban, vagy az altala hivottakban 
hasznalhatod.

Van valami olyasmi dolog is, ha jol emlekszem, hogy az NT-ben a 
virtualis memoria allokalas ugy megy, hogy a stack szamara 
lefoglalt hely (ez linkelesi parameter) alatt van egy guard page, 
amit ha valaki eler, akkor noveli meg a stack szamara fenntartott 
helyet. Ha viszont kapasbol 4k-nal nagyobb helyet foglalsz le, akkor 
atleped a guard page-et, es befurdik a dolog. Ez ellen a 
forditoporgram azt csinalja, hogy ha a lokalis valtozok merete tul 
nagy, akkor azokat kisebb (4k-s) lepesekben foglalja le, igy mindig 
hozzafer a guard laphoz, es a stack virtualis meretenek a novelese 
gond nelkul megy. Kicsit maceras igy a dolog (ugy ertem, lassabb, 
nem latsz belole egyebkent semmit).

Linuxban nem tudok ilyenrol, szoval ez ott nem problema.

Istvßn
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --

> > Nem birod :) fread() egy ciklusban, es kesz.
Szerintem, ha irsz magadnak egy kicsi fuggvenyt, ami egy menetben X pos byte-ra
 meghivja a rendszer idevago szolgaltatasat, azzal rengeteg proci-idot megsporo
lsz, ti. elmarad a ciklusban ohatatlanul X-szer meghivott fread() /parameter ci
mek a stackba, vezerlesatadas.../ tobb szaz utasitasa. Ha egy menetben csinalod
, egyszer van fuggvenyhivas es visszateres. Meggondolando, foleg, ha eroteljese
n alkalmazott modulba kerul.

> Meg tudnatok mondani, hogy mi a kulonbseg, hogy mondjuk egy 64kB-os
> tombot a stack-en hasznalok, vagy malloc-al foglalom le a heap-en?
> 
> mondjuk
> 
> main() {char buffer[0x10000]; ...
> 
> vagy
> 
> main() {char *buffer; buffer=(char*)malloc(0x10000);
> 
> Melyiket szeressem???
Szerintem a heap-et szeresd, a stack-et amugy is sok egyeb minden terheli.
Apropo! Bizti az, hogy az elso kodreszlet a stack-ben foglal neki helyet???

Kedves Emberek!

Egy programot ket valtozatban irtam meg es time-al nezegettem a futasi 
idejet. Az derult ki, hogy az elso inkabb a user time-ban sok es a 
sys-ben kevesebb, a masodik kicsit gyorsabb es az user kevesebb, de a 
sys valamivel tobb lett. 

Melyiknek oruljek jobban???

Az okot tudom. Az egyiket streamio-val csinaltam, a masiknal jo nagy 
bufferek-kel es read/write-al, igy inkabb a kernel hivasokban toltotte 
a draga idejet.

TIA && udv From:, a hibernalt

Kedves Emberek!

Megirtam eletem nagy pogromjat. tarview nevre hallgat. Egy tar file-ban
ki lehet listazni a bent ucsorgo file neveit es/vagy a tartalmat az
stdout-ra. Ha gzip-pelt, akkor kitomoriti menet kozben. Tobbek kozolt
arra is hasznalhato, hogy CGI-ben archivalt html-eket ki lehet lokni a
netcapa-ba.

Ha valakit erdekel, akkor elkuldhetem. Eszreveteleket szivesen varnek!
Nem mondom, hogy tokeletes, de nalam egesz jol mukodik!

HP-UX-ra keszult. a v0.1.1b verzional tart ;-)

TIA && udv From:, az al-koto

# Minden eronkkel tamogassuk azokat akik keresik az igazsagot...
# ... es menekuljunk azok elol, aki megtalaltak! /Vaclav Havel/

Kedves Emberek!

Honnan lehet hozzajutni egy kis infohoz ez ugyben? Elolvastam a 
tar(4)-et, ami leirja, hogy hogyan is nez ki a fej blokk. Arrol viszont 
nem szol, hogy a fejlec is egy 512 Byte-os blokkot foglal el. Ha 0 a 
file merete, akkor nincs utanna adat. Egyebkent a file 512-re van 
kerekitve. A vegen egy csomo 0-val fel van toltve a file, hogy az 
alapban 20 lapot (20*512 byte) (es ennek tobbszoroset) kitoltse. 

Viszont erdekes modon ebben a feltoltesben is van 0-tol kulonbozo
adat. Az mit keres ott??? Csak hulladek?? Ket file kozott lehet ilyen 
hulladek blokk, vagy nem???

TIA && udv From:, a kopirnyo

Hello!

Kis program eseteben nagyjabol mindegy, hogy melyiket hasznalod. Azonban
altalaban nem szep dolog tul nagy stack-valtozokat hasznalni: a malloc()-nal
menet kozben lehet valtoztatni a meretet a realloc()-kal, meg lehet szuntetni,
ha mar nem kell, emellett a stack-en levo valtozoknal konnyebben elofordulhat,
hogy olyan felulirasi hibat kovetsz el, ami eszrevetlen marad, nem jar memory
fault-tal. Meg egy hatrany az, hogy a malloc()-kal letrehozott tombot a letreho
zo
fuggveny visszaadhatja, lokalis valtozora mutato pointer-t azonban nem, az
ervenytelen lesz a fuggvenybol torteno kilepes utan. DOS-ban termeszetesen nem
lehet 64K-nal nagyobb stack szegmenst hasznalni, tehat az elso modszer
elmeletileg portolhatosagi problemat is jelent.      

Szanto Tamas
MOL Rt.

Sziasztok!

Lenne egy kis problemam: BP 7.00-val irok egy menuzo programot. Az
egyszeruseg kedveert az egavga.bgi-t hasznalom a grafikahoz.
Hogyha valamilyen programot az exec-el meghivok, nincs eleg memoria
neki. Ha pedig azt alkalmazom, amit a help javasol ( {$M $4000,0,0} ),
akkor nem hajlando az egavga.bgi-t betolteni. Ti mit javasoltok?

Gyongyosi Peter