Re: [linux-admin] cara memperbaiki cd install linux yg rusak
On 2003.10.29_14:07:31_+, [EMAIL PROTECTED] wrote: > download saja iso-nya di www.linuxiso.org > kalo download rate-nya kencang, kalo gak, cari di penampungan deh, paling > berapa duit. > ide lain adalah download rpm yang rusak, copy cd yang rusak yang filenya masih dapat dibaca, lalu write lagi. aga susah kalau format cd-nya bootable. btw, penampungan apa neh? apa jasa yang menyediakan download dengan sejumlah uang? -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] bisa ggak satu jaringan ada 2 router yg sama
On 2003.10.27_04:42:35_+, [EMAIL PROTECTED] wrote: > kalau di linux mau diset dua router ipnya sama sih fine - fine saja, yang > sudah duluan up dengan ip tsb, dialah yang bisa berkomunikasi dengan host > yang satu subnet. Yang up belakangan, tidak akan mampu berkomunikasi, jadi > diem dan membatu (: ga juga. kalau router yang belakangan up dengan ip yang sama, tapi ketika komputer user broadcast arp untuk mengetahui siapa pemilik ip tersebut, dan yang membalas adalah router yang terakhir up, maka router pertama yang giliran kaga dipake. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] vconvert problem
On 2003.10.29_14:55:32_+, adi wrote: > Jadi, pada prinsipnya kita sudah sepakat bahwa istilah directory > hashing bisa dipakai :-)) sorry, no. teknik yang dipakai vpopmail untuk membagi-bagi user ke dalam direktori menurut saya, tidak dapat disebut directory hashing. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] vconvert problem
On 2003.10.24_12:57:19_+, adi wrote: > On Thu, Oct 23, 2003 at 08:29:20PM +0700, H. D. Lee wrote: > > tidak, Anda benar. aplikasi vpopmail mempergunakan teknik hash cdb untuk > > mengakses user info, secara default. > > ini tidak ada hubungannya dengan directory hashing yang dilakukan > vpopmail. > balasan saya adalah untuk statement Anda yang ini: "hmm.. kenapa di kepala saya selalu berpikiran kalau vpopmail menerapkan hash-nya DJB :-)" > > teknik yang dipakai vpopmail tidak dapat dinamakan directory hashing. > > soal istilah, ok lah. saya ingin tahu kalau menurut anda yang disebut > 'directory hashing' itu yang seperti apa? btw, nampaknya pembuat > vpopmail menggunakan istilah yang sama dengan saya: > > http://www.inter7.com/vpopmail/vpopmail-new.html > >Directory hashing 1. istilah yang Anda gunakan pertama kali bukan directory hashing, tapi hash berdasarkan user name. 2. saya telah menulis email kepada author vpopmail kbo@ mengenai hal ini, walaupun tidak mendapatkan balasan yang jelas tentang perubahan yang akan dilakukan, yang bersangkutan tidak memberi- kan jawaban yang negatif juga. directory hashing, dapat diterangkan dengan lebih jelas dengan contoh: ~vpopmail/domains/your.domain/a/d/adi -> homedir untuk Maildir user adi atau bahkan ~vpopmail/domains/your.domain/a/adi -> homedir adi ~vpopmail/domains/your.domain/l/lee -> homedir lee teknik di atas menerapkan hashing sederhana untuk mencari informasi di mana lokasi di mana homedir adi berada, misalnya akses ke fungsi yang bersangkutan menggunakan argumen 'adi', maka akan mengembalikan string 'a/d', misalnya. tentu saja banyak teknik hashing lainnya yang dapat dipergunakan, yang gunanya mencari / mengakses data dengan lebih cepat. tidak harus dengan dibagi berdasarkan huruf depan user. teknik yang dipergunakan vpopmail untuk direktori akan membuat user homedir di direktori 1 sebanyak x, lalu pindah ke direktori 2, create user sebanyak x, lalu pindah ke direktori 3, dst. ada beberapa level kedalaman user direktori yang akan dibuat. tapi perhatikan bahwa tidak ada cara untuk mengakses kembali di (sub)*direktori mana homedir user berada. lalu bagaimana cara vpopmail mengakses fullpath di mana letak homedir user? memakai teknik hash cdb dalam file vpasswd.cdb. perlu diperhatikan, di mana pun lokasi homedir, tidak mempengaruhi akses data ini, karena sekali data ini ditemukan dengan hash cdb, data homedir user telah didapatkan. akses ke homedir user kemudian dapat terjadi secara langsung. bila (sub)*direktori di mana user homedir berada dapat diakses melalui suatu cara, sehingga user 'lee' dapat langsung diketahui berada di '1' (untuk contoh yang tidak mempergunakan huruf depan user), maka teknik ini dapat dikatakan hashing. tapi kenyataan data ini tidak dapat diakses kembali melalui kata kuncinya (username), hanya melalui vpasswd.cdb, yang kenyataannya adalah hash dengan teknik cdb. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Qmail Bugs
memberikan solusi atas masalah saya. > upss sorry, kurang nol he..he.. > > 1000 per menit = 60 * 24 = 144 ~ 150 ok. > > that's the point. ketika kebutuhan bertambah, single system dapat > > memenuhi kebutuhan, and more. patch ini diperlukan kalau kebutuhan > > tinggi, tapi menggunakan satu sistem. > > itu meminimalkan risiko. anda akan paham kalau anda bekerja > untuk ISP. 1000 per menit itu kira-kira 16 msgs/s. kemungkinan sekali lagi Anda mengasumsi tentang latar belakang saya. > besar bottleneck adalah disk dan bandwidth. Tapi gini, point > saya: jangan mulai dulu dengan patch! lakukan dengan apa adanya, > kalau kurang baru dipatch. berapa load MTA anda sehari? anda > pakai patch ini? jangan salah paham, saya juga akan mengambil pendekatan seperti Anda. tapi pernyataan bahwa patch ini useless, tidak valid. arsip mailing list qmail membuktikan untuk Anda. > > btw, apa yang Anda maksud dengan "red"? setau saya sih komentar > > redaksi.. > > benar :-) Anda sepertinya tidak mengerti fungsi dari "red." -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] vconvert problem
On 2003.10.23_10:42:57_+, adi wrote:
> hmm.. kenapa di kepala saya selalu berpikiran kalau vpopmail
> menerapkan hash-nya DJB :-) benar saya keliru, directory hashing
tidak, Anda benar. aplikasi vpopmail mempergunakan teknik hash cdb untuk
mengakses user info, secara default.
teknik yang dipakai vpopmail tidak dapat dinamakan directory hashing.
bila jumlah user dalam satu directory sudah lebih dari x, maka user
berikutnya akan diberikan homedir ~vpopmail/1/{y,z} dan seterusnya.
vpopmail sama sekali tidak menggunakan 1,2 dan seterusnya sebagai kata
kunci untuk mengetahui di mana lokasi homedir user, sehingga tidak
dapat dikatakan sebagai teknik hashing.
--
H. D. Lee
--
Berhenti langganan: [EMAIL PROTECTED]
Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] vconvert problem
On 2003.10.23_09:29:02_+, Ronny Haryanto wrote: > > benar. jika ini argumen, tunjukkan di mana saya mengatakannya. > > Lama2 kok jadi kayak personal sih ya? Mari kita jaga diskusi supaya > tetap objektif. hanya suatu usaha untuk memperjelas diskusi. jika terdapat statement saya yang menyinggung hash, maka menunjukkan kalimat yang bersangkutan membuat saya dapat melakukan koreksi atas statement saya. > > membagi-bagi user ke dalam direktori tidak sama dengan membuat hash. > > Sebetulnya yang dimaksud membuat hash di sini yang bagaimana ya? Kok > kalo dari pengertian saya, practically membagi2 user ke dalam direktori > itu sebetulnya adalah salah satu aplikasi membuat hash. Mohon saya > dikoreksi (dengan penjelasan) kalo salah. hash adalah sebuah format data tabel seperti array, yang perbedaannya terletak pada cara aksesnya, yaitu dengan menggunakan sebuah kata kunci, bukan index, seperti array. vpopmail membagi-bagi user ke dalam direktori yang berbeda, dan dibatasi sekian user dalam satu direktori. ketika aplikasi vpopmail akan mengakses password atau homedir dari suatu user, maka digunakan password file yang telah dihash, bernama vpasswd.cdb. cdb adalah format data hash yang dibuat oleh DJB. file plain text dari vpasswd.cdb adalah vpasswd, yang formatnya hampir seperti /etc/passwd; field-fieldnya dipisahkan dengan : (titik dua), salah satu field-nya adalah homedir. tidak peduli bagaimana pun vpopmail membagi user ke dalam direktori, tidak akan mempengaruhi kecepatan akses vpopmail ke informasi user tersebut. yang mempengaruhi adalah teknik akses yang digunakan: cdb (hash), sql (mysql, postgresql, dll.) vpopmail tidak menggunakan kata kunci direktori satu alphanumeric seperti 1, 2, dst, untuk mengakses dengan cepat direktori homedir user. tujuan pembagian user ke dalam direktori oleh vpopmail adalah untuk mempercepat akses ke direktori dalam filesystem tertentu, di mana kalau sudah ada lebih dari sekian entri, akan terasa lambatnya. semoga membantu. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] mirrordir
On 2003.10.20_17:12:38_+, [EMAIL PROTECTED] wrote: > > Ada saran dari rekan2x.? atau ada program lain yang lebih simple untuk > > melakukan mirror dari ftp.? > rsync. > rsync tidak dapat digunakan untuk mirror dari ftp. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] vconvert problem
On 2003.10.21_03:47:37_+, adi wrote: > vpopmail tidak membuat hash berdasar username. praktisnya, benar. jika ini argumen, tunjukkan di mana saya mengatakannya. membagi-bagi user ke dalam direktori tidak sama dengan membuat hash. > dengan vpopmail kita bisa membuat username (local part) > dengan 1 huruf. di vpopmail.c, function vadduser: if ( strlen(username) == 1 ) return(VA_ILLEGAL_USERNAME); percobaan lain: $ sudo ./vadduser [EMAIL PROTECTED] abc Error: Illegal username -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Qmail Bugs
On 2003.10.21_03:09:22_+, adi wrote: > wah .. ini agak panjang. bisa dibicarakan di thread baru kalau > mau :-) penjelesan sederhana gini saja, coba lihat patch yang disediakan > matthias. komentar saya: dengan patch ini qmail justru nampak lebih > culun :P pasalnya mail delivery failed bisa terjadi pada fase > sesudah itu, dan patch itu tidak bisa apa-apa :-)) 'scheduler' > pada mailer modular dilakukan oleh agent lain, dengan mencoba > semua MX untuk semua tempfail bisa problematik. bayangkan saja > gini: hotmail punya 10 MX, 1 MX kalau diretry bisa menghabiskan > 10 menitan, kalau 10 MX berarti 100 menit! kalau concurrencyremote > dibatasi 20 dan worst case banyak kirim ke hotmail, maka qmail, > kalau dicoba semua untuk mentaati postulat di atas, bisa menjadi > mailer telo. ingat yang mengatur concurrencyremote adalah qmail-send. > jadi minimal qmail-send harus support semacam preemtive scheduling. > mungkin ada solusinya (bapak-bapak pembuat MTA pasti > lebih tahu) tapi yang jelas tidak dengan one liner patch :-) > perilaku qmail yang sekarang pun sebenarnya masih acceptable. bukankah mta non-modular juga memiliki masalah yang sama: harus mencoba semua MX, dan akibatnya mengalami delay yang sama? sorry for being dense, tapi saya mulai dapat melihat maksud Anda. qmail tidak mempunyai fasilitas ini bukan karena perilakunya masih acceptable. Posting DS point 3.2. > > qmail menolak DSN karena alasan simplicity, reliability dan security. > > takutnya hanya karena point ini motto qmail menyimpang. patch > > kalo pengen pake fitur ini. bagi yang lain, ketahuilah bahwa code yang > > tidak perlu tidak terdapat dalam qmail, dan tidur dengan lebih nyenyak. > > sepertinya bukan. eh? any URL for reference? > philip haezel, DJB, wietse merasa spec untuk > DSN ini problematik, sehingga enggan untuk mengaplikasikannya. reliablity, security. > setidaknya dapat prioritas yang sangat rendah. lagi pula, > implementasi DSN mensyaratkan *semua* 'hop' yang dilalui harus > support DSN. kira-kira: sudah capek-capek bikin eh .. masih > kagak bisa juga. mendingan kagak usah ditulis sekalian :-) simplicity, reliability. > > dengan mengesampingkan kemudahan instalasi qmail+ezmlm(-idx), terdapat > > banyaknya synchronous writes per mail pada qmail disengajakan untuk > > memberikan reliability yang digaransi oleh qmail. > > hei .. postfix dengan satu file tapi tetap reliabel :-)) > hati-hati menggunakan istilah synchronous write di linux. > kecuali courier-mta, tidak ada satupun MTA yang menerapkan > synchronous write seperti yang dipostulatkan linus (dengan > mount async). courier pun kalau tidak salah ingat menyediakan > ini saat compile time. lagi-lagi salah paham. ini bukan tentang hubungan satu file vs. banyak file terhadap reliability. tapi bagaimana upaya qmail untuk memberikan reliability. lagipula, tidak ada yang menggunakan istilah synchronous write di "linux". > > bandingkan juga dengan benchmark yang diberikan pada jawaban DS. > > itu karena monotori pakai default as is :-) postfix bisa diset supaya > lebih strightforward seperti qmail kalau mau. dari sini bisa dilihat > bahwa qmail kalah dalam fleksibilitas. tapi sekali lagi MTA ditulis > untuk memecahkan masalah tertentu saja. pada dasarnya benchmark dapat dibuat untuk menampilkan hasil sesuai dengan keinginan pembuat benchmark. > 1000 msg/menit ~ 15000/hari pada titik itu, bottleneck-nya sudah > di concurrencyremote. note: jangan dikacaukan dengan milis (ezmlm) > dengan ezmlm hanya ada 1 msg untuk lebih dari satu destination. boleh dijelaskan dari mana angka-angka ini? saya tidak mengerti, apa maksud 1000 msg/menit ~ 15000/hari pada titik itu. > kalau di Indonesia, sulit. sepintas saya lihat ISP menerapkan > setup 'mahal' karena legacy dari setup sebelumnya. Dengan qmail, > rate segitu (tanpa patch) bisa dilakukan dengan komputer dengan > ram 64MB :-) that's the point. ketika kebutuhan bertambah, single system dapat memenuhi kebutuhan, and more. patch ini diperlukan kalau kebutuhan tinggi, tapi menggunakan satu sistem. > dalam batas tertentu, saya masih percaya pada skalabilitas > horisontal. lakukan dengan beberapa komputer kecil-kecil. > dengan demikian, sekaligus diperoleh redundancy (kalau sudah > ada lebih dari 1 komputer, patch tsb. useless, red). kebutuhan redundancy berbeda untuk setiap orang. kebanyakan orang memakai single system. malah kadang banyak service dalam satu sistem. yang ingin saya sampaikan bahwa patch ini tidaklah tanpa fungsi, sehingga setiap kali sindrom ini muncul, solusinya adalah setup lebih dari satu komputer versi LVS. btw, apa yang Anda maksud dengan "red"? setau saya sih komentar redaksi.. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] vpopmail auth mysql
On 2003.10.21_10:57:29_+, [EMAIL PROTECTED] wrote: > Saya instal qmail beserta vpopmail. Saya menggunakan autentifikasi mysql. > Saat ini sudah berjalan dengan baik. Tetapi socket mysql yang digunakan > adalah /var/run/mysql/mysql.sock. Saya mau rubah default socket mysql ke > /tmp/mysql.sock. Tetapi vpopmail tidak mau konek ke mysql. Nah, gimana cara > rubah settingan socket mysql di vpopmail? Thanks .. > coba koneksi ke mysql dari command line. vpopmail tidak melakukan koneksi lewat socket, tapi melalui jaringan TCP/IP. > -= andy =- -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Qmail Bugs
sisi qmail tidak menyelesaikan masalah berupa > admin ceroboh. betul, tidak semua masalah dapat diselesaikan dengan cara teknis. > 4.8. jangan dipatch, mending bikin farm dan handle incoming > connections dengan beberapa mesin kecil-kecil. bisa > pakai LVS. linux rocks! YMMV, tapi komputer kencang sekarang cukup membuat repot qmail tanpa patch ini. pemakai yang beruntung punya komputer, bandwith dan semuanya kencang, pertimbangkan patch ini. tahap lebih tinggi lagi, pake clustering dan redundancy solution. seperti saran di atas. > 4.9. no comment. i am no hacker. debat mengenai ini ada di arsip milis qmail. website qmail.org, recommended patches, layak dikonsultasi untuk yang ingin install qmail. > 5. EGP ga mesti audit kok. bisa aja kejadian kebetulan nemu security problem, dapat hadiah 500. not bad.. opensource developer nemuin dan perbaikin bugs (security and non security related) just for hobby, atau gaji yang jauh lebih kecil per bugs yang jauh lebih banyak. > 6. Silakan ditambah sendiri. 6.1. Yang penting simpel. Achievable, yes. 6.2. kalo pake prinsip ini, introduce more problem than solving it. kalo masalah kecil yang ada distandarkan, bugs tidak ada yang fix. yang ada cuma bloated code bagi yang toleransi, dan bugs yang hidup selamanya... > Artikel matthias ini tidak terlalu buruk kan? :-))) Biarkan pembaca menilai. Menurut saya: misleading, bugs qmail tidak sebanyak ini. yang ada juga tidak sepenting yang diiklankan. masih tidak terdapat lubang di qmail. mulai dari point 4-5, adalah shortcoming, bukan bugs. point 6 adalah wishlist. > Happy qmailling. Sure, you too. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] vconvert problem
On 2003.10.16_01:04:57_+, Eksploit Mlempem wrote: > saya menggunakan vconvert bawaan vpopmail untuk > mengkonversi user dari /etc/passwd > jumlah user saya ada 500 lebih > setelah saya konversi, kok home direktori user > berbeda-beda ya? ada yang di > /home/vpopmail/domain/abc.com/user langsung, trus ada > yang /home/vpopmail/domain/abc.com/0/ > /home/vpopmail/domain/abc.com/1/ > /home/vpopmail/domain/abc.com/2/ > dst > pada UNIX dengan filesystem tertentu, ada kelemahan di mana jika jumlah entri dalam suatu direktori melebihi jumlah tertentu, maka akan memperlambat akses. vpopmail membagi-bagi users ke dalam direktori yang lebih kecil, untuk mengatasi problem ini. hal ini juga menimbulkan pro dan kontra. kontranya, admin tidak dapat membuat email address dengan username satu karakter. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] ms exchange vs qmail
On 2003.10.17_11:31:03_+, Edi Mulfitra wrote: > Bisa nggak account dari microsoft exchange diterus dahulu > memakai qmail baru ke user. apa ga kebalik nih? jadi user mengakses qmail untuk mengambil mail? kebanyakan orang menggunakan qmail sebagai mail gateway, baik untuk send ke luar, maupun untuk terima mail, dan diteruskan ke mail server internal. salah satu kelebihannya: security. > Kalau bisa bagaimana cara setting nya di qmail bisa, buat domain tertentu mx record dns-nya point ke server exchange. lalu dari exchange relay ke qmail server. di qmail server, setiap mail yang ingin diterima oleh server didaftarkan di control/rcpthosts. selanjutnya, buat metode deliverynya di control/virtualdomains. but then, kenapa memakai exchange? -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Qmail Bugs
bahas soal > sikap, motivasi lebih baik minta saja dibuatkan milis linux-sikap, > linux-motivasi, atau untuk di atas linux-salah-tempat :-) memang tidak ada. tapi kalo ngotot, ada kaitannya. saya jelaskan lagi: MA bilang cara DJB salah. DJB dan DS membalas bahwa cara mereka begini. Ada lubang dalam cara itu? Ya, dokumentasi, menurut MA. Tapi menurut DJB dan DS, itu adalah tugas admin, dengan memaparkan contoh tentang resource usage di UNIX. terus, masih ada lubang? Ya, menurut MA, karena qmail tidak ikut Postfix way, dan tidak menerima pendapat orang lain. padahal, dari awal, lubang yang ditunjukkan itu adalah "kelalaian admin", bukan qmail. sudahkah Anda melihat hubungannya? sekali lagi, memang haknya MA untuk tetap publish informasi itu. dan itulah yang saya anggap membias. menurut DJB way, tidak ada lubang. tapi menurut MA sebaliknya, sampai difix sesuai kemauan MA. Sekarang yang tidak mengerti alasan dibuat dan desain qmail, kenapa harus melimpahkan kesalah pada qmail sendiri? > yang ditanyakan adalah artikel matthias, bukan debat matthias di > milis qmail, walaupun sebenarnya itu pun tidak bisa begitu saja > anda buat snapshot-nya seperti di atas. karena itu semua proses, > dengan diskusi orang bisa berubah, termasuk matthias, djb, saya, > anda. debat di milis qmail ada relevansinya dengan dokumen qmail-bugs. MA bilang: Hai DJB, anak Anda qmail seharusnya berpakaian dengan cara saya. DJB bilang: ia tampak perfect, dengan pakaian ala saya. Walaupun dengan semua itu, MA tetap bilang: sebelum Anda fix anak Anda untuk berpakaian seperti saya, atau Anda mencantumkan kenapa anak Anda harus berpakaian seperti Anda, saya akan publish terus dokumen ini. Itulah sebabnya Point 1.1, masih ada sampai sekarang... :) > ada 1 juta orang anda jelek-jelekan di seribu paragraf, saya tidak > perduli. asal, minimal ada 1 paragraf yang menyebutkan artikel > matthias mana yang salah :-) that's not the point. point saya adalah, saya mengemukakan pendapat saya, dan karena pendapat itu pro DS, maka kedengarannya menjelek-jelekkan MA. Pertanyaan saya jelas, bagaimana cara mengemukakan pendapat saya tanpa menjelek-jelekkan MA? Anda boleh pakai cara Anda, kemukakan pendapat Anda tanpa menjelek-jelekkan DS, DJB dan qmail? mungkin saya bisa belajar dari Anda? minimal? untung ada arsip. Baca kembali posting saya terdahulu, yang sempat saya singgung juga di mail ini. > ok kita sudahi saja ya membahas Si Matthias yang Malang. Kita > beralih langsung membahas artikel yang ditulisnya saja. Lebih > sip kayaknya. atau DS, DJB dan qmail yang malang? dari awal sudah. Point 1.1 adalah posisi kita, jika Anda masih juga belum sadar. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Qmail Bugs
On 2003.10.15_08:01:52_+, adi wrote: > kenapa anda tidak melihat sendiri saja ke source qmail, kmd: > > % grep -i limit * | less > > tidak ada keterangan bahwa qmail menyerahkan limitasi sistem pada > tools lain. kalau tidak disebutkan, artinya: 'Maaf Tuan, qmail hanya > untuk orang pinter'. versi persepsi Anda. Kenapa harus dikatakan secara explisit? Saya tau tidak ada salahnya dicantumkan tapi tidak ada salahnya juga tidak. Software DJB mengajarkan kepada saya, bahwa seorang admin harus berhati-hati terhadap penggunaan resource pada sistemnya. Mengharapkan bantuan setiap daemon untuk berfungsi sebagaimana mestinya dalam resource limit hanya ada dalam negeri impian. Postfix saja pernah... (sudah saya kemukakan dalam posting terdahulu) btw, orang yang bertanggungjawab atas sebuah MTA dengan domain yang reachable dari Internet, memang sebaiknya orang pintar: ngerti memakai komputer dan sadar akan kekurangannya, mengerti administrasi komputer, etika Internet, dsb. Tanpa pengetahuan itu, akan berbahaya bagi netizen yang lain.. > seperti yang saya bilang, saya kurang tertarik dengan cara > penyampaian, tetapi lebih tertarik pada apa yang disampaikan. > issue perlu melakukan limitasi, baik built-in maupun via tool > eksternal itu perlu. ini diakui oleh DJB. itu saja. memang. > perkara DJB menolak mengupdate dokumentasi di source, tetapi > memilih mencantumkan soal ini di homepage pribadinya. Itu > wewenang dan hak mutlak DJB. exactly my point. > demikian juga dengan matthias. issue yang disampaikannya > soal perlu melakukan limitasi memory sewaktu menjalankan > qmail-smtpd itu benar. soal bagaimana dia menyampaikan > itu bukan urusan saya, lagian saya tidak tertarik memikirkan > yang begituan :-) baca di posting saya yang lain... > barangkali tip dari saya: filter semua kata-kata > bug, hole, security dll. kemudian baca lagi artikel > matthias, kalau anda menemukan kesalahan, silakan > kemukakan argumentasi anda. kenyataannya memang > qmail-smtpd bisa menghabiskan memory komputer anda > K A L A U pemakaian memory tidak dibatasi dengan > setrlimit(2). > saya kurang setuju. mengabaikan suatu kata pasti menyembunyikan makna sebenarnya. kalau tentang resource memory yang dapat dihabiskan, saya setuju. solusi DJB dan WV beda. itu saja. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Secondary MX Discussion (was: ganti hardisk mail server)
On 2003.10.15_09:34:56_+, adi wrote: > keberatan orang (termasuk saya) terhadap pemakaian > secondary MX, bukan karena alasan design 'MX RR' itu > salah. tapi pada "... kompleksitas dari setup tidak sebanding dengan hasil yang didapat." --adi bagi saya tidak. sudahkan Anda melakukan survey, atau mempunyai data, tentang apa yang Anda maksud dengan orang di sini? saya yakin Anda tidak bermaksud "semua orang yang tidak memakai secondary MX"? which is my point, pada argumen tentang desain (priority MX) pasti ada gunanya: bisa saja berguna bagi sebagian, tapi tidak cukup bermanfaat untuk diharuskan, karena alasan yang beragam. dan saya telah menyatakan pendapat saya di dalamnya. dengan argumen itu, secara implisit maupun explisit, saya mengatakan bahwa desain MX record dengan priority itu tidak bermanfaat, bagi saya. saya merasa keuntungan yang didapat lebih besar tanpa secondary MX. arsip mailing list qmail juga sangat bermanfaat untuk topik ini, mungkin juga mailing list sendmail, postfix dan lainnya. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Qmail Bugs
On 2003.10.15_08:19:10_+, adi wrote: > On Tue, Oct 14, 2003 at 11:34:21PM +0700, H. D. Lee wrote: > > mestinya Anda juga lebih jeli, tidak kemakan oleh tipuan MA. Hanya > > dengan mencantumkan hal tersebut, tidak membuatnya netral. > > kenapa sih anda reseh mau mengurusi yang beginian? :-))) again, as if it is a bad thing... :) > saya tidak memihak qmail/postfix. tetapi lebih tertarik > pada issue yang disampaikan. idem. cuma bedanya Anda lebih tertarik kepada dokumen MA, dan posting DS lebih dapat saya terima. > saran mengupdate dokumentasi itu bagus juga. saya melihat tidak > ada ruginya kalau dilakukan. cuma DJB saja yang tau kenapa dokumentasi itu tidak/belum diupdate. hanya karena tidak diupdate, tidak membuat qmail tidak secure by design. > hi..hi.. enak aja! ya harus mau menerima domain astaga.com dong :-) arghh, sorry. but you haven't been clear in the previous mail. saya mengerti duduk permasalahannya sekarang. Bulan ini, terdapat diskusi mengenai masalah ini, di mailing list qmail. Saya harap yang berminat dapat mengambil keuntungan dari sana. [bencmark post left out, starting new thread soon..] > benar. tergantung pada problem yang mau dipecahkan. tapi, > seandainya suatu saat nanti anda tiap hari harus menghapus > ribuan junk dari queue qmail tiap hari, ingatlah saya :-)) saya kadang-kadang ngeri dengan orang yang dapat mengetahui, atau meramalkan kapasitas mail yang pernah, sedang, dan akan saya tangani... never, ever presume anything on the other end. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Qmail Bugs
On 2003.10.15_09:27:03_+, adi wrote: > On Tue, Oct 14, 2003 at 10:36:45PM +0700, H. D. Lee wrote: > > oh, tunjukkan di mana saya memaksa... > > baca artikel tulisan matthias. dan tunjukkan salahnya. > sederhana saja. dari kemarin anda terlalu sibuk mengurusi > soal sikap dan etika saja. menurut saya lebih cocok dibahas > di milis linux-etika atau linux-sopan-santun atau bahkan > linux-moral :-) > as if it is a bad thing... :) menurut hemat saya, posting DS cukup bermanfaat, maka saya posting URL tersebut ke mailing list, agar dapat dijadikan bahan pertimbangkan oleh pembaca, terutama OP. bukankah itu yang sejak awal saya lakukan, sebelum Anda masuk dan mengatakan bahwa saya seharusnya punya argumen sendiri? nah kalo begitu: 1. Anda dari awal sibuk sejak saya post URL yang berisi posting DS, yang menentang dokumen qmail-bugs. Seolah-olah pembaca tidak berhak judge sendiri mana yang benar, mana yang salah. Memang betul, saya juga mengutarakan pendapat saya. Dengan itu, saya kelihatan lebih pro ke qmail. Tapi itu sekaligus menjawab pernyataan Anda kemudian yang mengharapkan setiap orang punya argumen sendiri. Hilarious... Judge one thing dari dua pendapat yang berbeda, itu merupakan suatu pendapat juga bukan? Saya sudah memberikan argumen mengenai ini, pada posting saya yang terdahulu. Jika Anda menganggap saya sibuk melulu soal etika and nothing else, sebutkan istilah yang tepat untuk Anda: seorang yang ikut dalam diskusi etika. Kalau diskusi ini menurut Anda tentang etika tentunya, di mana menurut saya bukan. Lihat tanggal dan jam reply dari setiap argumen saya dan Anda. Siapa yang lebih sibuk? Apakah perlu saya tunjukkan, bahwa Anda terlalu sibuk untuk mengurusi masalah yang menurut Anda etika? 2. Jika Anda menganggap saya hanya mengurusi etika, baca kembali posting saya. MA memang bertindak salah dengan etikanya yang salah tempat, IMHO. Saya juga membeberkan alasan mengapa point-point dalam dokumen itu tidak berlaku lagi, karena alasan dari DJB tidak diterima. MA ngotot dan itu bagi saya tidak baik. Karena ngotot itulah mengapa point-point itu masih ada dalam qmail-bugs. Memang, itu haknya. Tapi memang juga hak DS dan lainnya meluruskan situasinya. Itu semua karena sikap dan etikanya. Apakah Anda dapat melihat hubungannya sekarang? Anda bilang, yang Anda pentingkan adalah isinya. Fine with me, biarkan pembaca menilai sendiri antara dokumen qmail-bugs oleh MA, dan posting argumen untuk dokumen qmail-bugs, oleh DS, dan resource lainnya. Sekali lagi, pembaca berhak mengetahui semua isi dari dokumen, posting dan resource yang bersangkutan, bukan? Setuju? Jika ya, kembali ke posting argumen Anda terhadap posting pertama saya dalam thread ini, dan tunjukkan siapa yang sibuk... -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Qmail Bugs
On 2003.10.14_12:29:43_+, adi wrote: > ini justru di-rujuk oleh Matthias. mestinya dengan ini anda > bisa koreksi diri sendiri. bahwa sebenarnya matthias tidak > menjalankan misi nge-flame/menjelek-jelekan qmail. mestinya Anda juga lebih jeli, tidak kemakan oleh tipuan MA. Hanya dengan mencantumkan hal tersebut, tidak membuatnya netral. pokok permasalahannya adalah perbedaan pendapat cara penanganan resource limit. dengan mencantumkan bahwa cara DS adalah workaround, dan ngotot bahwa fix-nya none, ini dapat menyesatkan. menurut DJB, itulah fix-nya. > bedakan antara 'menjelek-jelekan' dengan kritik yang logis. > baca dan dengar dulu pendapat orang baik-baik, baru mengambil > kesimpulan. setelah anda memiliki kesimpulan sendiri, baru > bandingkan dengan kesimpulan orang lain. bedakan juga antara kritik yang logis dengan tidak menerima perbedaan pendapat dan solusi. > validasi recipient mutlak diperlukan. gini saja. anda pernah > dengar domain astaga.com? saya bisa mengarahkan mx-nya ke mesin > anda. setelah itu, baru anda bisa melakukan restrukturisasi > terhadap argumen anda di atas. seperti yang saya bilang, mta > di design tidak untuk menjawab semua masalah. validasi mutlak? bisa diterangkan? saya tidak bisa melihat relevansi antara "ancaman" Anda dengan validasi recipient. Misalnya Anda benar-benar mengarahkannya, qmail akan complain: 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) > sudah jelas. saya bisa menunjukkan hasil benchmark > kurang lebih 5 menit. tapi kalau saya yang mengerjakan, > nanti dikira cheating. anda bisa membuktikannya sendiri. saya percaya Anda. deskripsikan bagaimana Anda melakukan benchmark yang dimaksud. Pembaca akan menilai apakah Anda fair atau tidak. > matthias sendiri punya benchmark soal ini. dan anda pun > pasti tidak tertarik. Mungkin yang lain tidak tertarik, but not me. But, but, sebuah MTA yang tidak punya catatan security vulnerabilities selama 5 tahun (as of 2003) cukup membuat saya stay with qmail, untuk sekarang ini. > stay calm and cool :-) don't worry, i live in a small cold town. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Qmail Bugs
On 2003.10.14_14:50:44_+, adi wrote: > sebenarnya yang diminta adalah: kalau kesalahan ada > di dokumentasi, perbaiki dokumentasinya. sekali lagi: menurut DJB system resource limit adalah tugas dari admin yang baik, caranya dengan menjalankan softlimit untuk melimitasi memory yang dapat dipakai oleh qmail. menurut WV, resource limit adalah tugas dari program yang menjalankan, sehingga admin tidak perlu lagi pusing-pusing. MA menginginkan DJB mengikuti cara Postfix. Ini jelas sekali, dikatakan bahwa DJB tidak pernah membayar $500 sebagai hadiah menemukan bug kepada WV. Desain DJB adalah simplicity, karena menurutnya resource limit yang built-in di satu program, akan menimbulkan masalah. terbukti Postfix pernah kecolongan sekali. Jangan memaksakan seorang mengupdate dokumentasi, seandainya hal itu tidak diakui sebagai bugs, karena memang dari awal desainnya mengalihkan tanggungjawab ke non built-in methods, yaitu metode eksternal. Saya ingin menunjukkan ini dengan hanya memberikan URL. Anda juga tidak memberikan pendapat, hanya kesimpulan. Saya ingin memberikan kebebasan kepada pembaca untuk menyimpulkan semuanya sendiri, dengan memberikan bahan perbandingan. At the end, I have to point out facts. > 'berseteru' (eh .. ada konon eric, djb dan wietse pernah > foto bersama di satu konferensi), yang terpenting adalah how nice. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Secondary MX Discussion (was: ganti hardisk mail server)
On 2003.10.14_15:01:42_+, adi wrote: > Itu komentar untuk pernyataan anda yang ini: > > Tidak setiap hal yang dirancang bermanfaat. Banyak RFC > yang obsolete, bahkan TCP/IP dirancang tidak dengan > security in mind. > Dan ini jawaban saya, seandainya Anda kelewatan: Yang ingin saya luruskan adalah: kegunaan suatu fitur hasil desain dari standard dan recommeded practice di Internet, tidaklah selalu mempunyai keuntungan yang signifikan untuk setiap orang. Memang dalam hal ini secondary MX tidak sama kasusnya seperti TCP/IP, tapi menjelaskan bahwa desain dapat saja salah, karena yang membuatnya tidak dapat men-cover semua aspek. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Qmail Bugs
On 2003.10.14_14:45:06_+, adi wrote: > tidak ada. saya setuju. tapi pertanyaannya jelas, bagaimana > pendapat dari anggota milis ini. bukan pendapat orang lain. > setiap orang mestinya punya pendapat sendiri-sendiri. tidak setuju. apakah saya harus perdebatkan dokumen qmail-bugs dengan cara saya sendiri? lalu kenapa Anda tidak kemukakan qmail-bugs versi Anda sendiri? Kadang antara dua hal kita bisa melihat baik buruknya, dan menyampaikan hal itu kepada orang lain, tanpa perlu memberikan pandangan kita sendiri. setiap hari mailing list dipenuhi pertanyaan yang dijawab dengan menunjukkan pembaca ke URL tertentu, atau dijawab oleh pembaca yang lebih tau, dari kenyataan, atau hasil bacaan orang lain. Bukan atas pendapat sendiri. Misalnya, iptables. Apakah perlu cari cara sendiri kalau mau jawab pertanyaan: bagaimana ngeblok port 80? oh mungkin saya mengerti sekarang. Saya punya pendapat sendiri: saya membaca dokumen qmail-bugs dan posting Dave, dan yang benar menurut hemat saya, adalah Dave. This is my opinion. > walaupun kemampuan baca sudah banyak menurun, tapi saya mengikuti > milis qmail dari hari ke hari :-) what are you trying to prove? > barangkali itu bedanya. kalau saran saya, jangan terpengaruh > dengan cara penyampaian orang lain, tapi konsentrasi saja pada > apa yang disampaikan. dengan begitu orang jadi (lebih) obyektif. > sadarkah anda kalau sebenarnya sekarangpun anda menjelek-jelekkan > orang? kalau benar bilang benar, kalau salah bilang salah. > matthias menyarankan agar bagi siapa saja yang menemukan kesalahan > pada yang dia tulis, silakan menghubunginya langsung dan memberikan > koreksi. maaf, jika nadanya terdengar begitu. tapi yang saya katakan adalah kenyataan. Anda sepertinya setuju dengan pendapat saya bahwa tindakan "M A" tidak tepat. Tapi Anda juga menyarankan agar setiap orang membiarkannya, karena pernyataan beliau benar. Salah tempat adalah suatu kesalahan. "M A" memang mengatakan begitu. Tapi ketika DJB mengatakan bahwa cara untuk menghindari memory exhaustion cara DJB adalah dengan softlimit, "M A" ngotot bahwa yang benar adalah Postfix way. Tapi "M A" ngotot, itu adalah bug qmail. lalu, bagaimana cara saya menyampaikan kenyatan di atas tanpa terdengar menjelek-jelekkan? -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Qmail Bugs
On 2003.10.14_14:53:46_+, adi wrote: > hi..hi.. pancingannya kurang pas kali ya .. :-) let's see. > kalau anda sekarang memaksa membuktikan russell, > kenapa anda tidak berusaha membuktikan bahwa matthias > salah. coba anda kunjungi lagi webnya dan baca baik-baik. oh, tunjukkan di mana saya memaksa... pak adi, sejak dari awal thread ini berlangsung adalah sbb: 1. diawali dengan posting bahwa dokumen qmail-bugs adalah dokumen yang menyatakan bahwa qmail itu banyak bugs. 2. saya sanggah, dengan memberikan URL dan posting mailing list, termasuk beberapa anggota milis yang memberikan informasi sejenis. 3. lalu Anda mengatakan bahwa sebaiknya saya punya argumen sendiri, jangan jiplak, hanya akan menimbulkan flame-war. Do I feed a flame war here? Meluruskan sesuatu dianggap flame war? Memberikan URL ke dokumen lain yang menentang dianggap flame war? 4. informasi yang saya berikan adalah untuk meluruskan bahwa dokumen tersebut salah. ini membuktikan bagaimana "M A". 5. anda menjelek2kan "R N", tanpa alasan tepat. Saya menyanggah, di posting ini. Apakah saya menjelek2 "M A"? Ya, karena beliau menggunakan sarana yang tidak tepat. Web itu tepat, menurut hemat saya, tapi saya juga boleh memberikan informasi kepada pembaca, agar dapat dijadikan bahan pertimbangan bukan? Tapi menggunakan sarana milis qmail? Sama sekali tidak tepat. Nah bila Anda tidak setuju dengan pendapat "R N" di kandangnya, proof it. Saya sudah tunjukkan bagaiman "M A" di posting saya yang lain, di dalam thread yang sama. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Qmail Bugs
On 2003.10.14_08:09:35_+, adi wrote: > orang ini konsultan qmail. hidupnya bergantung pada ketenaran > qmail :-))) kebanyakan qmail zealotz yang 'ngotot' di milis > qmail, hidupnya bergantung pada ketenaran qmail. jadi, 'berdebat' > dengan mereka akan menjadi never ending story. irrelevant. Russell Nelson mempunyai perusahaan bernama Crynwr, yang websitenya ada di http://www.crynwr.com. Dari sana dapat dilihat bahwa hidupnya tidak hanya tergantung dari ketenaran qmail. Saya tidak mempunyai ide bagaimana porsi konsultasi qmail berpengaruh dalam pendapatannya. But, buktikan bahwa Russell salah, jangan hanya memberikan kenyataan tanpa dasar. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Qmail Bugs
On 2003.10.14_07:53:17_+, adi wrote: > tertentu. Jadi yang paling penting bagi kita dalam memilih MTA > adalah: Masalah (seperti) apa yang hendak kita pecahkan? > Ok, sepertinya Anda sependapat dengan saya. Dan bagi desainer software, "M A" dan "V" tidak harus ngotot bahwa solusi qmail menghindari memory exhaustion dengan softlimit, tidak benar. Harus pake "Postfix" way. Padahal desainnya sendiri tidak konsisten, pernah kecolongan. Bukankah setiap orang punya cara dan hak punya solusi yang berbeda atas masalah yang sama? Saya tidak pakai Postfix untuk production, dan saya lebih tau qmail. Tapi saya tidak anti Postfix. Saya cuma merasa tindakan "M A" kurang tepat, dan membias. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Qmail Bugs
On 2003.10.14_07:53:17_+, adi wrote: > Orang ikutan milis biasanya untuk berdiskusi, bukan untuk > mendapat nasihat cari arsip :-) Kenyataannya, nasihat di atas Kenapa harus mengetik kembali text yang sudah ada di Internet? Mengapa Anda harus pakai Linux, BSD, qmail, postfix? Why don't reinvent the wheel? Internet digunakan untuk menyebarkan informasi. Apa salahnya point user ke informasi tersebut dari mailing list? > Alasannya? Baca thread yang saya tunjukkan, baca juga posting "M A" dalam mailing list qmail. RTFA. > MTA dibuat jelas tidak untuk memecahkan semua masalah. Mereka punya > design sendiri. Design tertentu dipilih untuk menjawab masalah > tertentu. Jadi yang paling penting bagi kita dalam memilih MTA > adalah: Masalah (seperti) apa yang hendak kita pecahkan? Setuju. Tapi taukah Anda "M A" masuk ke rumah orang lain lalu gembar gembor MTA favoritnya, lalu jelek2an pemakai MTA tuan rumah? Lalu mengemukakan alasan, bahwa ada orang menjelek2an Postfix di mailing list postfix, yang merupakan user qmail? Come on, orang yang menjelek2an postfix itu bahkan dianggap komunitas qmail sendiri adalah orang yang clueless, tidak tau bagaimana cara memasyarakatkan qmail, tapi "M A" berpendapat bahwa kekacauan ini harus dilakukan, sampai orang yang clueless tersebut tidak muncul lagi di mailing list postfix, yang saya yakin tidak akan ada habisnya dan akan muncul sekali waktu di mailing list postfix. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Secondary MX Discussion (was: ganti hardisk mail server)
On 2003.10.14_08:00:35_+, adi wrote: > kalau ini sudah keluar dari konteks. keberatan orang menggunakan > secondary mail server adalah pada kompleksitas dari setup > tidak sebanding dengan hasil yang didapat. Bisa dijelaskan apa yang keluar dari konteks? Menurut saya, setting secondary mail server is a snap, dan dapat menggunakan server low end, untuk mail server dengan load ringan tentunya. Setting mail server primary jauh lebih rumit. Bagi sebagian orang yang ikut dalam diskusi ini, queue mail oleh secondary mail server terasa lebih baik daripada mail server pengirim harus queue mail itu sendiri. Saya rasa keuntungan yang dikemukakan jauh lebih besar bagi mereka. Pilihan tergantung dari pemakai. Anda dapat memakainya jika diperlukan. Tapi saya telah mengemukakan kenapa saya tidak memakainya. Dan itu tidak out of contexts. Yang ingin saya luruskan adalah: kegunaan suatu fitur hasil desain dari standard dan recommeded practice di Internet, tidaklah selalu mempunyai keuntungan yang signifikan untuk setiap orang. Memang dalam hal ini secondary MX tidak sama kasusnya seperti TCP/IP, tapi menjelaskan bahwa desain dapat saja salah, karena yang membuatnya tidak dapat men-cover semua aspek. > sebenarnya masih ada kasus-kasus tertentu yang masih membutuhkan > secondary mailserver. seperti kasus yahoo yang down beberapa tahun > yang lalu. karena tidak memiliki secondary MX, begitu up mesin-mesin > mail yahoo dibombardir oleh MTA dari seluruh dunia, jadi langsung > down :-) dengan secondary mailserver, kita jadi lebih bisa mengontrol > concurrency ke primary mailserver. Agree, but I am not another Yahoo!, dan keuntungan yang diperoleh oleh mail server kelas menengah ke bawah, nihil dalam hal concurrency. Concurrency dari mail server penerima juga dapat diset sehingga pengirim tidak dapat melakukan delivery (seperti pada saat down), dan tetap mengambil keuntungan dengan menghindari false sense tersebut. YMMV, but kalo saya punya mail server sekaliber Yahoo!, saya juga tidak akan invest secondary mail server, tapi lebih kepada teknologi redundancy. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] ganti hardisk mail server
On 2003.10.13_01:13:36_+, Sharren Kandou wrote: > Kalo maintenancenya cuman sehari rasanya ngga perlu pikir-pikir bikin > secondary mail server. Betul, inilah yang saya perdebatkan dalam mail terdahulu. :) > Pada dasarnya mail server yang telah terkonfigurasi dengan benar memang > tidak memerlukan secondary mail server (MX2). Setuju. > Menurut saya tujuan dibuatnya secondary mail server itu hanya jika terjadi > masalah pada primary mail server (entah servernya, jaringannya, akibat > bencana alam dll) yang lebih dari queuelifetime mail server yang mengirim. > Ingat juga, tidak semua orang mengkonfigurasi mail servernya dengan > queuelifetime seminggu, mungkin ada alasan lain sehingga queuelifetimenya > diperpendek. Rasanya kita sependapat. Dengan catatan tambahan saya, bahwa secondary mail server tidak diperlukan, karena false sense yang dikemukakan pada mail pertama saya pada thread yang sama. Jika seorang memutuskan untuk memberikan queuelifetime yang lebih pendek untuk mailnya, maka saya rasa orang tersebut juga ingin tau bahwa mailnya tidak sampe ke recipient. Buat apa memberikan efek bahwa mail telah diterima oleh server, pengirim tidak menerima bounce apa-apa, padahal mail masih diqueue di secondary mail server? Bukankah lebih baik kalau mail temporary undeliverable di server pengirim? Mungkin dengan diperpendeknya queuelifetime, admin juga memutuskan untuk mengirimkan delivery notification kepada pengirim, sehingga informasi kegagalan pengiriman mail segera diketahui pengirim? Sebuah catatan, pada dasarnya jika pengirim mengetahui mail telah sampai ke tujuan, pengirim akan mengasumsi bahwa mail server tujuan akan menyampaikan mail ke recipient dengan benar. Dan recipient kemungkinan telah membaca mail yang dikirim. Mungkin Anda berpendapat bahwa: daripada tidak terima mail dari pengirim, saya lebih baik menerimanya, walaupun ga tau kapan bacanya. Atau tidak dibaca sama sekali. Ini bisa saja terjadi kalo queuelifetime secondary mail server juga udah terlampaui, alhasil, mail bounce setelah "queuelifetime secondary mail server" pengirim baru tau, kalau mail tidak diterima recipient. Duh.. > Pada Sendmail dan Postfix default queuelifetime nya 5 hari. Kalaupun mau > pake MX2 sebaiknya MX2 tsb berada di network/ISP/tempat lain, kalo > bersebelahan dengan MX1 nya buat apa? :) Baca argumen di atas. :) > CMIIW No one's wrong. Cuma perbedaan preference tentang penanganan mail. :) -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] ganti hardisk mail server
On 2003.10.13_10:17:51_+, Asfihani wrote: > Kalau kata "mail telah server yang dikonfigurasi dengan baik" maksud > anda mengacu pada default qmail yang menggunakan queulifetime 60480 > ya OK OK saja, tapi saya kira tidak semua server memakai qmail atau > memakai qmail dengan queuelifetime yang seabad itu :-) No, maksud saya adalah, mail server tersebut diset dengan queue mail yang temporary undeliverable, sesuai waktu yang ditentukan oleh policy perusahaan atau keinginan dari pengirim yang bersangkutan. Katakanlah sebuah perusahaan memutuskan bahwa queuelifetime "server yang telah dikonfigurasi dengan baik", sesuai policynya, adalah 2 jam. Kalau setelah, 2 jam mail tidak berhasil dideliver ke mail server recipient, saya memilih pengirim mengetahuinya, dengan mendapatkan bounce message. Tentunya selama itu, mail server pengirim akan terus mencoba, sesuai dengan waktu yang telah ditentukan oleh MTA, mengirim email yang sama kepada mail server tujuan. Pilihan Anda tentu saja boleh lain. Tapi alasan saya adalah: Perusahaan tersebut tentu mempunyai tujuan, menset mail server dengan queuelifetime 2 jam tersebut. Mungkin karena email yang dikirim oleh pengirimnya dianggap penting. Jika secondary mail server Anda menerima mail tersebut, dan tiga hari kemudian baru delivered ke primary mail, mungkin mail tersebut sudah 'basi'. Tidakkah lebih baik kalo pengirimnya tau, lalu mengambil jalan lain, misalnya menelepon ke pengirim? Kalau penting, saya rasa pengirim akan melakukannya. > Lha memang gunanya secondary MX begitu, agar email yang dikirim tidak > ngendon di server pengirim ya mendingan ditampung dulu di backup MX tsb > kemudian akan dideliver ke primary MX jika memang sudah aktif lagi, entah > dipaksa atau dengan internal scheduler masing-masing MTA. Dan menciptakan false sense yang dimaksud di reply saya di thread yang sama? > Selain itu, biasanya untuk mailserver yang sangat sibuk sehingga batas > concurancy tercapai, biasanya secondary MX dibuat tumpangan untuk > mendeliver email. Sama seperti di atas. Tambahan lagi, upgrade resource Anda, jika mail server Anda tidak dapat menangani mail Anda dengan baik. > Pastilah perancang DNS mempunyai tujuan mengapa RR untuk MX bisa dibuat > prioritas. Tidak setiap hal yang dirancang bermanfaat. Banyak RFC yang obsolete, bahkan TCP/IP dirancang tidak dengan security in mind. Mungkin bagi Anda ini bermanfaat, tapi saya memilih tidak memakainya. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] ganti hardisk mail server
> Kalau seandainya MX1 dan MX2 di beri prioritas yang sama di resource DNS > record, apakah "false sense" seperti yang diterangkan diatas berlaku juga ? Jika, MX1 dan MX2 share storage yang sama, via NFS atau sejenisnya, maka konfigurasi ini menghasilkan semacam round robin load balancing. Jika tidak share storage yang sama, pastikan user yang bersangkutan melakukan pop dari MX1 dan MX2. Kedua kondisi di atas mengambil asumsi bahwa MX2 adalah server yang juga melakukan delivery ke user mailbox (or Maildir, whatever). Sinkronisasi konfigurasi MX1 dan MX2 merupakan masalah tersendiri. Jika MX2 mempunyai smtproutes (asumsi qmail dipakai sebagai MTA), yang isinya: :[IP MX1] atau :nama MX1 atau dengan kata lain: 1. tidak melakukan delivery ke user mailbox 2. hanya sebagai penampungan sementara yang akan deliver mail ke MX1 secara langsung jika MX1 aktif, atau queue mail menunggu MX1 aktif maka jawabannya: Ya, false sense yang dimaksud masih berlaku, pada saat MX1 down. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Qmail Bugs
On 2003.10.11_13:48:21_+, Jimmy wrote: > Saya baca artikel di : > http://www-dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html > > Bug-nya qmail banyak banget yah ? Ada banyak perdebatan tentang ini di mailing list qmail. Cari di arsipnya untuk informasi lebih lanjut. Pada dasarnya bugs yang dikemukakan oleh Matthias Andre membias. Bila Anda membaca posting yang dilakukannya ke mailing list qmail, terasa sekali bahwa tujuannya bukan untuk membantu, tapi untuk mempromosikan postfix di mailing list qmail. Dan akibatnya, menjelek-jelekkan qmail. Suatu hal yang tidak sepatutnya dilakukan. Seorang yang bernama Dave Sill, penulis Life with qmail dan buku Qmail Handbook, memberikan jawaban atas dokumen ini. Sekali lagi, ini ada di arsip mailing list qmail: http://marc.theaimsgroup.com/?l=qmail&m=103116907221626 In summary, baca thread mengenai perdebatan tentang dokumen ini. Baca juga posting yang dilakukan oleh Matthias Andre yang lain. Dan selanjutnya terserah Anda, mau menganggap dokumen itu benar, atau mengambil pendekatan yang meniadakan "bugs" yang ada dengan cara yang benar, seperti yang didesain dari awal oleh Prof. Daniel J. Bernstein. Menurut saya sendiri, qmail dapat dibuat secure, asalkan mengikuti instruksi instalasi seperti di Life with qmail. "Bugs" lainnya yang diklaim merupakan kekurangan feature tertentu atau tidak "RFC compliant", sebagian merupakan desain yang disengajakan qmail untuk keuntungan tertentu (seperti security) dan dalam hal ini tidak benar-benar melanggar RFC, dan sebagian lainnya terbukti tidak benar. YMMV. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] ganti hardisk mail server
On 2003.10.09_09:52:22_+, Iwan Sulistyawan wrote: > Daripada diganti hardisk baru.. Mendingan hardisk barunya buat tambahan > aja... setuju. beberapa harddisk ukuran M, lebih baik daripada satu harddisk ukuran XL. untuk mail server yang sibuk, sangat disarankan. :) saran di bawah ini, menganggap harddisk lama tetap dipergunakan. > Terus pindahin directory mailbox atau vpopmailnya ke hardisk baru... > Jadi hardisk lama isinya qmail + OS, hardisk baru isinya vpopmail dan > mailbox user.. apabila load mail tinggi, bisa dipertimbangkan untuk memisahkan qmail, misalnya khusus /var/qmail/queue di harddisk yang lebih cepat, terpisah dari harddisk di mana partisinya dipergunakan untuk /var/qmail dan logging (/var?). > Tahap persiapan.. > 1. Siapin MX2 sementara MX1 nya mau di maintenance... Perpanjang queue > life timenya (seperlunya aja) default queuelifetime adalah 604800, atau seminggu, jauh lebih panjang dari waktu yang dibutuhkan untuk memasang harddisk dan melakukan maintenance... saya ingat di mailing list qmail pernah terjadi perdebatan mengenai penggunaan secondary mail server (menggunakan istilah di atas, MX2). pada dasarnya secondary mail server tidak diperlukan, karena mail server yang telah dikonfigurasi dengan baik akan mencoba melakukan queue terhadap mail yang servernya untuk sementara tidak dapat dijangkau. lebih dari itu, secondary mail server akan menciptakan semacam false sense, di mana mail server penerima yang tidak menerima mail sementara waktu, dianggap telah menerimanya. well, kalau tetap mau pake MX2, bisa menggunakan server yang light load untuk menampung mail sementara waktu, bila tidak dapat ditemukan mesin nganggur yang bisa dipakai. Karena pada dasarnya mail server ini sifatnya light load, dan sementara saja. YMMV. > 3. kalau bisa format hardisk baru di komputer linux lain. format dgn > file system yg mau dipake (misal ext2 atau ext3 or whatever). Ini untuk > mempersingkat downtime. Toolsnya pake fdisk, dan mkfs kang.. RTFM!!.. tidak diperlukan. harddisk dapat dipasang pada mail server yang production. nyalakan, pastikan hdnya kedetect, login, fdisk, bikin filesystemnya, lalu mount. > Tahap pelaksanaan > 1. matiin mail server, pasang hardisk barunya.. > 2. hidupin ke single user mode aja. tidak perlu. langsung ke multiuser. stop service qmail-send, dan pop3. qmail-smtpd boleh tetap nyala. keuntungannya, mail tetap dapat diterima, tapi akan diqueue. Tujuannya untuk mencegah modifikasi ke direktori pada user virtual domain saat mail user dipindahkan. persiapkan partisi, bikin filesystem, mount. pindahkan direktori /home/vpopmail (or whatever) ke partisi baru. unmount, dan mount kembali partisi yang bersangkutan ke /home/vpopmail. lakukan langkah yang sama untuk partisi lain. ingat jangan pindahkan /var/qmail/queue, karena akan membuat queue-nya rusak. start kembali service yang dimatikan di atas. lihat queue mulai dikosongkan, user bisa pop lagi, dan fungsi lainnya. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Ip loopback
On 2003.09.23_00:31:56_+, JaVas wrote: > to achieve the same result since the Hosts file on a Windows machine > resolves the friendly name localhost into the IP address 172.0.0.1. Finally, 127.0.0.1? > you can even ping any legal IP address of the form 127.x.y.z to test your > TCP/IP protocol stack. If this test produces an error, either your network > interface card (NIC) is incorrectly configured or your protocol stack is > corrupt. If the configuration looks correct, try removing and reinstalling > TCP/IP on your machine to fix the problem. If that fails, try reinstalling > the driver for your NIC or replacing the NIC Setidaknya di OpenBSD, ketika 127.x.y.z (selain 127.0.0.1) di-ping, akan menimbulkan pesan "network is unreachable", kecuali interface lo0 atau lo1 dikonfigurasi dengan alias yang bersangkutan. Bahkan, di RFC 990, disebutkan bahwa: The class A network number 127 is assigned the "loopback" function, that is, a datagram sent by a higher level protocol to a network 127 address should loop back inside the host. No datagram "sent" to a network 127 address should ever appear on any network anywhere. Perhatikan kata kunci "should", di mana artinya tidak mengikat, dan tidak ada keharusan untuk itu. CMIIW > > Regards, > > > Panji.M > -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] internet connection sharing
On 2003.09.23_02:47:30_+, hanny wijaya wrote: > client kasih ip mulai 10.10.0.2/255.255.255.0 > client arahkan gateway ke 10.10.0.1 > client set DNS ke 10.10.0.1 atau ip.dns.isp.anda > > isi DNS di rh 9.0 > /etc/resolve /etc/resolv.conf > nameserver ip.dns.isp.anda > > hidupkan service dns > /etc/rc.d/init.d/named start > hanya bila setting DNS dari client diarahkan ke 10.10.0.1, pastikan juga dibatasi akses hanya dari jaringan 10.10.0.0/24. > jalankan dan taruh di /etc/rc.local > /sbin/iptables -A POSTROUTING -t nat -s > 10.10.1.0/255.255.255.0 -d 0/0 -j MASQUERADE > > hehehe :)) oopss.. pastikan juga /proc/sys/net/ipv4/ip_forward isinya 1, alias nyala. :) bisa diset di /etc/sysctl.conf. pada distribusi redhat, ada option khusus di /etc/sysconfig/network yang dapat dipakai untuk menyalakan IP forwarding (FORWARD_IPV4). iptables juga dapat diaktifkan dengan service iptables (/etc/sysconfig/iptables). Terserah yang mana, TMTOWTDI. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] bingung blackbox
On 2003.09.23_09:52:49_+, Adhytia Wisnu Sasmita wrote: > Saya sedang nyoba x window blackbox... > seperti fluxbox ya ? mm... fluxbox yang seperti blackbox. tepatnya, fluxbox dikembangkan dengan dari blackbox. > CUma bingung ini kalau sebuah aplikasi di minimize...terus dia > menghilang, sementara panel dibawah nggak ada tanda apa-apa. > > terus kalau mau meng maximize nya lagi gimana ya caranya ? Coba lihat di menu Workspace, pada submenu Icons, terdapat aplikasi yang diminimasi. > Adhytia Wisnu Sasmita > -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] tanya default domain qmail
On 2003.09.23_15:14:53_+, Kurniadi wrote: > kalau pake vpopmail versi 2.3.25 keatas bisa di konfigurasi di > /home/vpopmail/etc/defaultdomain > baca deh http://www.pipeline.com.au/staff/mbowe/isp/webmail-server.htm Oops.. fitur ini ditambahkan oleh Tom Collins. Anda benar. Maaf atas kesalahan informasinya. Perlu diperhatikan bahwa versi 2.3.x adalah versi "development", walaupun pada umumnya cukup stabil, dan direkomendasikan oleh inter7. YMMV. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] ngasih izin mount ke user
On 2003.09.22_11:28:48_+, Royke K wrote: > /dev/hdc5 /mnt/data vfat defaults,umask=000 0 0 > Option defaults, secara 'default' berisi option 'nouser'. Menurut manual mount, nouser berarti user biasa (bukan root) tidak dapat melakukan mount terhadap filesystem yang bersangkutan. Sedangkan option umask dipergunakan untuk memberikan, err, umask :) terhadap filesystem yang akan dimount. Mungkin yang dimaksud adalah: /dev/hdc5 /mnt/data vfat defaults,users 0 0 Dalam hal ini option defaults selain nouser berlaku, ditambah dengan option users itu sendiri. > CMIIW > > Salam. > -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] Problem IPTABLES
On 2003.09.22_19:41:04_+, Albertus Andreas Eko Yoga wrote: > Skenarionya seperti ini, aku mau blok semau paket icmp > dari luar maupun dari dalam. jadi dari luar kagak isa di > ping/tracert, dari dalam juga gak isa ping/tracert ke > luar. > > Tapi Aku mau buat pengecualian buat komputer ip > 192.168.230.1 (dari dalam) dan localhost(si router) bisa > ngeping/tracert ke luar. > Untuk rules yang dimaksud, bisa coba baca IP-Masquerade-HOWTO. Sebagai tips, iptables mempunyai argumen "!" untuk sumber maupun tujuan, jadi !192.168.230.1, berarti: IP selain 192.168.230.1. Untuk localhost, asumsi IP 127.0.0.1, direkomendasikan untuk _tidak_ diblok paketnya. IP 127.0.0.1 ini tidak akan terlihat di jaringan, jadi yang di-allow hanya IP dari router yang bersangkutan. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
Re: [linux-admin] tanya default domain qmail
On 2003.09.19_14:13:37_+, Adi Gunawan wrote: > Mohon penjelasan, > bisakah mengganti default domain tanpa format atau compile ulang, > saya pake qmail-1.03, vpopmail,qmailadmin,courierimap, squirrelmail. Jika maksudnya default domain di vpopmail (--enable-default-domain=xxx), maka jawabannya: tidak. Jika untuk qmail, tidak ada yang namanya default domain, mungkin yang dimaksud adalah locals. > Terimakasih > Adi -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
