diff --git a/ja_JP.eucJP/articles/contributors/article.sgml b/ja_JP.eucJP/articles/contributors/article.sgml index 56196fdfb1..079349c0fb 100644 --- a/ja_JP.eucJP/articles/contributors/article.sgml +++ b/ja_JP.eucJP/articles/contributors/article.sgml @@ -1,7184 +1,7185 @@ %man; %ja-authors; %authors; ]>
FreeBSD への貢献者 $FreeBSD$ この文書は FreeBSD に貢献した個人や組織を列記したものです. 寄贈者ギャラリー FreeBSD プロジェクトは次の寄贈者に恩義を受けており, ここに公表して感謝の意を表したいと思います. セントラルサーバプロジェクトへの寄贈者: 次にあげる個人および企業からは, セントラルサーバマシンのための部品の寄贈を頂いており, それによって freefall.FreeBSD.org をリプレースして新たに FreeBSD プロジェクトのセントラルサーバマシンを 構築することができました. &a.mbarkah と彼の所属する Hemisphere Online は, Pentium Pro (P6) 200MHz CPU を寄贈してくださいました. ASA Computers は, Tyan 1662 マザーボード を寄贈してくださいました. ViaNet Communications の Joe McGuckin joe@via.net は, Kingston イーサネットコントローラ を寄贈してくださいました. Jack O'Neill jack@diamond.xtalwind.net は, NCR 53C875 SCSI コントローラカード を寄贈してくださいました. Alameda Networks の Ulf Zimmermann ulf@Alameda.net は, 128MB のメモリ, そして 4 GB のディスクドライブと匡体 を寄贈してくださいました. 直接的な資金提供 次にあげる個人および企業からは FreeBSD プロジェクトに対する直接的な 資金提供を頂いています. Annelise Anderson ANDRSN@HOOVER.STANFORD.EDU &a.dillon; Blue Mountain Arts Epilogue Technology Corporation &a.sef; Global Technology Associates, Inc Don Scott Wilde Gianmarco Giovannelli gmarco@masternet.it Josef C. Grosch joeg@truenorth.org Robert T. Morris &a.chuckr; Imaginary Landscape, LLC. の Kenneth P. Stox ken@stox.sa.enteract.com Dmitry S. Kohmanyuk dk@dog.farm.org 日本の Laser5 は, さまざまな種類の FreeBSD CD の販売利益の一部を 寄付してくれました. 蕗出版 は, はじめての FreeBSD の売り上げの一部を FreeBSD プロジェクト及び XFree86 プロジェクトへ寄付してくれました. アスキー は FreeBSD 関連の書籍の売り上げの一部を FreeBSD プロジェクトおよび FreeBSD 友の会へ寄付してくれました. 横河電機株式会社 からは FreeBSD プロジェクトへ多大な寄付をいただきました. BuffNET Pacific Solutions Siemens AG via Andre Albsmeier andre.albsmeier@mchp.siemens.de Chris Silva ras@interaccess.com ハードウェアの寄贈者 次にあげる個人および企業からは, テストやデバイスドライバの開発 / サポート のためのハードウェアの寄贈を頂いています. BSDi は, ネットワークへのアクセスおよび 他のハードウェアリソースの寄贈はいうまでもなく, 開発に使うための Pentium P5-90 と 486/DX2-66 EISA/VL のシステム数台を提供してくださいました. TRW Financial Sysytems 社は, PC 130台, 68 GB のファイルサーバ 3台, 12のイーサネット, ディスクレスコードのデバッグをおこなうための ルータ 2台及び ATM スイッチを提供してくださいました. また, 彼らは 2, 3人の FreeBSD ハッカーを雇って, FreeBSD に専念させてくださっております. ありがとうございます! Dermot McDonnell は, 東芝 XM3401B CD-ROM ドライブを 寄贈してくださいました. その CD-ROM ドライブは現在 freefall で使用されています. - &a.chuck; は, 実験用のフロッピーテープストリーマを + Chuck Robey chuckr@glue.umd.edu + は, 実験用のフロッピーテープストリーマを 寄付してくださいました. Larry Altneu larry@ALR.COM と &a.wilko;は, wt ドライバを改良するために Wangtek と Archive の QIC-02 テープドライブを提供してくださいました. Ernst Winter ewinter@lobo.muc.de は, このプロジェクトへ 2.88 MB のフロッピードライブを提供してくださいました. うまくいけば, これでフロッピーディスクドライバを書き直すための プレッシャーが増えるでしょう. Tekram Technologies は NCR ドライバや AMD ドライバと自社のカードの逆行テストのため FAST/ULTRA SCSI ホストアダプタ DC-390, DC-390U, DC-390F を 各１枚提供してくださいました. また, フリーな OS のためのドライバの ソースを自社の FTP サーバ ftp://ftp.tekram.com/scsi/FreeBSD/ で公開されていることも称賛に値するでしょう. Larry M. Augustin は Symbios Sym8751S SCSI カードを寄贈してくださっただけでなく, Ultra-2 や LVD をサポートする次期チップ Sym53c895 のものを含む データブックのセットと, 最新の Symbios SCSI チップが持つ先進的機能を安全に使う方法について書かれた 最新のプログラミングマニュアルも寄贈してくださいました. 本当にありがとうございます! Christoph Kukulies kuku@FreeBSD.org は, IDE CD-ROM ドライバ開発用の FX120 12 倍速 Mitsumi CD-ROM ドライブを提供してくださいました. 特筆すべき寄贈者 BSDi (かつての Walnut Creek CDROM)は, 言い表せないほど多くの寄付をしてくださいました (詳細は FreeBSD ハンドブックの FreeBSD 小史の章を見てください). 特に, 私たちのもともとのプライマリ開発マシンである freefall.FreeBSD.org, テストおよびビルドマシンである thud.FreeBSD.org で使用しているハードウェアに対し感謝したいと思います. また彼らには, 数年にわたる色々な貢献者への資金提供や, インターネットへの T1 コネクションの無制限使用を提供して 頂いた恩義があります. interface business GmbH, Dresden は, &a.joerg; を根気よくサポートしてくださいました. 彼は本職より FreeBSD の仕事を好みがちであり, 彼個人の接続があまりに 遅くなったり途切れたりして仕事にならない時は必ず interface business の (非常に高価な) EUnet インターネット接続に頼ったものです... Berkeley Software Design, Inc. は, 同社の DOS エミュレータのコードを BSD コミュニティ全体に対して提供してくれました. このコードは, doscmd コマンドに利用されています. FreeBSD コアチーム FreeBSD コアチームは, プロジェクトの 運用委員会 を形成し, FreeBSD プロジェクトの全般的な目的や方針の決定を行います. さらに, FreeBSDプロジェクトの 特定の分野の 運用も行っています. (姓でアルファベット順): &a.asami; &a.dg; &a.jkh; &a.grog; &a.imp; &a.dfr; &a.jesper; &a.msmith; &a.rwatson; &a.peter; FreeBSD の開発者たち (CVSの)commitする権利を持っていて, FreeBSD のソースツリーについて 作業をおこなっている人々がいます. すべてのコアチームのメンバはま た 開発者でもあります. &a.akiyama; &a.jmas; &a.will; &a.ugen; &a.toshi; &a.babkin; &a.dbaker; &a.jhb; &a.dmlb; &a.rvb; &a.dougb; &a.mike; &a.mbarkah; &a.tobez; &a.stb; &a.pb; &a.abial; &a.jb; &a.nbm; &a.torstenb; &a.mb; &a.jmb; &a.wilko; &a.jake; &a.dburr; &a.adrian; &a.dwcjr; &a.charnier; &a.jon; &a.luoqi; &a.ache; &a.ejc; &a.kjc; &a.cjh; &a.cjc; &a.nik; &a.archie; &a.chris; &a.alc; &a.cracauer; &a.dec; &a.pds; &a.adam; &a.brooks; &a.bsd; &a.jwd; &a.dillon; &a.mdodd; &a.dd; &a.iedowse; &a.robert; &a.gad; &a.dufault; &a.uhclem; &a.tegge; &a.deischen; &a.eivind; &a.julian; &a.rse; &a.ue; &a.ru; &a.se; &a.bde; &a.jasone; &a.sef; &a.jedgar; &a.green; &a.fenner; &a.lioux; &a.jfieber; &a.jfitz; &a.petef; &a.scrappy; &a.lars; &a.dirk; &a.sf; &a.shige; &a.billf; &a.furuta; &a.gallatin; &a.patrick; &a.tg; &a.gibbs; &a.brandon; &a.gioria; &a.graichen; &a.cg; &a.rgrimes; &a.jmg; &a.hanai; &a.roger; &a.mharo; &a.dannyboy; &a.thepish; &a.jhay; &a.sheldonh; &a.mikeh; &a.helbig; &a.ghelmer; &a.erich; &a.chm; &a.nhibma; &a.flathill; &a.orion; &a.pho; &a.horikawa; &a.hosokawa; &a.jeh; &a.hsu; &a.foxfair; &a.tom; &a.mph; &a.imura; &a.shin; &a.itojun; &a.iwasaki; &a.mjacob; &a.keith; &a.gj; &a.trevor; &a.phk; &a.tomsoft; &a.joe; &a.cokane; &a.kato; &a.kris; &a.keramida; &a.fjoe; &a.kiri; &a.andreas; &a.lkoeller; &a.motoyuki; &a.jkoshy; &a.kuriyama; &a.alex; &a.chern; &a.reg; &a.jlemon; &a.truckman; &a.ijliao; &a.lile; &a.clive; &a.kevlo; &a.scottl; &a.ade; &a.jmacd; &a.smace; &a.bmah; &a.dwmalone; &a.matusita; &a.mckay; &a.mckusick; &a.eric; &a.ken; &a.dinoex; &a.hm; &a.sanpei; &a.bmilekic; &a.mita; &a.non; &a.jim; &a.marcel; &a.amorita; &a.dan; &a.tmm; &a.amurai; &a.markm; &a.rich; &a.knu; &a.nakai; &a.max; &a.newton; &a.rnordier; &a.davidn; &a.obrien; &a.danny; &a.okazaki; &a.olgeni; &a.ljo; &a.onoe; &a.marko; &a.gpalmer; &a.fsmp; &a.smpatel; &a.cp; &a.wpaul; &a.mp; &a.alfred; &a.roam; &a.wes; &a.cpiazza; &a.pirzyk; &a.jdp; &a.bp; &a.rpratt; &a.steve; &a.mpp; &a.markp; &a.darrenr; &a.csgr; &a.greid; &a.mr; &a.martin; &a.benno; &a.luigi; &a.paul; &a.roberto; &a.chuckr; &a.jesusr; &a.guido; &a.groudier; &a.dima; &a.asmodai; &a.ps; &a.sada; &a.hrs; &a.wsanchez; &a.nsayer; &a.sos; &a.wosch; &a.schweikh; &a.dick; &a.jseger; &a.gshapiro; &a.shiba; &a.tshiozak; &a.simokawa; &a.vanilla; &a.silby; &a.shafeeq; &a.demon; &a.msmith; &a.ben; &a.nsouch; &a.issei; &a.des; &a.sobomax; &a.dcs; &a.brian; &a.mks; &a.stark; &a.murray; &a.sumikawa; &a.gsutter; &a.unfurl; &a.nyan; &a.tanimura; &a.taoka; &a.mtaylor; &a.dt; &a.mi; &a.yar; &a.cwt; &a.pst; &a.ume; &a.semenu; &a.rv; &a.hoek; &a.logo; &a.nectar; &a.jayanth; &a.wjv; &a.bean; &a.swallace; &a.takawata; &a.assar; &a.dwhite; &a.nate; &a.wollman; &a.keichii; &a.joerg; &a.kbyanc; &a.uch; &a.yokota; &a.andy; &a.zarzycki; &a.phantom; &a.jmz; FreeBSD ドキュメンテーションプロジェクト FreeBSD ドキュメンテーションプロジェクトは複数のサービスを提供 しています. それぞれのサービスは, 以下の担当者とその 副担当者によって運用されています. ドキュメンテーションプロジェクト担当 &a.nik; ハンドブック編集担当 &a.jim; FAQ 編集担当 &a.faq; ニュースフラッシュ編集担当 &a.jim; In the Press 編集担当 &a.jkoshy; FreeBSD Really-Quick NewsLetter編集担当 Chris Coleman chrisc@vmunix.com ギャラリーページ担当 &a.phantom; 商用ベンダーページ担当 担当者なし ]]> WEB 更新担当 &a.www; ]]> ユーザグループ担当 &a.grog; FreeBSD プロジェクトおよびタスクリスト担当 &a.asmodai; FreeBSD Java プロジェクト &a.patrick; LinuxDoc から DocBook への移行 &a.nik; 担当者 ドキュメンテーションプロジェクト担当 &a.nik; 起動ブロック &a.rnordier;, &a.jhb; ローダ &a.dcs; &a.jhb; 国際化 &a.ache; ポストマスタ &a.jmb; リリースコーディネータ &a.jkh; 広報および渉外担当 &a.jkh; セキュリティ担当 &a.kris; CVS ツリー管理者 責任者: &a.peter; 副責任者: &a.jdp; Ports Collection 担当 &a.asami; 標準化担当 &a.wollman; XFree86 Project, Inc. との渉外担当 &a.rich; GNATS 管理者 &a.steve; コアチームの卒業生 コアチーム(core team) 次にあげる人々は()で記した期間, FreeBSD コアチームのメンバーでした. FreeBSD プロジェクトにおける彼らの努力に感謝の意を表します. だいたいの年代順: &a.ache (1993 - 2000) &a.jmb (1993 - 2000) &a.bde (1992 - 2000) &a.gibbs (1993 - 2000) &a.rich (1994 - 2000) &a.phk (1992 - 2000) &a.gpalmer (1993 - 2000) &a.sos (1993 - 2000) &a.wollman (1993 - 2000) &a.joerg (1995 - 2000) &a.jdp (1997 - 2000) &a.guido (1995 - 1999) - &a.dyson (1993 - 1998) + John Dyson (1993 - 1998) &a.nate (1992 - 1996) &a.rgrimes (1992 - 1995) Andreas Schulz (1992 - 1995) &a.csgr (1993 - 1995) &a.paul (1992 - 1995) &a.smace (1993 - 1994) Andrew Moore (1993 - 1994) Christoph Robitschko (1993 - 1994) J. T. Conklin (1992 - 1993) 開発チームの卒業生 開発チーム(development team) 次にあげるのは, かつて FreeBSD 開発チームの一員だった人々です. FreeBSD プロジェクトに貢献してくださった彼らに感謝します. ほぼ年代順に: &a.tedm (???? - 2000) &a.karl (???? - 2000) - &a.gclarkii (1993 - 2000) + Gary Clark II (1993 - 2000) - &a.jraynard (???? - 2000) + James Raynard (???? - 2000) &a.jgreco (???? - 1999) - &a.ats (???? - 1999) + Andreas Schulz (???? - 1999) Jamil Weatherby (1997 - 1999) meganm (???? - 1998) - &a.dyson (???? - 1998) + John Dyson (???? - 1998) Amancio Hasty (1997 - 1998) Drew Derbyshire (1997 - 1998) BSD 派生ソフトウェアへの貢献者 このソフトウェアは最初は William F. Jolitz の 386BSD release 0.1 から派生しましたが, オリジナルの 386BSD に固有のコードはほとんど残っていません. このソフトウェアは基本的にはカリフォルニア大学 バークレイ校の Computer Science Research Group (CSRG) とその共同研究者 たちによる 4.4BSD-Lite リリースから再実装されました. また, NetBSD や OpenBSD の一部も FreeBSD に取り込まれています. したがって私たちは NetBSD と OpenBSD へ貢献した人々すべてに感謝します. その他の FreeBSD への貢献者 (名前でアルファベット順に): ABURAYA Ryushirou rewsirow@ff.iij4u.or.jp AMAGAI Yoshiji amagai@nue.org Aaron Bornstein aaronb@j51.com Aaron Smith aaron@mutex.org Achim Patzner ap@noses.com Ada T Lim ada@bsd.org Adam Baran badam@mw.mil.pl Adam Glass glass@postgres.berkeley.edu Adam Herzog adam@herzogdesigns.com Adam Kranzel adam@alameda.edu Adam McDougall mcdouga9@egr.msu.edu Adam Strohl troll@digitalspark.net Adoal Xu adoal@iname.com Adrian Colley aecolley@ois.ie Adrian Hall ahall@mirapoint.com Adrian Mariano adrian@cam.cornell.edu Adrian Steinmann ast@marabu.ch Adrian T. Filipi-Martin atf3r@agate.cs.virginia.edu Ajit Thyagarajan unknown Akira SAWADA unknown Akira Watanabe akira@myaw.ei.meisei-u.ac.jp Akito Fujita fujita@zoo.ncl.omron.co.jp Alain Kalker A.C.P.M.Kalker@student.utwente.nl Alan Bawden alan@curry.epilogue.com Alec Wolman wolman@cs.washington.edu Aled Morris aledm@routers.co.uk Aleksandr A Babaylov .@babolo.ru Alex G. Bulushev bag@demos.su Alex D. Chen dhchen@Canvas.dorm7.nccu.edu.tw Alex Le Heux alexlh@funk.org Alex Kapranoff kappa@zombie.antar.bryansk.ru Alex Perel veers@disturbed.net Alex Semenyaka alex@rinet.ru Alex Varju varju@webct.com Alex Zepeda garbanzo@hooked.net Alexander B. Povolotsky tarkhil@mgt.msk.ru Alexander Gelfenbain mail@gelf.com Alexander Leidinger Alexander+FBSD@Leidinger.net Alexandre Peixoto alexandref@tcoip.com.br Alexandre Snarskii snar@paranoia.ru Alistair G. Crooks agc@uts.amdahl.com Allan Bowhill bowhill@bowhill.vservers.com Allan Saddi asaddi@philosophysw.com Allen Campbell allenc@verinet.com Amakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jp Amancio Hasty hasty@star-gate.com Amir Farah amir@comtrol.com Amir Shalem amir@boom.org.il Amy Baron amee@beer.org The Anarcat beaupran@iro.umontreal.ca Anatoly A. Orehovsky tolik@mpeks.tomsk.su Anatoly Vorobey mellon@pobox.com Anders Andersson anders@codefactory.se Anders Nordby anders@fix.no Anders Thulin Anders.X.Thulin@telia.se Andras Olah olah@cs.utwente.nl Andre Albsmeier Andre.Albsmeier@mchp.siemens.de Andre Goeree abgoeree@uwnet.nl Andre Oppermann andre@pipeline.ch Andreas Haakh ah@alman.robin.de Andreas Kohout shanee@rabbit.augusta.de Andreas Lohr andreas@marvin.RoBIN.de Andreas Schulz unknown Andreas Wetzel mickey@deadline.snafu.de Andreas Wrede andreas@planix.com Andres Vega Garcia unknown Andrew Atrens atreand@statcan.ca Andrew Boothman andrew@cream.org Andrew Gillham gillham@andrews.edu Andrew Gordon andrew.gordon@net-tel.co.uk Andrew Herbert andrew@werple.apana.org.au Andrew J. Korty ajk@purdue.edu Andrew L. Moore alm@mclink.com Andrew L. Neporada andrew@chg.ru Andrew McRae amcrae@cisco.com Andrew Stevenson andrew@ugh.net.au Andrew Timonin tim@pool1.convey.ru Andrew V. Stesin stesin@elvisti.kiev.ua Andrew Webster awebster@dataradio.com Andrey Novikov andrey@novikov.com Andrey Simonenko simon@comsys.ntu-kpi.kiev.ua Andrey Tchoritch andy@venus.sympad.net Andy Farkas andyf@speednet.com.au Andy Sparrow spadger@best.com Andy Valencia ajv@csd.mot.com Andy Whitcroft andy@sarc.city.ac.uk Angelo Turetta ATuretta@stylo.it Anthony C. Chavez magus@xmission.com Anthony Yee-Hang Chan yeehang@netcom.com Anton N. Bruesov antonz@library.ntu-kpi.kiev.ua Anton Voronin anton@urc.ac.ru Antti Kaipila anttik@iki.fi arci vega@sophia.inria.fr Are Bryne are.bryne@communique.no Ari Suutari ari@suutari.iki.fi Arindum Mukerji rmukerji@execpc.com Arjan de Vet devet@IAEhv.nl Arne Henrik Juul arnej@Lise.Unit.NO Arun Sharma adsharma@sharmas.dhs.org Arnaud S. Launay asl@launay.org Ask Bjoern Hansen ask@valueclick.com Atsushi Furuta furuta@sra.co.jp Atsushi Murai amurai@spec.co.jp Atushi Sakauchi sakauchi@yamame.to Bakul Shah bvs@bitblocks.com Barry Bierbauch pivrnec@vszbr.cz Barry Lustig barry@ictv.com Ben Hutchinson benhutch@xfiles.org.uk Ben Jackson unknown Ben Walter bwalter@itachi.swcp.com Benjamin Lewis bhlewis@gte.net Berend de Boer berend@pobox.com Bernd Rosauer br@schiele-ct.de Bill Kish kish@osf.org Bill Trost trost@cloud.rain.com Blaz Zupan blaz@amis.net Bob Van Valzah Bob@whitebarn.com Bob Wilcox bob@obiwan.uucp Bob Willcox bob@luke.pmr.com Boris Staeblow balu@dva.in-berlin.de Boyd Faulkner faulkner@mpd.tandem.com Boyd R. Faulkner faulkner@asgard.bga.com Brad Chapman chapmanb@arches.uga.edu Brad Hendrickse bradh@uunet.co.za Brad Karp karp@eecs.harvard.edu Bradley Dunn bradley@dunn.org Brad Jones brad@kazrak.com Brandon Fosdick bfoz@glue.umd.edu Brandon Gillespie brandon@roguetrader.com - &a.wlloyd; + Bill Lloyd wlloyd@mpd.ca Brent J. Nordquist bjn@visi.com Brett Lymn blymn@mulga.awadi.com.AU Brett Taylor brett@peloton.runet.edu Brian Campbell brianc@pobox.com Brian Clapper bmc@willscreek.com Brian Cully shmit@kublai.com Brian Handy handy@lambic.space.lockheed.com Brian Litzinger brian@MediaCity.com Brian McGovern bmcgover@cisco.com Brian Moore ziff@houdini.eecs.umich.edu Brian R. Haug haug@conterra.com Brian Tao taob@risc.org Brion Moss brion@queeg.com Bruce Albrecht bruce@zuhause.mn.org Bruce Gingery bgingery@gtcs.com Bruce J. Keeler loodvrij@gridpoint.com Bruce Murphy packrat@iinet.net.au Bruce Walter walter@fortean.com Carey Jones mcj@acquiesce.org Carl Fongheiser cmf@netins.net Carl Mascott cmascott@world.std.com Casper casper@acc.am Castor Fu castor@geocast.com Chad David davidc@acns.ab.ca Chain Lee chain@110.net Charles Hannum mycroft@ai.mit.edu Charles Henrich henrich@msu.edu Charles Mott cmott@scientech.com Charles Owens owensc@enc.edu Chet Ramey chet@odin.INS.CWRU.Edu Chia-liang Kao clkao@CirX.ORG Chiharu Shibata chi@bd.mbn.or.jp Chip Norkus unknown Chris Csanady cc@tarsier.ca.sandia.gov Chris Dabrowski chris@vader.org Chris Dillon cdillon@wolves.k12.mo.us Chris Shenton cshenton@angst.it.hq.nasa.gov &a.cshumway; Chris Stenton jacs@gnome.co.uk Chris Timmons skynyrd@opus.cts.cwu.edu Chris Torek torek@ee.lbl.gov Christian Gusenbauer cg@fimp01.fim.uni-linz.ac.at Christian Haury Christian.Haury@sagem.fr Christian Weisgerber naddy@mips.inka.de Christoph P. Kukulies kuku@FreeBSD.org Christoph Robitschko chmr@edvz.tu-graz.ac.at Christoph Weber-Fahr wefa@callcenter.systemhaus.net Christopher G. Demetriou cgd@postgres.berkeley.edu Christopher N. Harrell cnh@ivmg.net Christopher Preston rbg@gayteenresource.org Christopher T. Johnson cjohnson@neunacht.netgsi.com Chrisy Luke chrisy@flix.net Chuck Hein chein@cisco.com Cliff Rowley dozprompt@onsea.com Colman Reilly careilly@tcd.ie Conrad Sabatier conrads@home.com Coranth Gryphon gryphon@healer.com Cornelis van der Laan nils@guru.ims.uni-stuttgart.de Cove Schneider cove@brazil.nbn.com Craig Leres leres@ee.lbl.gov Craig Loomis unknown Craig Metz cmetz@inner.net Craig Spannring cts@internetcds.com Craig Struble cstruble@vt.edu Cristian Ferretti cfs@riemann.mat.puc.cl Curt Mayer curt@toad.com Cy Schubert cschuber@uumail.gov.bc.ca Cyrille Lefevre clefevre@citeweb.net Cyrus Rahman cr@jcmax.com Dai Ishijima ishijima@tri.pref.osaka.jp Daisuke Watanabe NU7D-WTNB@asahi-net.or.jp Damian Hamill damian@cablenet.net Dan Cross tenser@spitfire.ecsel.psu.edu Dan Langille dan@freebsddiary.org Dan Lukes dan@obluda.cz Dan Nelson dnelson@emsphone.com Dan Papasian bugg@bugg.strangled.net Dan Piponi wmtop@tanelorn.demon.co.uk Dan Walters hannibal@cyberstation.net Daniel Hagan dhagan@cs.vt.edu Daniel O'Connor doconnor@gsoft.com.au Daniel Poirot poirot@aio.jsc.nasa.gov Daniel Rock rock@cs.uni-sb.de Daniel W. McRobb dwm@caimis.com Danny Egen unknown Danny J. Zerkel dzerkel@phofarm.com Darren Reed avalon@coombs.anu.edu.au Dave Adkins adkin003@tc.umn.edu Dave Andersen angio@aros.net Dave Blizzard dblizzar@sprynet.com Dave Bodenstab imdave@synet.net Dave Burgess burgess@hrd769.brooks.af.mil Dave Chapeskie dchapes@ddm.on.ca Dave Cornejo dave@dogwood.com Dave Edmondson davided@sco.com Dave Glowacki dglo@ssec.wisc.edu Dave Marquardt marquard@austin.ibm.com Dave Tweten tweten@FreeBSD.org David A. Adkins adkin003@tc.umn.edu David A. Bader dbader@eece.unm.edu David Borman dab@bsdi.com David Dawes dawes@XFree86.org David Filo unknown David Holland dholland@eecs.harvard.edu David Holloway daveh@gwythaint.tamis.com David Horwitt dhorwitt@ucsd.edu David Hovemeyer daveho@infocom.com David Jones dej@qpoint.torfree.net David Kelly dkelly@tomcat1.tbe.com David Kulp dkulp@neomorphic.com David L. Nugent davidn@blaze.net.au David Leonard d@scry.dstc.edu.au David Muir Sharnoff muir@idiom.com David Sugar dyfet@gnu.org David S. Miller davem@jenolan.rutgers.edu David Wolfskill dhw@whistle.com Dean Gaudet dgaudet@arctic.org Dean Huxley dean@fsa.ca Denis Fortin unknown Denis Shaposhnikov dsh@vlink.ru Dennis Glatting dennis.glatting@software-munitions.com Denton Gentry denny1@home.com der Mouse mouse@Collatz.McRCIM.McGill.EDU Derek Inksetter derek@saidev.com DI. Christian Gusenbauer cg@scotty.edvz.uni-linz.ac.at Dirk Keunecke dk@panda.rhein-main.de Dirk Nehrling nerle@pdv.de Dishanker Rajakulendren draj@oceanfree.net Dmitry A. Yanko fm@astral.ntu-kpi.kiev.ua Dmitry Khrustalev dima@xyzzy.machaon.ru Dmitry Kohmanyuk dk@farm.org Dmitry Morozovsky marck@rinet.ru Dom Mitchell dom@myrddin.demon.co.uk Domas Mituzas midom@dammit.lt Dominik Brettnacher domi@saargate.de Dominik Rothert dr@domix.de Don Croyle croyle@gelemna.ft-wayne.in.us Donn Miller dmmiller@cvzoom.net Dan Pelleg dpelleg+unison@cs.cmu.edu &a.whiteside; Don Morrison dmorrisn@u.washington.edu Don Yuniskis dgy@rtd.com Donald Maddox dmaddox@conterra.com Douglas Ambrisko ambrisko@whistle.com Douglas Carmichael dcarmich@mcs.com Douglas Crosher dtc@scrooge.ee.swin.oz.au Drew Derbyshire ahd@kew.com Dustin Sallings dustin@spy.net Eckart "Isegrim" Hofmann Isegrim@Wunder-Nett.org Ed Gold vegold01@starbase.spd.louisville.edu Ed Hudson elh@p5.spnet.com Edward Chuang edwardc@firebird.org.tw Edward Wang edward@edcom.com Edwin Groothus edwin@nwm.wan.philips.com Edwin Mons e@ik.nu Ege Rekk aagero@aage.priv.no Eiji-usagi-MATSUmoto usagi@clave.gr.jp Eike Bernhardt eike.bernhardt@gmx.de ELISA Font Project Elmar Bartel bartel@informatik.tu-muenchen.de Eoin Lawless eoin@maths.tcd.ie Eric A. Griff eric@talesfromthereal.com Eric Blood eblood@cs.unr.edu Eric J. Haug ejh@slustl.slu.edu Eric J. Schwertfeger eric@cybernut.com Eric L. Hernes erich@lodgenet.com Eric P. Scott eps@sirius.com Eric Sprinkle eric@ennovatenetworks.com Erich Stefan Boleyn erich@uruk.org Erich Zigler erich@tacni.net Erik H. Bakke erikhb@bgnett.no Erik E. Rantapaa rantapaa@math.umn.edu Erik H. Moe ehm@cris.com Ernst de Haan ernst@heinz.jollem.com Ernst Winter ewinter@lobo.muc.de Espen Skoglund esk@ira.uka.de Eugene M. Kim astralblue@usa.net Eugene Radchenko genie@qsar.chem.msu.su Eugeny Kuzakov CoreDumped@coredumped.null.ru Evan Champion evanc@synapse.net Fanying Jen fanying@fynet.com Faried Nawaz fn@Hungry.COM Flemming Jacobsen fj@batmule.dk Fong-Ching Liaw fong@juniper.net Francis M J Hsieh mjshieh@life.nthu.edu.tw Francisco Reyes fjrm@yahoo.com Frank Bartels knarf@camelot.de Frank Chen Hsiung Chan frankch@waru.life.nthu.edu.tw Frank Durda IV uhclem@nemesis.lonestar.org Frank MacLachlan fpm@n2.net Frank Nobis fn@Radio-do.de Frank ten Wolde franky@pinewood.nl Frank van der Linden frank@fwi.uva.nl Frank Volf volf@oasis.IAEhv.nl Fred Cawthorne fcawth@jjarray.umn.edu Fred Gilham gilham@csl.sri.com Fred Templin templin@erg.sri.com Frederick Earl Gray fgray@rice.edu FUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jp FURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jp Fuyuhiko Maruyama fuyuhik8@is.titech.ac.jp &a.stanislav; Gabor Kincses gabor@acm.org Gabor Zahemszky zgabor@CoDe.hu Garance A Drosehn gad@eclipse.its.rpi.edu Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Gary J. garyj@rks32.pcs.dec.com Gary Kline kline@thought.org Gary W. Swearingen swear@aa.net Gaspar Chilingarov nightmar@lemming.acc.am Gea-Suan Lin gsl@tpts4.seed.net.tw Gene Raytsin pal@paladin7.net Geoff Rehmet csgr@alpha.ru.ac.za Georg Wagner georg.wagner@ubs.com Gianlorenzo Masini masini@uniroma3.it Gianmarco Giovannelli gmarco@giovannelli.it Gil Kloepfer Jr. gil@limbic.ssdl.com Gilad Rom rom_glsa@ein-hashofet.co.il Giles Lean giles@nemeton.com.au Ginga Kawaguti ginga@amalthea.phys.s.u-tokyo.ac.jp Glen Foster gfoster@gfoster.com Glenn Johnson gljohns@bellsouth.net Godmar Back gback@facility.cs.utah.edu Goran Hammarback goran@astro.uu.se Gord Matzigkeit gord@enci.ucalgary.ca Gordon Greeff gvg@uunet.co.za Graham Wheeler gram@cdsec.com Greg A. Woods woods@zeus.leitch.com Greg Ansley gja@ansley.com Greg Lewis glewis@eyesbeyond.com Greg Robinson greg@rosevale.com.au Greg Troxel gdt@ir.bbn.com Greg Ungerer gerg@stallion.oz.au Gregory Bond gnb@itga.com.au Gregory D. Moncreaff moncrg@bt340707.res.ray.com Guy Harris guy@netapp.com Guy Helmer ghelmer@cs.iastate.edu HAMADA Naoki hamada@astec.co.jp Hammurabi Mendes hmendes_br@yahoo.com Hannu Savolainen hannu@voxware.pp.fi Hans Huebner hans@artcom.de Hans Petter Bieker zerium@webindex.no Hans Zuidam hans@brandinnovators.com Harlan Stenn Harlan.Stenn@pfcs.com Harold Barker hbarker@dsms.com Harry Newton harry_newton@telinco.co.uk Havard Eidnes Havard.Eidnes@runit.sintef.no Heath Nielson heath@cs.byu.edu Heikki Suonsivu hsu@cs.hut.fi Heiko W. Rupp unknown Helmut F. Wirth hfwirth@ping.at Henrik Vestergaard Draboel hvd@terry.ping.dk Herb Peyerl hpeyerl@NetBSD.org Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp Hidekazu Kuroki hidekazu@cs.titech.ac.jp Hideki Yamamoto hyama@acm.org Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp Hirayama Issei iss@mail.wbs.ne.jp Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp Hiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jp Hironori Ikura hikura@kaisei.org Hiroshi Nishikawa nis@pluto.dti.ne.jp Hiroya Tsubakimoto unknown Holger Lamm holger@eit.uni-kl.de Holger Veit Holger.Veit@gmd.de Holm Tiffe holm@geophysik.tu-freiberg.de HONDA Yasuhiro honda@kashio.info.mie-u.ac.jp Horance Chou horance@freedom.ie.cycu.edu.tw Horihiro Kumagai kuma@jp.FreeBSD.org HOSOBUCHI Noriyuki hoso@buchi.tama.or.jp HOTARU-YA hotaru@tail.net Hr.Ladavac lada@ws2301.gud.siemens.co.at Hubert Feyrer hubertf@NetBSD.ORG Hugh F. Mahon hugh@nsmdserv.cnd.hp.com Hugh Mahon h_mahon@fc.hp.com Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw Ian Holland ianh@tortuga.com.au Ian Struble ian@broken.net Ian Vaudrey i.vaudrey@bigfoot.com Igor Serikov bt@turtle.pangeatech.com Igor Khasilev igor@jabber.paco.odessa.ua Igor Roshchin str@giganda.komkon.org Igor Sviridov siac@ua.net Igor Vinokurov igor@zynaps.ru Ikuo Nakagawa ikuo@isl.intec.co.jp Ilia Chipitsine ilia@jane.cgu.chel.su Ilya V. Komarov mur@lynx.ru IMAI Takeshi take-i@ceres.dti.ne.jp IMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jp Itsuro Saito saito@miv.t.u-tokyo.ac.jp IWASHITA Yoji shuna@pop16.odn.ne.jp J. Bryant jbryant@argus.flash.net J. David Lowe lowe@saturn5.com J. Han hjh@photino.com J. Hawk jhawk@MIT.EDU J.T. Conklin jtc@cygnus.com Jack jack@zeus.xtalwind.net Jacob Bohn Lorensen jacob@jblhome.ping.mk Jagane D Sundar jagane@netcom.com Jake Hamby jehamby@anobject.com James Clark jjc@jclark.com James D. Stewart jds@c4systm.com James da Silva jds@cs.umd.edu James Jegers jimj@miller.cs.uwm.edu James Raynard fhackers@jraynard.demon.co.uk James T. Liu jtliu@phlebas.rockefeller.edu Jamie Heckford jamie@jamiesdomain.co.uk Jan Conard charly@fachschaften.tu-muenchen.de Jan Jungnickel Jan@Jungnickel.com Jan Koum jkb@FreeBSD.org Jan L. Peterson jlp@flipdog.com Janick Taillandier Janick.Taillandier@ratp.fr Janusz Kokot janek@gaja.ipan.lublin.pl Jarle Greipsland jarle@idt.unit.no Jason DiCioccio geniusj@ods.org Jason Garman init@risen.org Jason R. Mastaler jason-freebsd@mastaler.com Jason Thorpe thorpej@NetBSD.org Jason Wright jason@OpenBSD.org Jason Young doogie@forbidden-donut.anet-stl.com Javier Martin Rueda jmrueda@diatel.upm.es Jay Fenlason hack@datacube.com Jay Krell jay.krell@cornell.edu Jaye Mathisen mrcpu@cdsnet.net Jeff Bartig jeffb@doit.wisc.edu Jeff Brown jabrown@caida.org Jeff Forys jeff@forys.cranbury.nj.us Jeff Kletsky Jeff@Wagsky.com Jeff Palmer scorpio@drkshdw.org Jeffrey Evans evans@scnc.k12.mi.us Jeffrey Wheat jeff@cetlink.net Jeremy Allison jallison@whistle.com Jeremy Chadwick yoshi@parodius.com Jeremy Chatfield jdc@xinside.com Jeremy Karlson karlj000@unbc.ca Jeremy Prior unknown Jeremy Shaffner jeremy@external.org Jesse McConnell jesse@cylant.com Jesse Rosenstock jmr@ugcs.caltech.edu Jian-Da Li jdli@csie.nctu.edu.tw Jim Babb babb@FreeBSD.org Jim Binkley jrb@cs.pdx.edu Jim Bloom bloom@acm.org Jim Carroll jim@carroll.com Jim Flowers jflowers@ezo.net Jim Leppek jleppek@harris.com Jim Lowe james@cs.uwm.edu Jim Mattson jmattson@sonic.net Jim Mercer jim@komodo.reptiles.org Jim Sloan odinn@atlantabiker.net Jim Wilson wilson@moria.cygnus.com Jimbo Bahooli griffin@blackhole.iceworld.org Jin Guojun jin@george.lbl.gov Joachim Kuebart kuebart@mathematik.uni-ulm.de Joao Carlos Mendes Luis jonny@jonny.eng.br Jochen Pohl jpo.drs@sni.de Joe "Marcus" Clarke marcus@marcuscom.com Joe Abley jabley@automagic.org Joe Jih-Shian Lu jslu@dns.ntu.edu.tw Joe Orthoefer j_orthoefer@tia.net Joe Traister traister@mojozone.org Joel Faedi Joel.Faedi@esial.u-nancy.fr Joel Ray Holveck joelh@gnu.org Joel Sutton jsutton@bbcon.com.au Jordan DeLong fracture@allusion.net Joseph Scott joseph@randomnetworks.com Johan Granlund johan@granlund.nu Johan Karlsson k@numeri.campus.luth.se Johan Larsson johan@moon.campus.luth.se Johann Tonsing jtonsing@mikom.csir.co.za Johannes 5 Joemann joemann@beefree.free.de Johannes Helander unknown Johannes Stille unknown John Beckett jbeckett@southern.edu John Beukema jbeukema@hk.super.net John Brezak unknown John Capo jc@irbs.com John F. Woods jfw@jfwhome.funhouse.com John Goerzen jgoerzen@alexanderwohl.complete.org John Heidemann johnh@isi.edu John Hood cgull@owl.org John Kohl unknown John Lind john@starfire.mn.org John Mackin john@physiol.su.oz.au John Merryweather Cooper jmcoopr@webmail.bmi.net John P johnp@lodgenet.com John Perry perry@vishnu.alias.net John Preisler john@vapornet.com John Reynolds jjreynold@home.com John Rochester jr@cs.mun.ca John Sadler john_sadler@alum.mit.edu John Saunders john@pacer.nlc.net.au John Wehle john@feith.com John Woods jfw@eddie.mit.edu Johny Mattsson lonewolf@flame.org Jon Morgan morgan@terminus.trailblazer.com Jonathan Belson jon@witchspace.com Jonathan H N Chin jc254@newton.cam.ac.uk Jonathan Hanna jh@pc-21490.bc.rogers.wave.ca Jonathan Pennington john@coastalgeology.org Jorge Goncalves j@bug.fe.up.pt Jorge M. Goncalves ee96199@tom.fe.up.pt Jos Backus jbackus@plex.nl Jose Marques jose@nobody.org Josef Grosch jgrosch@superior.mooseriver.com Joseph Stein joes@wstein.com Josh Gilliam josh@quick.net Josh Tiefenbach josh@ican.net Jostein Trondal jostein.trondal@sikkerhet.no Juergen Lock nox@jelal.hb.north.de Juha Inkari inkari@cc.hut.fi Jukka A. Ukkonen jau@iki.fi Julian Assange proff@suburbia.net Julian Coleman j.d.coleman@ncl.ac.uk &a.jhs; Julian Jenkins kaveman@magna.com.au Junichi Satoh junichi@jp.FreeBSD.org Junji SAKAI sakai@jp.FreeBSD.org Junya WATANABE junya-w@remus.dti.ne.jp Justas justas@mbank.lv Justin Stanford jus@security.za.net K.Higashino a00303@cc.hc.keio.ac.jp Kai Vorma vode@snakemail.hut.fi Kaleb S. Keithley kaleb@ics.com Kaneda Hiloshi vanitas@ma3.seikyou.ne.jp Kang-ming Liu gugod@gugod.org Kapil Chowksey kchowksey@hss.hns.com Karl Denninger karl@mcs.com Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com KATO Tsuguru tkato@prontomail.ne.jp Kawanobe Koh kawanobe@st.rim.or.jp Kees Jan Koster kjk1@ukc.ac.uk Keith Bostic bostic@bostic.com Keith E. Walker kew@icehouse.net Keith Moore unknown Keith Sklower unknown Ken Hornstein unknown Ken Key key@cs.utk.edu Ken Mayer kmayer@freegate.com Kenji Saito marukun@mx2.nisiq.net Kenji Tomita tommyk@da2.so-net.or.jp Kenneth Furge kenneth.furge@us.endress.com Kenneth Monville desmo@bandwidth.org Kenneth R. Westerback krw@tcn.net Kenneth Stailey kstailey@gnu.ai.mit.edu Kent Talarico kent@shipwreck.tsoft.net Kent Vander Velden graphix@iastate.edu Kentaro Inagaki JBD01226@niftyserve.ne.jp Kevin Bracey kbracey@art.acorn.co.uk Kevin Day toasty@dragondata.com Kevin Lahey kml@nas.nasa.gov Kevin Meltzer perlguy@perlguy.com Kevin Street street@iname.com Kevin Van Maren vanmaren@fast.cs.utah.edu Killer killer@prosalg.no Kim Scarborough sluggo@unknown.nu Kiril Mitev kiril@ideaglobal.com Kiroh HARADA kiroh@kh.rim.or.jp Klaus Herrmann klaus.herrmann@gmx.net Klaus Klein kleink@layla.inka.de Klaus-J. Wolf Yanestra@t-online.de Koichi Sato copan@ppp.fastnet.or.jp Konrad Heuer kheuer@gwdu60.gwdg.de Konstantin Chuguev Konstantin.Chuguev@dante.org.uk Kostya Lukin lukin@okbmei.msk.su Kouichi Hirabayashi kh@mogami-wire.co.jp Kris Dow kris@vilnya.demon.co.uk KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp Kurt D. Zeilenga Kurt@Boolean.NET Kurt Olsen kurto@tiny.mcs.usu.edu L. Jonas Olsson ljo@ljo-slip.DIALIN.CWRU.Edu Larry Altneu larry@ALR.COM Lars Bernhardsson lab@fnurt.net Lars Köller Lars.Koeller@Uni-Bielefeld.DE Laurence Lopez lopez@mv.mv.com Lee Cremeans lcremean@tidalwave.net Leo Kim leo@florida.sarang.net Leo Serebryakov lev@serebryakov.spb.ru Liang Tai-hwa avatar@www.mmlab.cse.yzu.edu.tw Lon Willett lon%softt.uucp@math.utah.edu Louis A. Mamakos louie@TransSys.COM Louis Mamakos loiue@TransSys.com Lowell Gilbert lowell@world.std.com Lucas James Lucas.James@ldjpc.apana.org.au Lyndon Nerenberg lyndon@orthanc.ab.ca M. L. Dodson bdodson@scms.utmb.EDU M.C. Wong unknown Magnus Enbom dot@tinto.campus.luth.se Mahesh Neelakanta mahesh@gcomm.com Makoto WATANABE watanabe@zlab.phys.nagoya-u.ac.jp Makoto YAMAKURA makoto@pinpott.spnet.ne.jp Malte Lance malte.lance@gmx.net MANTANI Nobutaka nobutaka@nobutaka.com Manu Iyengar iyengar@grunthos.pscwa.psca.com Marc Frajola marc@dev.com Marc Ramirez mrami@mramirez.sy.yale.edu Marc Slemko marcs@znep.com Marc van Kempen wmbfmk@urc.tue.nl Marc van Woerkom van.woerkom@netcologne.de Marcin Cieslak saper@system.pl Mark Andrews unknown Mark Cammidge mark@gmtunx.ee.uct.ac.za Mark Diekhans markd@grizzly.com Mark Huizer xaa@stack.nl Mark J. Taylor mtaylor@cybernet.com Mark Knight markk@knigma.org Mark Krentel krentel@rice.edu Mark Mayo markm@vmunix.com Mark Thompson thompson@tgsoft.com Mark Tinguely tinguely@plains.nodak.edu Mark Treacy unknown Mark Valentine mark@thuvia.org Markus Holmberg saska@acc.umu.se Martin Birgmeier unknown Martin Blapp blapp@attic.ch Martin Hinner mhi@linux.gyarab.cz Martin Ibert mib@ppe.bb-data.de Martin Kammerhofer dada@sbox.tu-graz.ac.at Martin Matuska matuska@wu-wien.ac.at Martin Minkus diskiller@cnbinc.com Martin Renters martin@tdc.on.ca Martti Kuparinen martti.kuparinen@ericsson.com Masachika ISHIZUKA ishizuka@isis.min.ntt.jp Masahiro Sekiguchi seki@sysrap.cs.fujitsu.co.jp Masahiro TAKEMURA mastake@msel.t.u-tokyo.ac.jp Masanobu Saitoh msaitoh@spa.is.uec.ac.jp Masanori Kanaoka kana@saijo.mke.mei.co.jp Masanori Kiriake seiken@ARGV.AC Masatoshi TAMURA tamrin@shinzan.kuee.kyoto-u.ac.jp Mats Lofkvist mal@algonet.se Matt Bartley mbartley@lear35.cytex.com Matt Heckaman matt@LUCIDA.QC.CA Matt Thomas matt@3am-software.com Matt White mwhite+@CMU.EDU Matthew C. Mead mmead@Glock.COM Matthew Cashdollar mattc@rfcnet.com Matthew Emmerton root@gabby.gsicomp.on.ca Matthew Flatt mflatt@cs.rice.edu Matthew Fuller fullermd@futuresouth.com Matthew Stein matt@bdd.net Matthew West mwest@uct.ac.za Matthias Pfaller leo@dachau.marco.de Matthias Scheler tron@netbsd.org Mattias Gronlund Mattias.Gronlund@sa.erisoft.se Mattias Pantzare pantzer@ludd.luth.se Maurice Castro maurice@planet.serc.rmit.edu.au Max Euston meuston@jmrodgers.com Maxim Bolotin max@rsu.ru Maxim Konovalov maxim@macomnet.ru Maxime Henrion mhenrion@cybercable.fr Micha Class michael_class@hpbbse.bbn.hp.com Michael Alyn Miller malyn@strangeGizmo.com Michael Lucas mwlucas@blackhelicopters.org Michael Lyngbøl michael@lyngbol.dk Michael Butler imb@scgt.oz.au Michael Butschky butsch@computi.erols.com Michael Clay mclay@weareb.org Michael Galassi nerd@percival.rain.com Michael Hancock michaelh@cet.co.jp Michael Hohmuth hohmuth@inf.tu-dresden.de Michael Perlman canuck@caam.rice.edu Michael Petry petry@netwolf.NetMasters.com Michael Sardo jaeger16@yahoo.com Michael Searle searle@longacre.demon.co.uk Michael Schout mschout@gkg.net Michael Urban murban@tznet.com Michael Vasilenko acid@stu.cn.ua Michal Listos mcl@Amnesiac.123.org Michio Karl Jinbo karl@marcer.nagaokaut.ac.jp Miguel Angel Sagreras msagre@cactus.fi.uba.ar Mihoko Tanaka m_tonaka@pa.yokogawa.co.jp Mika Nystrom mika@cs.caltech.edu Mikael Hybsch micke@dynas.se Mikael Karpberg karpen@ocean.campus.luth.se Mike Bristow mike@urgle.com Mike Del repenting@hotmail.com Mike Durian durian@plutotech.com Mike Durkin mdurkin@tsoft.sf-bay.org Mike E. Matsnev mike@azog.cs.msu.su Mike Evans mevans@candle.com Mike Futerko mike@LITech.lviv.ua Mike Grupenhoff kashmir@umiacs.umd.edu Mike Harding mvh@ix.netcom.com Mike Hibler mike@marker.cs.utah.edu Mike Karels unknown Mike McGaughey mmcg@cs.monash.edu.au Mike Meyer mwm@mired.org Mike Mitchell mitchell@ref.tfs.com Mike Murphy mrm@alpharel.com Mike Peck mike@binghamton.edu Mike Sherwood mike@fate.com Mike Spengler mks@msc.edu Mikhail A. Sokolov mishania@demos.su Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW Mitsuru Yoshida mitsuru@riken.go.jp Monte Mitzelfelt monte@gonefishing.org Morgan Davis root@io.cts.com MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp Mostyn Lewis mostyn@mrl.com Motomichi Matsuzaki mzaki@e-mail.ne.jp Motoyuki Kasahara m-kasahr@sra.co.jp N.G.Smith ngs@sesame.hensa.ac.uk Nadav Eiron nadav@barcode.co.il NAGAO Tadaaki nagao@cs.titech.ac.jp NAKAJI Hiroyuki nakaji@tutrp.tut.ac.jp NAKAMURA Kazushi nkazushi@highway.or.jp NAKAMURA Motonori motonori@econ.kyoto-u.ac.jp NAKATA, Maho chat95@mbox.kyoto-inet.or.jp Nanbor Wang nw1@cs.wustl.edu Naofumi Honda honda@Kururu.math.sci.hokudai.ac.jp Naoki Hamada nao@tom-yam.or.jp Narvi narvi@haldjas.folklore.ee Nathan Dorfman nathan@rtfm.net Neal Fachan kneel@ishiboo.com Niall Smart rotel@indigo.ie Nicholas Esborn nick@netdot.net Nick Barnes Nick.Barnes@pobox.com Nick Handel nhandel@NeoSoft.com Nick Hilliard nick@foobar.org Nick Johnson freebsd@spatula.net Nick Williams njw@cs.city.ac.uk Nickolay N. Dudorov nnd@itfs.nsk.su NIIMI Satoshi sa2c@and.or.jp Niklas Hallqvist niklas@filippa.appli.se Nils M. Holm nmh@t3x.org Nisha Talagala nisha@cs.berkeley.edu No Name adrian@virginia.edu No Name alex@elvisti.kiev.ua No Name anto@netscape.net No Name bobson@egg.ics.nitch.ac.jp No Name bovynf@awe.be No Name burg@is.ge.com No Name chris@gnome.co.uk No Name colsen@usa.net No Name coredump@nervosa.com No Name dannyman@arh0300.urh.uiuc.edu No Name davids@SECNET.COM No Name derek@free.org No Name devet@adv.IAEhv.nl No Name djv@bedford.net No Name dvv@sprint.net No Name enami@ba2.so-net.or.jp No Name flash@eru.tubank.msk.su No Name flash@hway.ru No Name fn@pain.csrv.uidaho.edu No Name frf@xocolatl.com No Name gclarkii@netport.neosoft.com No Name gordon@sheaky.lonestar.org No Name graaf@iae.nl No Name greg@greg.rim.or.jp No Name grossman@cygnus.com No Name gusw@fub46.zedat.fu-berlin.de No Name hfir@math.rochester.edu No Name hnokubi@yyy.or.jp No Name iaint@css.tuu.utas.edu.au No Name invis@visi.com No Name ishisone@sra.co.jp No Name iverson@lionheart.com No Name jpt@magic.net No Name junker@jazz.snu.ac.kr No Name k-sugyou@ccs.mt.nec.co.jp No Name kenji@reseau.toyonaka.osaka.jp No Name kfurge@worldnet.att.net No Name lh@aus.org No Name lhecking@nmrc.ucc.ie No Name mrgreen@mame.mu.oz.au No Name nakagawa@jp.FreeBSD.org No Name ohki@gssm.otsuka.tsukuba.ac.jp No Name owaki@st.rim.or.jp No Name pechter@shell.monmouth.com No Name pete@pelican.pelican.com No Name pritc003@maroon.tc.umn.edu No Name risner@stdio.com No Name roman@rpd.univ.kiev.ua No Name root@ns2.redline.ru No Name root@uglabgw.ug.cs.sunysb.edu No Name stephen.ma@jtec.com.au No Name sumii@is.s.u-tokyo.ac.jp No Name takas-su@is.aist-nara.ac.jp No Name tamone@eig.unige.ch No Name tjevans@raleigh.ibm.com No Name tony-o@iij.ad.jp amurai@spec.co.jp No Name torii@tcd.hitachi.co.jp No Name uenami@imasy.or.jp No Name uhlar@netlab.sk No Name vode@hut.fi No Name wlloyd@mpd.ca No Name wlr@furball.wellsfargo.com No Name wmbfmk@urc.tue.nl No Name yamagata@nwgpc.kek.jp No Name ziggy@ryan.org No Name ZW6T-KND@j.asahi-net.or.jp Nobuhiro Yasutomi nobu@psrc.isac.co.jp Nobuyuki Koganemaru kogane@koganemaru.co.jp NOKUBI Hirotaka h-nokubi@yyy.or.jp Norio Suzuki nosuzuki@e-mail.ne.jp Noritaka Ishizumi graphite@jp.FreeBSD.org Noriyuki Soda soda@sra.co.jp Oddbjorn Steffenson oddbjorn@tricknology.org Oh Junseon hollywar@mail.holywar.net Olaf Wagner wagner@luthien.in-berlin.de Oleg Semyonov os@altavista.net Oleg Sharoiko os@rsu.ru Oleg V. Volkov rover@lglobus.ru Olexander Kunytsa kunia@wolf.istc.kiev.ua Oliver Breuninger ob@seicom.NET Oliver Friedrichs oliver@secnet.com Oliver Fromme oliver.fromme@heim3.tu-clausthal.de Oliver Helmling oliver.helmling@stud.uni-bayreuth.de Oliver Laumann net@informatik.uni-bremen.de Oliver Lehmann Kai_Allard_Liao@gmx.de Oliver Oberdorf oly@world.std.com Olof Johansson offe@ludd.luth.se Osokin Sergey aka oZZ ozz@FreeBSD.org.ru Pace Willisson pace@blitz.com Paco Rosich rosich@modico.eleinf.uv.es Palle Girgensohn girgen@partitur.se Parag Patel parag@cgt.com Pascal Pederiva pascal@zuo.dec.com Pasvorn Boonmark boonmark@juniper.net Patrick Alken cosine@ellipse.mcs.drexel.edu Patrick Bihan-Faou patrick@mindstep.com Patrick Hausen unknown Patrick Li pat@databits.net Patrick Seal patseal@hyperhost.net Paul Antonov apg@demos.su Paul F. Werkowski unknown Paul Fox pgf@foxharp.boston.ma.us Paul Koch koch@thehub.com.au Paul Kranenburg pk@NetBSD.org Paul M. Lambert plambert@plambert.net Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Paul S. LaFollette, Jr. unknown Paul Sandys myj@nyct.net Paul T. Root proot@horton.iaces.com Paul Vixie paul@vix.com Paulo Menezes paulo@isr.uc.pt Paulo Menezes pm@dee.uc.pt Pedro A M Vazquez vazquez@IQM.Unicamp.BR Pedro Giffuni giffunip@asme.org Per Wigren wigren@home.se Pete Bentley pete@demon.net Peter Childs pjchilds@imforei.apana.org.au Peter Cornelius pc@inr.fzk.de Peter Haight peterh@prognet.com Peter Jeremy peter.jeremy@alcatel.com.au Peter M. Chen pmchen@eecs.umich.edu Peter Much peter@citylink.dinoex.sub.org Peter Olsson unknown Peter Philipp pjp@bsd-daemon.net Peter Stubbs PETERS@staidan.qld.edu.au Peter van Heusden pvh@egenetics.com Phil Maker pjm@cs.ntu.edu.au Phil Sutherland philsuth@mycroft.dialix.oz.au Phil Taylor phil@zipmail.co.uk Philip Musumeci philip@rmit.edu.au Philippe Lefebvre nemesis@balistik.net Pierre Y. Dampure pierre.dampure@k2c.co.uk Pius Fischer pius@ienet.com Pomegranate daver@flag.blackened.net Powerdog Industries kevin.ruddy@powerdog.com Priit Järv priit@cc.ttu.ee R Joseph Wright rjoseph@mammalia.org R. Kym Horsell Radoslav Vasilev rvasilev@uni-svishtov.bg Ralf Friedl friedl@informatik.uni-kl.de Randal S. Masutani randal@comtest.com Randall Hopper rhh@ct.picker.com Randall W. Dean rwd@osf.org Randy Bush rbush@bainbridge.verio.net Rasmus Kaj kaj@Raditex.se Reinier Bezuidenhout rbezuide@mikom.csir.co.za Remy Card Remy.Card@masi.ibp.fr Ricardas Cepas rch@richard.eu.org Riccardo Veraldi veraldi@cs.unibo.it Rich Wood rich@FreeBSD.org.uk Richard Henderson richard@atheist.tamu.edu Richard Hwang rhwang@bigpanda.com Richard Kiss richard@homemail.com Richard J Kuhns rjk@watson.grauel.com Richard M. Neswold rneswold@enteract.com Richard Seaman, Jr. dick@tar.com Richard Stallman rms@gnu.ai.mit.edu Richard Straka straka@user1.inficad.com Richard Tobin richard@cogsci.ed.ac.uk Richard Wackerbarth rkw@Dataplex.NET Richard Winkel rich@math.missouri.edu Richard Wiwatowski rjwiwat@adelaide.on.net Rick Macklem rick@snowhite.cis.uoguelph.ca Rick Macklin unknown Rob Austein sra@epilogue.com Rob Mallory rmallory@qualcomm.com Rob Snow rsnow@txdirect.net Robert Crowe bob@speakez.com Robert D. Thrush rd@phoenix.aii.com Robert Eckardt roberte@MEP.Ruhr-Uni-Bochum.de Robert P Ricci ricci@cs.utah.edu Robert Sanders rsanders@mindspring.com Robert Sexton robert@kudra.com Robert Shady rls@id.net Robert Swindells swindellsr@genrad.co.uk Robert Withrow witr@rwwa.com Robert Yoder unknown Robin Carey robin@mailgate.dtc.rankxerox.co.uk Rod Taylor rod@idiotswitch.org Roger Hardiman roger@cs.strath.ac.uk Roland Jesse jesse@cs.uni-magdeburg.de Roman Shterenzon roman@xpert.com Ron Bickers rbickers@intercenter.net Ron Lenk rlenk@widget.xmission.com Ronald Kuehn kuehn@rz.tu-clausthal.de Rudolf Cejka cejkar@dcse.fee.vutbr.cz Ruslan Belkin rus@home2.UA.net Ruslan Shevchenko rssh@cam.grad.kiev.ua Russell L. Carter rcarter@pinyon.org Russell Vincent rv@groa.uct.ac.za Ryan Younce ryany@pobox.com Ryuichiro IMURA imura@af.airnet.ne.jp Sakai Hiroaki sakai@miya.ee.kagu.sut.ac.jp Sakari Jalovaara sja@tekla.fi Sam Hartman hartmans@mit.edu Samuel Lam skl@ScalableNetwork.com Samuel Tardieu sam@inf.enst.fr Samuele Zannoli zannoli@cs.unibo.it Sander Janssen janssen@rendo.dekooi.nl Sander Vesik sander@haldjas.folklore.ee Sandro Sigala ssigala@globalnet.it SANETO Takanori sanewo@strg.sony.co.jp SASAKI Shunsuke ele@pop17.odn.ne.jp Sascha Blank blank@fox.uni-trier.de Sascha Wildner swildner@channelz.GUN.de Satoh Junichi junichi@astec.co.jp SAWADA Mizuki miz@qb3.so-net.ne.jp Scot Elliott scot@poptart.org Scot W. Hetzel hetzels@westbend.net Scott A. Kenney saken@rmta.ml.org Scott A. Moberly smoberly@xavier.dyndns.org Scott Blachowicz scott.blachowicz@seaslug.org Scott Burris scott@pita.cns.ucla.edu Scott Hazen Mueller scott@zorch.sf-bay.org Scott Michel scottm@cs.ucla.edu Scott Mitchel scott@uk.FreeBSD.org Scott Reynolds scott@clmqt.marquette.mi.us Sebastian Strollo seb@erix.ericsson.se Serge V. Vakulenko vak@zebub.msk.su Sergei Chechetkin csl@whale.sunbay.crimea.ua Sergei S. Laskavy laskavy@pc759.cs.msu.su Sergey Gershtein sg@mplik.ru Sergey Kosyakov ks@itp.ac.ru Sergey N. Vorokov serg@tmn.ru Sergey Potapov sp@alkor.ru Sergey Samoyloff gonza@techline.ru Sergey Shkonda serg@bcs.zp.ua Sergey Skvortsov skv@protey.ru Sergey V.Dorokhov svd@kbtelecom.nalnet.ru Sergio Lenzi lenzi@bsi.com.br Shaun Courtney shaun@emma.eng.uct.ac.za Shawn M. Carey smcarey@mailbox.syr.edu Shell Hung shell@shellhung.org Shigio Yamaguchi shigio@tamacom.com Shinya Esu esu@yk.rim.or.jp Shinya FUJIE fujie@tk.elec.waseda.ac.jp Shuichi Tanaka stanaka@bb.mbn.or.jp Simon simon@masi.ibp.fr Simon Burge simonb@telstra.com.au Simon Dick simond@irrelevant.org Simon J Gerraty sjg@melb.bull.oz.au Simon Marlow simonm@dcs.gla.ac.uk Simon Shapiro shimon@simon-shapiro.org Sin'ichiro MIYATANI siu@phaseone.co.jp Slaven Rezic eserte@cs.tu-berlin.de Soochon Radee slr@mitre.org Soren Dayton csdayton@midway.uchicago.edu Soren Dossing sauber@netcom.com Soren S. Jorvang soren@wheel.dk Stefan Bethke stb@hanse.de Stefan Eggers seggers@semyam.dinoco.de Stefan Moeding s.moeding@ndh.net Stefan Petri unknown Stefan `Sec` Zehl sec@42.org Eric D. Futch efutch@nyct.net Steinar Haug sthaug@nethelp.no Stephane E. Potvin sepotvin@videotron.ca Stephane Legrand stephane@lituus.fr Stephen Clawson sclawson@marker.cs.utah.edu Stephen F. Combs combssf@salem.ge.com Stephen Farrell stephen@farrell.org Stephen Hocking sysseh@devetir.qld.gov.au Stephen J. Roznowski sjr@home.net Stephen McKay syssgm@devetir.qld.gov.au Stephen Melvin melvin@zytek.com Steve Bauer sbauer@rock.sdsmt.edu Steve Coltrin spcoltri@unm.edu Steve Deering unknown Steve Gerakines steve2@genesis.tiac.net Steve Gericke steveg@comtrol.com Steve Piette steve@simon.chi.il.US Steve Schwarz schwarz@alpharel.com Steven Enderle panic@subphase.de Steven G. Kargl kargl@troutmask.apl.washington.edu Steven H. Samorodin samorodi@NUXI.com Steven McCanne mccanne@cs.berkeley.edu Steven Plite splite@purdue.edu Steven Wallace unknown Stijn Hoop stijn@win.tue.nl Stuart Henderson stuart@internationalschool.co.uk Sue Blake sue@welearn.com.au Sugimoto Sadahiro ixtl@komaba.utmc.or.jp SUGIMURA Takashi sugimura@jp.FreeBSD.org Sugiura Shiro ssugiura@duo.co.jp Sujal Patel smpatel@wam.umd.edu Sungman Cho smcho@tsp.korea.ac.kr Sune Stjerneby stjerneby@usa.net SURANYI Peter suranyip@jks.is.tsukuba.ac.jp Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jp Svein Skogen tds@nsn.no Sybolt de Boer bolt@xs4all.nl Tadashi Kumano kumano@strl.nhk.or.jp Taguchi Takeshi taguchi@tohoku.iij.ad.jp TAKAHASHI Kaoru kaoru@kaisei.org Takahiro Yugawa yugawa@orleans.rim.or.jp Takashi Mega mega@minz.org Takashi Uozu j1594016@ed.kagu.sut.ac.jp Takayuki Ariga a00821@cc.hc.keio.ac.jp Takeru NAIKI naiki@bfd.es.hokudai.ac.jp Takeshi Amaike amaike@iri.co.jp Takeshi MUTOH mutoh@info.nara-k.ac.jp Takeshi Ohashi ohashi@mickey.ai.kyutech.ac.jp Takeshi WATANABE watanabe@crayon.earth.s.kobe-u.ac.jp Takuya SHIOZAKI tshiozak@makino.ise.chuo-u.ac.jp Tatoku Ogaito tacha@tera.fukui-med.ac.jp Tatsuya Kudoh cdr@cosmonet.org Ted Buswell tbuswell@mediaone.net Ted Faber faber@isi.edu Ted Lemon mellon@isc.org Terry Lambert terry@lambert.org Terry Lee terry@uivlsi.csl.uiuc.edu Tetsuya Furukawa tetsuya@secom-sis.co.jp Theo de Raadt deraadt@OpenBSD.org Thomas thomas@mathematik.uni-Bremen.de Thomas D. Dean tomdean@ix.netcom.com Thomas David Rivers rivers@dignus.com Thomas E. Zander rriggs@f113.hadiko.de Thomas G. McWilliams tgm@netcom.com Thomas Graichen graichen@omega.physik.fu-berlin.de Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de Thomas Ptacek unknown Thomas Quinot thomas@cuivre.fr.eu.org Thomas A. Stephens tas@stephens.org Thomas Stromberg tstrombe@rtci.com Thomas Valentino Crimi tcrimi+@andrew.cmu.edu Thomas Wintergerst thomas@lemur.nord.de Þórður Ívarsson totii@est.is Thierry Thomas tthomas@mail.dotcom.fr Timothy Jensen toast@blackened.com Tim Kientzle kientzle@netcom.com Tim Singletary tsingle@sunland.gsfc.nasa.gov Tim Wilkinson tim@sarc.city.ac.uk Timo J. Rinne tri@iki.fi Tobias Reifenberger treif@mayn.de Todd Miller millert@openbsd.org Tom root@majestix.cmr.no Tom tom@sdf.com Tom Gray - DCA dcasba@rain.org Tom Jobbins tom@tom.tj Tom Pusateri pusateri@juniper.net Tom Rush tarush@mindspring.com Tom Samplonius tom@misery.sdf.com Tomohiko Kurahashi kura@melchior.q.t.u-tokyo.ac.jp Tony Kimball alk@Think.COM Tony Li tli@jnx.com Tony Lynn wing@cc.nsysu.edu.tw Tony Maher tonym@biolateral.com.au Torbjorn Granlund tege@matematik.su.se Toshihiko SHIMOKAWA toshi@tea.forus.or.jp Toshihiro Kanda candy@kgc.co.jp Toshiomi Moriki Toshiomi.Moriki@ma1.seikyou.ne.jp Trefor S. trefor@flevel.co.uk Trenton Schulz twschulz@cord.edu Trevor Blackwell tlb@viaweb.com Udo Schweigert ust@cert.siemens.de Ugo Paternostro paterno@dsi.unifi.it Ulf Kieber kieber@sax.de Ulli Linzen ulli@perceval.camelot.de URATA Shuichiro s-urata@nmit.tmg.nec.co.jp Uwe Arndt arndt@mailhost.uni-koblenz.de Vadim Belman vab@lflat.vas.mobilix.dk Vadim Chekan vadim@gc.lviv.ua Vadim Kolontsov vadim@tversu.ac.ru Vadim Mikhailov mvp@braz.ru Valentin Nechayev netch@lucky.net Van Jacobson van@ee.lbl.gov Vasily V. Grechishnikov bazilio@ns1.ied-vorstu.ac.ru Vasim Valejev vasim@uddias.diaspro.com Vernon J. Schryver vjs@mica.denver.sgi.com Veselin Slavov vess@btc.net Vic Abell abe@cc.purdue.edu Ville Eerola ve@sci.fi Vince Valenti vince@blue-box.net Vincent Poy vince@venus.gaianet.net Vincenzo Capuano VCAPUANO@vmprofs.esoc.esa.de Virgil Champlin champlin@pa.dec.com Vladimir A. Jakovenko vovik@ntu-kpi.kiev.ua Vladimir Kushnir kushn@mail.kar.net Vsevolod Lobko seva@alex-ua.com W. Gerald Hicks wghicks@bellsouth.net W. Richard Stevens rstevens@noao.edu Walt Howard howard@ee.utah.edu Walt M. Shandruk walt@erudition.net Warren Toomey wkt@csadfa.cs.adfa.oz.au Wayne Scott wscott@ichips.intel.com Werner Griessl werner@btp1da.phy.uni-bayreuth.de Wes Santee wsantee@wsantee.oz.net Wietse Venema wietse@wzv.win.tue.nl Wiljo Heinen wiljo@freeside.ki.open.de Willem Jan Withagen wjw@surf.IAE.nl William Jolitz withheld William Liao william@tale.net Wojtek Pilorz wpilorz@celebris.bdk.lublin.pl Wolfgang Helbig helbig@ba-stuttgart.de Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@FreeBSD.org Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW &a.wylie; Yarema yds@ingress.com Yaroslav Terletsky ts@polynet.lviv.ua Yasuhiro Fukama yasuf@big.or.jp Yasuhito FUTATSUKI futatuki@fureai.or.jp Yen-Ming Lee leeym@bsd.ce.ntu.edu.tw Yen-Shuo Su yssu@CCCA.NCTU.edu.tw Yin-Jieh Chen yinjieh@Crazyman.Dorm13.NCTU.edu.tw Yixin Jin yjin@rain.cs.ucla.edu Yoichi Asai yatt@msc.biglobe.ne.jp Yoichi Nakayama yoichi@eken.phys.nagoya-u.ac.jp Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp Yoshihiko SARUMRU mistral@imasy.or.jp Yoshihisa NAKAGAWA y-nakaga@ccs.mt.nec.co.jp Yoshikazu Goto gotoh@ae.anritsu.co.jp Yoshimasa Ohnishi ohnishi@isc.kyutech.ac.jp Yoshishige Arai ryo2@on.rim.or.jp Yuichi MATSUTAKA matutaka@osa.att.ne.jp Yujiro MIYATA miyata@bioele.nuee.nagoya-u.ac.jp Yu-Shun Wang yushunwa@isi.edu Yusuke Nawano azuki@azkey.org Yuu Yashiki s974123@cc.matsuyama-u.ac.jp Yuuki SAWADA mami@whale.cc.muroran-it.ac.jp Yuuichi Narahara aconitum@po.teleway.ne.jp Yuval Yarom yval@cs.huji.ac.il Yves Fonk yves@cpcoup5.tn.tudelft.nl Yves Fonk yves@dutncp8.tn.tudelft.nl Zach Heilig zach@gaffaneys.com Zach Zurflu zach@pabst.bendnet.com Zahemszhky Gabor zgabor@code.hu Zhong Ming-Xun zmx@mail.CDPA.nsysu.edu.tw 386BSD パッチキットへのパッチ提供者 (名前でアルファベット順): Adam Glass glass@postgres.berkeley.edu Adrian Hall ahall@mirapoint.com Andrey A. Chernov ache@astral.msk.su Andrew Herbert andrew@werple.apana.org.au Andrew Moore alm@netcom.com Andy Valencia ajv@csd.mot.com jtk@netcom.com Arne Henrik Juul arnej@Lise.Unit.NO Bakul Shah bvs@bitblocks.com Barry Lustig barry@ictv.com Bob Wilcox bob@obiwan.uucp Branko Lankester Brett Lymn blymn@mulga.awadi.com.AU Charles Hannum mycroft@ai.mit.edu Chris G. Demetriou cgd@postgres.berkeley.edu Chris Torek torek@ee.lbl.gov Christoph Robitschko chmr@edvz.tu-graz.ac.at Daniel Poirot poirot@aio.jsc.nasa.gov Dave Burgess burgess@hrd769.brooks.af.mil Dave Rivers rivers@ponds.uucp David Dawes dawes@physics.su.OZ.AU David Greenman dg@Root.COM Eric J. Haug ejh@slustl.slu.edu Felix Gaehtgens felix@escape.vsse.in-berlin.de Frank Maclachlan fpm@crash.cts.com Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Geoff Rehmet csgr@alpha.ru.ac.za Goran Hammarback goran@astro.uu.se Guido van Rooij guido@gvr.org Guy Antony Halse guy@rucus.ru.ac.za Guy Harris guy@auspex.com Havard Eidnes Havard.Eidnes@runit.sintef.no Herb Peyerl hpeyerl@novatel.cuc.ab.ca Holger Veit Holger.Veit@gmd.de Ishii Masahiro, R. Kym Horsell J.T. Conklin jtc@cygnus.com Jagane D Sundar jagane@netcom.com James Clark jjc@jclark.com James Jegers jimj@miller.cs.uwm.edu James W. Dolter James da Silva jds@cs.umd.edu et al Jay Fenlason hack@datacube.com Jim Wilson wilson@moria.cygnus.com Jörg Lohse lohse@tech7.informatik.uni-hamburg.de Jörg Wunsch joerg_wunsch@uriah.heep.sax.de John Dyson John Woods jfw@eddie.mit.edu Jordan K. Hubbard jkh@whisker.hubbard.ie Julian Elischer julian@dialix.oz.au Julian Stacey jhs@FreeBSD.org Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com karl@one.neosoft.com Keith Bostic bostic@toe.CS.Berkeley.EDU Ken Hughes Kent Talarico kent@shipwreck.tsoft.net Kevin Lahey kml%rokkaku.UUCP@mathcs.emory.edu kml@mosquito.cis.ufl.edu Konstantinos Konstantinidis kkonstan@duth.gr Marc Frajola marc@dev.com Mark Tinguely tinguely@plains.nodak.edu tinguely@hookie.cs.ndsu.NoDak.edu Martin Renters martin@tdc.on.ca Michael Clay mclay@weareb.org Michael Galassi nerd@percival.rain.com Mike Durkin mdurkin@tsoft.sf-bay.org Naoki Hamada nao@tom-yam.or.jp Nate Williams nate@bsd.coe.montana.edu Nick Handel nhandel@NeoSoft.com nick@madhouse.neosoft.com Pace Willisson pace@blitz.com Paul Kranenburg pk@cs.few.eur.nl Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Peter da Silva peter@NeoSoft.com Phil Sutherland philsuth@mycroft.dialix.oz.au Poul-Henning Kamp phk@FreeBSD.org Ralf Friedl friedl@informatik.uni-kl.de Rick Macklem root@snowhite.cis.uoguelph.ca Robert D. Thrush rd@phoenix.aii.com Rodney W. Grimes rgrimes@cdrom.com Sascha Wildner swildner@channelz.GUN.de Scott Burris scott@pita.cns.ucla.edu Scott Reynolds scott@clmqt.marquette.mi.us Sean Eric Fagan sef@kithrup.com Simon J Gerraty sjg@melb.bull.oz.au sjg@zen.void.oz.au Stephen McKay syssgm@devetir.qld.gov.au Terry Lambert terry@icarus.weber.edu Terry Lee terry@uivlsi.csl.uiuc.edu Tor Egge Tor.Egge@idi.ntnu.no Warren Toomey wkt@csadfa.cs.adfa.oz.au Wiljo Heinen wiljo@freeside.ki.open.de William Jolitz withheld Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@dentaro.GUN.de Yuval Yarom yval@cs.huji.ac.il diff --git a/ja_JP.eucJP/books/handbook/advanced-networking/chapter.sgml b/ja_JP.eucJP/books/handbook/advanced-networking/chapter.sgml index 0ce5b8c0c9..c7c5130388 100644 --- a/ja_JP.eucJP/books/handbook/advanced-networking/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/advanced-networking/chapter.sgml @@ -1,2936 +1,2936 @@ 高度なネットワーク この章では 以下の章では, UNIX システム上で良く利用されるネットワークサービスについて書かれています. これはもちろん, あなたの FreeBSD システムでの, そのようなサービスの設定に関する内容です. ゲートウェイとルート 原作: &a.gryphon;. 1995 年 10 月 6 日. 訳: &a.jp.yuki;. 1996 年 9 月 6 日. あるマシンが他のマシンをみつけることができるようにするには, あるマシンから他のマシンへ, どのようにたどり着くかを適切に記述するための仕組みが必要です. この仕組みをルーティングと呼びます. ルート(経路)は destination (目的地) と gateway (ゲートウェイ) の 2 つのアドレスの組で定義します. あなたが destination へアクセスしようとした場合, gateway を通って送られることをこのペアは示しています. destination には個々のホスト, サブネット, デフォルト の 3つの タイプがあります. デフォルトルート は他への経路が適用できない 場合に使われます. のちほどデフォルトルートについて少し述べること するとして, ここでは, 個々のホスト, インタフェース (リンク とも呼ばれます), イーサネットハードウェアアドレスという 3つのタイ プのゲートウェイについて説明します. 例 以下に示す netstat -r の出力の例を使って, ルーティン グがいろいろと異なっている様子を説明することにします. Destination Gateway Flags Refs Use Netif Expire default outside-gw UGSc 37 418 ppp0 localhost localhost UH 0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 10.20.30.255 link#1 UHLW 1 2421 foobar.com link#1 UC 0 0 host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => host2.foobar.com link#1 UC 0 0 224 link#1 UC 0 0 最初の2行はデフォルトルート(次の節で詳しく説明します)と, localhostへの経路を示しています. localhostのためのインタフェース (Netifの欄) はlo0で, これはループバックデバイスとして知られています. 結局のところ戻るだけなので, この destinationへのすべてのトラフィックが 内部的に処理されるのであって, LAN を経由して送られるのではありません. 次の行では 0:e0:... というアドレスに注目しましょう. これはイーサネットハードウェアアドレスです. FreeBSDは自動的に ローカルなイーサネット上の任意のホスト (この例ではtest0) を見つけ, イーサネットインタフェース ed0 の所にそのホストへの経路を直接つけ加えます. タイムアウト時間 (Expireの 欄) も経路のタイプと結びついており, 指定された時間が経過しても応 答がないときに使用します. この場合, 経路情報は自動的に削除されま す. これらのホストは, RIP(Routing Information Protocol) という, 最短パスの判定に基づいてローカルホストへの経路を 決定する仕組みを利用することで認識されます. 更に, FreeBSDではローカルサブネット (10.20.30.255 は 10.20.30 というサブネットに対するブロードキャストアドレスで, foobar.com はこのサブネットに結びつけられているドメイン名) への経路情報も加えることができます. link#1というのは, このマシンの最初のイーサネットカードのことをさします. これら については, 何も追加インタフェースが指定されていないことに気づく でしょう. これらの2つのグループ(ローカルネットワークホストと ローカルサブネット) の両方とも, routed と呼ばれるデーモンによって自動的に経路が設定されます. routed を動かさなければ, 静的に定義した (つまり具体的に設定した) 経路のみ存在することになります. host1 の行は私たちのホストのことで, イーサネットアドレスで示されています. 送信側のホストの場合, FreeBSDはイーサネットインタフェースへ送るのではなく, ループバックインタフェース (lo0)を使います. 2つあるhost2の行は, ifconfigのエイリアス (このようなことをする理由については ethernetの章を参照してください) を使ったとき にどのようになるかを示す例です. lo0の後にある=> は, インタフェースが (このアドレスがローカルなホストを参照しているので) ループバックを使っているというだけでなく, エイリアスになっていることも示しています. このような経路はエイリアスをサポートしている ホストにのみ現れます. ローカルネットワーク上の他のすべてのホストでは 単にlink#1となります. 最後の行 (destinationが224のサブネット) はマルチキャストで扱うものですが, これは他の章で説明します. 他の欄については Flags について説明する必要があります. それぞれの経路は欄に示されているように違った属性を もっています. 以下にいくつかのフラグとこれらが何を意味しているかを示します. U Up: この経路はアクティブです. H Host: 経路の destinationが単一のホストです. G Gateway: この destinationへ送られると, どこへ送れ ばよいかを明らかにして, そのリモートシステムへ送られます. S Static: この経路はシステムによって自動的に生成 されたのではなく, 手動で作成されました. C Clone: マシンに接続したときにこの経路に基づく 新しい経路が作られます. このタイプの経路は通常は ローカルネットワークで使われます. W WasCloned: ローカルエリアネットワーク(Clone) の経路に基づいて 自動的に生成された経路であることを示します. L Link: イーサネットハードウェアへの参照を含む 経路です. デフォルトルート ローカルシステムからリモートホストにコネクションを張る 必要がある場合, 既知のパスが存在するかどうかを確認するためにル ーティングテーブルをチェックします. 到達するためのパスを知っているサブネットの内部に リモートホストがある場合 (Cloned routes), システムはインタフェース から接続できるかどうかをチェックします. 知っているパスがすべて駄目だった場合でも, システムには 最後の切り札の デフォルト ルートがあります. このルートは ゲートウェイルート (普通はシステムに 1つしかありません) の特別なものです. そして, フラグフィールドは必ず c がマークされています. このゲートウェイは, LAN 内のホストにとっ て, 外部 (PPPのリンクを経由する場合や, データラインに接続するハードウェアデバイスなど) へ直接接続するマシンすべてのためのものです. 外部に対するゲートウェイとして機能するマシンで デフォルトルートを設定する場合, デフォルトルートはインターネットサービスプロバイダ (ISP) のサイトのゲートウェイマシンになるでしょう. それではデフォルトルートの一例を見てみましょう. 一般的な構成を示します. [Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW] ホスト Local1 とホスト Local2 を PPP で ISP のターミナルサーバと接続されているあなたの サイトだとします. ISP はサイト内にロー カルなネットワークを持っていて, そこにはまざまなものがあり, あなたの接続するサーバや ISP のインターネットへの 接続点であるハードウェアデバイス (T1-GW) などがあります. あなたのマシンのデフォルトルートは それぞれ次のようになります. host default gateway interface Local2 Local1 ethernet Local1 T1-GW PPP なぜ (あるいは, どうやって) Local1 の デフォルトゲートウェイをISPのサーバでなく T1-GWにセットするのか という質問がよくあります. コネクションのローカルの側については, PPPのインタフェースは ISPのローカルネットワーク上のアドレスを用いているため, ISPのローカルネットワーク上のすべてのマシンへの経路は 自動的に生成されています. つまり, あなたのマシンは, どのようにT1-GW まで届くかという経路を既に知っていることになりますから, ISPサーバに媒介的なトラフィックをかける必要はありません. 最後になりましたが, 一般的にローカルネットワークでは ...1 というアドレスをゲートウェイアドレスとして使います. ですから (同じ例を用います), あなたのclass-Cのアドレス空間が 10.20.30で ISPが 10.9.9を用いている場合, デフォルトルートは次のようになります. Local2 (10.20.30.2) --> Local1 (10.20.30.1) Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1) マルチホームホスト ここで扱うべき他のタイプの設定があります. それは2つの異なるネットワークにまたがるホストです. 技術的にはゲートウェイとして機能するマシン (上 の例では PPPコネクションを用いています) はマルチホームホストで す. しかし実際にはこの言葉は, 2つのローカルエリアネットワーク上のサ イトであるマシンを指す言葉としてのみ使われます. 2枚のイーサネットカードを持つマシンが, 別のサブネット 上にそれぞれアドレスを持っている場合があります. あるいは, イーサネットカードを1枚持っているマシンで, ifconfigのエイリアスを使っているかもしれません. 物理的に分かれている2つのイーサネットのネットワークが使われて いるならば前者が用いられます. 後者は, 物理的には1つのネットワ ークセグメントで, 論理的には分かれている 2つのサブネットとする 場合に用いられます. どちらにしても, このマシンがお互いのサブネットへのゲートウェイ (inbound route) として定義されていることが分かるように, おのお ののサブネットでルーティングテーブルを設定します. このマシンが 2 つのサブネットの間のブリッジとして動作するという構成は, パケ ットのフィルタリングを実装する必要がある場合や, 一方向または双 方向のファイアウォールを利用したセキュリティを構築する場合によ く用いられます. ルーティングの伝播 すでに外部との経路をどのように定義したらよいかは 説明しました. しかし外部から私たちのマシンをどのようにして 見つけるのかについては説明していません. ある特定のアドレス空間 (この例では class-C のサブネット) におけるすべてのトラフィックが, 到着したパケットを内部で転送するネ ットワーク上の特定のホストに送られるようにルーティングテーブル を設定することができるのは分かっています. あなたのサイトにアドレス空間を割り当てる場合, あなたのサブネットへのすべてのトラフィックがすべて PPPリンクを通じてサイトに送 ってくるようにサービスプロバイダはルーティングテーブルを設定し ます. しかし, 国境の向こう側のサイトはどのようにしてあなたの ISPへ送ることを知るのでしょうか? 割り当てられているすべてのアドレス空間の経路を維持する (分散している DNS 情報とよく似た) システムがあり, そのインターネット バックボーンへの接続点を定義しています. バックボーン とは国を越え, 世界中のインターネットのトラフィックを運ぶ主要 な信用できる幹線のことです. どのバックボーンマシンも, あるネットワークから特定のバックボーンのマシンへ 向かうトラフィックと, そのバックボーンのマシンからあなたのネットワークに届くサービス プロバイダまでのチェーンのマスタテーブルのコピーを持っていま す. あなたのサイトが接続(プロバイダからみて内側にある ことになります) したということを, プロバイダからバックボー ンサイトへ通知することはプロバイダの仕事です. これが経 路の伝搬です. トラブルシューティング ルーティングの伝搬に問題が生じて, いくつかのサイトが 接続をおこなうことができなくなることがあります. ルーティングがどこでおかしくなっているかを明らかにするのに 最も有効なコマンドはおそらく &man.traceroute.8; コマンドでしょ う. このコマンドは, あなたがリモートマシンに対して接続をおこなう ことができない(例えば &man.ping.8; に失敗するような場合) 場合も, 同じように有効です. &man.traceroute.8; コマンドは, 接続を試みているリモートホストを引数にして実行します. 試みているパスの経由するゲートウェイホストを表示し, 最終的には目的のホストにたどり着くか, コネクションの欠如によって終ってしまうかのどちら かになります. より詳しい情報は, &man.traceroute.8; のマニュアルページをみてください. Bridging Written by Steve Peterson steve@zpfe.com. はじめに IP サブネットを作成し, それらのセグメントをルータを 使って接続したりせずに, (Ethernet セグメントのような) 物理ネットワークを二つのネットワークセグメントに分割することは とても有効な場合があります. このような二つのネットワークを繋ぐデバイスはブリッジと呼ばれます. そして, 二つのネットワークインターフェイスカードを持つ FreeBSD システムは, ブリッジとして動作することができます. ブリッジは, 各ネットワークインターフェイスに繋がる デバイスの MAC 層のアドレス (例えば Ethernet アドレス) を記憶します. ブリッジはトラフィックの送信元と受信先が異なったネットワーク上に ある場合にのみ, トラフィックを転送します. すなわち, ブリッジはポート数の少ない Ethernet スイッチ だ, ということができます. ブリッジがふさわしい状況とは 今日ブリッジが活躍する場面は大きく分けて二つあります. トラフィックの激しいセグメント ひとつは, 物理ネットワークセグメントがトラフィック 過剰になっているが, なんらかの理由によりネットワークを サブネットに分け, ルータで接続することができない場合です. 編集部門と製作部門がおなじサブネットに同居している 新聞社を例に考えてみましょう. 編集部門のユーザはファイルサーバとして全員サーバ A を利用し, 製作部門のユーザはサーバ B を利用します. すべてのユーザを接続するのには Ethernet が使われており, 高負荷となったネットワークは遅くなってしまいます. もし編集部門のユーザを一つのネットワークセグメントに 分離することができ, 製作部門もユーザも同様にできるのなら, 二つのネットワークセグメントをブリッジで繋ぐことができます. ブリッジの "反対" 側へ向かうネットワークトラフィックだけが 転送され, 各ネットワークセグメントの混雑は緩和されます. パケットフィルタ/帯域制御用ファイアウォール もうひとつは, IP Masquerading (NAT) を使わずに ファイアウォール機能を利用したい場合です. ここでは DSL もしくは ISDN で ISP に接続している 小さな会社を例にとってみましょう. この会社は ISP から 13 個のグローバル IP アドレスの割り当て を受けており, ネットワーク内には 10 台の PC が存在します. このような状況では, サブネット化にまつわる問題から ルータを用いたファイアウォールを利用することは困難です. ブリッジを用いたファイアウォールなら, IP アドレスの問題を気にすること無く, DSL/ISDN ルータの 下流側に置くように設定できます. ブリッジを設定する ネットワークインターフェイスカードの選択 ブリッジを利用するには少なくとも二つのネットワークカードが 必要です. 残念なことに, FreeBSD 4.0 ではすべてのネットワークインターフェイス カードがブリッジ機能をサポートしているわけではありません. カードがサポートされているかどうかについては &man.bridge.4; を参照してください. 以下に進む前に, 二つのネットワークカードをインストールして テストしてください. カーネルコンフィグレーションの変更 カーネルでブリッジ機能を有効にするには options BRIDGE という行をカーネルコンフィグレーションファイルに追加して カーネルを再構築してください. ファイアウォール機能 ブリッジと同時にファイアウォール機能も利用しようとしている 場合には, IPFIREWALL オプションも指定する必要があります. ブリッジをファイアウォールとして設定する際の一般的な 情報に関しては, を参照してください. IP 以外のパケット (ARP など) がブリッジを通過するように するためには, ドキュメント化されていないファイアウォール用 オプションを設定する必要があります. このオプションは IPFIREWALL_DEFAULT_TO_ACCEPT です. この変更により, デフォルトではファイアウォールがすべての パケットを accept するようになることに注意してください. この設定を行う前に, この変更が自分のルールセットにどのような 影響をおよぼすかを把握しておかなければなりません. 帯域制御機能 ブリッジで帯域制御機能を利用したい場合, カーネルコンフィグレーションで DUMMYNET オプションを加える必要があります. 詳しい情報に関しては &man.dummynet.4; を参照 してください. ブリッジを有効にする ブリッジを有効にするには, /etc/sysctl.conf に以下の行を加えてください: net.link.ether.bridge=1 ブリッジを経由したパケットを ipfw でフィルタしたい場合には, net.link.ether.bridge_ipfw=1 という行も付け加える必要があります. パフォーマンス 私のブリッジ/ファイアウォールは Pentium 90 で, 3Com 3C900B と 3c905B を使っています. 防護される側のネットワークは 10Mbps の half duplex で, ブリッジとルータ (Cisco 675) の間は 100Mbps full duplex で 動作しています. パケットフィルタを利用しない場合, 防護されている 10Mbps ネットワークから Cisco 675 への ping では, ブリッジにより 0.4 ミリ秒の遅延が発生しています. その他の情報 ネットワークからブリッジに telnet したい場合, ネットワークカードの一つに IP アドレスを割り当てれば OK です. 一般的に, 両方のカードに IP アドレスを割り当てるのは よいアイデアではないとされています. ネットワーク内に複数のブリッジを設置する場合, 任意のワークステーション間で一つ以上の経路を持つことは できません. 技術的には, これは spanning tree link management はサポートされていない, ということを意味します. NFS Written by &a.unfurl;, 4 March 2000. FreeBSD がサポートしている多くのファイルシステムの中でも, NFS, すなわち Network File System は極めてユニークな存在です. NFS はあるマシンから他のマシンへと, ネットワークを通じて ディレクトリとファイルを共有することを可能にします. NFS を使うことで, ユーザやプログラムはリモートシステムのファイルを, それがローカルファイルであるかのようにアクセスすることができます. NFS には以下の利点があります: 一般的に使われるデータを単一のマシンに納める ことができ, ネットワーク上のユーザはデータにアクセスできる ため, ローカルワークステーションは多くのディクスを 必要としません. ネットワーク上のすべてのマシンに, ユーザが独自のホームディレクトリを持つ必要がありません. 一旦 NFS 経由でアクセスできるディレクトリができれば, どこからでもアクセス可能です. フロッピーや CD-ROM ドライブなどのストレージデバイスを, 追加のハードウェアなしにネットワーク上の他のマシンに 使ってもらうことができます. どのようにして動作するのか NFS はクライアント, サーバの二つの部分から 構成されます. これは 需要(want)/供給(have) の関係として考えることができます. クライアントはサーバが 供給 している データに対する 需要 があります. サーバはそのデータをクライアントと共有します. このシステムが適切に機能するために, いくつかのプロセスが 設定され正しく動作していなければなりません. サーバは以下のデーモンを動作させなければなりません: nfsd - NFS クライアントからの リクエストを処理する NFS デーモン. mountd - nfsd から渡された リクエストを実際に実行する NFS マウントデーモン. portmap - NFS サーバの利用しているポートを NFS クライアントから取得できるようにするためのポートマッパデーモン. クライアント側ではデーモンを一つ実行する必要があります: nfsiod - NFS サーバからのリクエストを 処理する NFS 非同期 I/O デーモン. NFS を設定する 幸運なことに, FreeBSD システムで設定を行うのは簡単です. 実行させなければならないプロセスは, /etc/rc.conf ファイルをちょっと編集することでブート時から実行させる ことができます. NFS サーバでは, 以下の設定が必要です: portmap_enable="YES" nfs_server_enable="YES" nfs_server_flags="-u -t -n 4" mountd_flags="-r" mountd は NFS サーバが有効になっている 場合, 自動的に実行されます. nfsd への , フラグは クライアントに UDP と TCP のサービスを提供することを指示します. フラグは nfsd が 4 つのコピーを立ち上げることを指示します. クライアント側では, 以下のようにします: nfs_client_enable="YES" nfs_client_flags="-n 4" nfsd と同様に, は nfsiod が 4 つのコピーを立ち上げることを指示します. 最後に /etc/exports という 設定ファイルを作成します. exports ファイルはサーバのどのファイルシステムが 共有されるのか (exported といいます), またどのクライアントが共有できるのかを指定します. ファイル中の各行は, 共有されるファイルシステムを 指定します. ファイル中で指定できるオプションはたくさんありますが, そのうちの少ししか使うことはないでしょう. より細かいことに関しては &man.exports.5; マニュアルページをお読み下さい. いくつか /etc/exports の設定例 を示します: 以下の設定は, サーバと同じドメイン名(ドメイン名が無いので)か, /etc/hosts に記述のある三つのマシン に対して, /cdrom を export します. オプションは共有されるファイルシステムを 読み込み専用にします. このフラグにより, リモートシステムは共有されたファイルシステム にたいして何の変更も行えなくなります. /cdrom -ro moe larry curly 以下の設定は, IP アドレスによる三つのホストに対して /home を export します. この設定はプライベートネットワークで DNS が走っていない 場合に便利な設定でしょう. フラグは指定されたファイルシステム 以下のディレクトリに対しても同様に export します. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 以下の設定は, サーバとは異なるドメイン名の二つの マシンに対して /a を export します. フラグは, リモートマシンの root ユーザが共有されたファイルシステムに root として書き込むことを 許可します. -maproot=0 フラグが無ければ, リモートマシンの root 権限を 持っていても共有されたファイルシステム上のファイルを変更する ことはできません. /a -maproot=0 host.domain.com box.example.com クライアントが export されたファイルシステムを共有 する際には, そのような権限が与えられていなければなりません. /etc/exports ファイルに クライアントが含まれているかどうか確認してください. 必要な変更はすべて行ったので, FreeBSD を再起動してブート時からすべてが起動するようにするか, root で以下のコマンドを実行します: NFS サーバでは: &prompt.root; portmap &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r NFS クライアントでは: &prompt.root; nfsiod -n 4 これでリモートのファイルシステムを実際にマウントする 準備ができました. やり方は二通りあります. この例では, サーバの名前は server で, クライアントの名前は client とします. リモートファイルシステムを一時的にマウントするだけ, もしくは設定をテストするだけなら, クライアント上で root として以下のコマンドを実行してください: &prompt.root; mount server:/home /mnt これにより, クライアントの /mnt ディレクトリにサーバの /home が マウントされます. もしすべてが正しく設定されていれば, クライアントの /mnt に, サーバにあるファイルすべてが見えるようになっているはずです. リモートファイルシステムを今後も (リブートする度に) マウントしたいなら, /etc/fstab ファイルに設定を追加する必要があります. 例としてはこのようになります: server:/home /mnt nfs rw 0 0 ほかのオプションに関しては &man.fstab.5; マニュアル ページをお読み下さい. 典型的な使い方 NFS にはいくつかすてきな使い方があります. 私は自分が管理している LAN でそれらを利用しています. そのうちにいくつかをここで紹介しましょう. ネットワークには幾つかのマシンがありますが, CD-ROM ドライブを持っているのは一台だけです. なぜかって? それは一台の CD-ROM ドライブをほかのマシンと NFS 経由で共有しているからです. フロッピードライブについても同じことがいえます. ネットワーク内に多くのマシンがあると, 様々な場所に ちらばる個人的なファイルは日に日に古くなってしまいます. 私はすべてのユーザのホームディレクトリを格納する, 中心となる NFS サーバを用意し, LAN 上の残りのマシンと 共有しています. そうすることで, どこにログインしても, 同じホームディレクトリを使うことができるのです. マシンのひとつに FreeBSD を再インストールするなら, NFS こそその方法です. ディストリビューション CD をファイル サーバに入れ, 再インストールを実行するだけです. 共用の /usr/ports/distfiles ディレクトリを用意して, すべてのマシンで共有しています. この方法だと, 別のマシンで既にインストールしたことのある port をインストールする場合, 再びすべてのソースをダウンロードする 必要がなくなります. Problems integrating with other systems - 原作: &a.jlind;. + 原作: John Lind john@starfire.MN.ORG. 訳: &a.jp.tomo;. 6 September 1996. ISA用のイーサネットアダプタの中には性能が悪いため, ネットワーク, 特に NFS で深刻な問題がおきるものがあります. これは FreeBSD に限ったことではありませんが, FreeBSD でも起こり得ます. この問題は, (FreeBSDを使用した) PC がシリコン・グラフィックス社や サン・マイクロシステムズ社などの高性能な WS にネットワーク接続されている場合に頻繁に起こります. NFS マウントはうまく行きます. また, いくつかの操作もうまく働きますが, 他のシステム (WS) に対する要求や応答は続いていても, 突然サーバが クライアントの要求に対して反応しなくなります. これは, クライアントが FreeBSD か上記の WS であるとき, にクライアント側に起きる現象です. 多くのシステムでは, いったんこの問題が現われると, 行儀良くクライアントを終了する手段はありません. NFS がこの状態に陥ってしまうと, 正常に戻すことはできないため, 多くの場合, クライアントを強制終了し, 再び実行することが唯一の解決法となります. 正しい解決法は, より高性能のイーサネットアダプタをFreeBSDシステムに インストールすることですが, 満足な操作ができるような簡単な方法があります. もし, FreeBSDシステムがサーバになるのなら, クライアントからのマウント時に オプションをつけて下さい. もしFreeBSDシステムがクライアントになる のなら, NFSファイルシステムを オプションつきでマウントして下さい. これらのオプションは自動的にマウントをおこなう場合には クライアントの fstab エントリの4番目のフィールドに指定してもよいですし, 手動マウントの場合は mount コマンドの パラメータで指定してもよいでしょう. NFSサーバとクライアントが別々のネットワーク上にあるような 場合, これと間違えやすい他の問題が起きることに注意して下さい. そのような場合は, ルータが必要な UDP 情報をきちんと ルーティングしているかを確かめて下さい. そうでなければ, たとえあなたが何をしようと解決できないでしょう. 次の例では, fastwsは高性能のWSのホスト (インタフェース)名で, freeboxは低性能のイーサネットアダプタを備えた FreeBSDシステムのホスト(インタフェース)名です. また, /sharedfs はエクスポートされる NFS ファイルシステムであり (man exports を見て下さい), /project はエクスポートされたファイルシステムの クライアント上のマウントポイントとなります. 全ての場合において, や , といった追加オプションが アプリケーションにより要求されるかもしれないことに 注意して下さい. クライアント側 FreeBSD システム (freebox) の例は: freebox の /etc/fstab に次のように書いて下さい: fastws:/sharedfs /project nfs rw,-r=1024 0 0 freebox 上で手動で mount コマンドを実行する場合は次のようにして下さい: &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project サーバ側FreeBSDシステムの例は: fastws の /etc/fstab に次のように書いて下さい: freebox:/sharedfs /project nfs rw,-w=1024 0 0 fastws 上で手動で mount コマンドで実行する場合は次のようにして下さい: &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project 近いうちにどのような 16 ビットのイーサネットアダプタでも 上記の読み出し, 書き込みサイズの制限なしの操作ができるようになるでしょう. 失敗が発生したとき何が起きているか関心のある人に, なぜ回復不可能なのかも含めて説明します. NFSは通常 (より小さいサイズへ分割されるかもしれませんが) 8Kのブロック サイズで働きます. イーサネットのパケットサイズは最大1500バイト程度なので, 上位階層のコードにとっては1つのユニットのままなのですが, NFS ブロックは 複数のイーサネットパケットに分割されます. そして受信され, 組み立て直されてから肯定応答 されなければなりません. 高性能のWSは次々に NFSユニットを構成するパケットを, 基準の範囲内で間隔を詰めて次々に送り出すことができます. 小さく, 容量の低いカードでは, 同じユニットの 前のパケットがホストに転送される前に, 後のパケットがそれを 踏みつぶしてしまいます. このため全体としてのユニットは再構成もされないし, 肯定応答もされません. その結果, WSはタイムアウトして再送を試みますが, 8Kのユニット全体を再送しようとするので, このプロセスは 際限無く繰り返されてしまいます. ユニットサイズをイーサネットのパケットサイズの 制限以下に抑えることにより, 受信された完全な イーサネットパケットは個々に肯定応答を受けられることが 保証されるので, デッドロック状態を避けることができるようになります. 高性能のカードを使っている場合でも, 高性能な WS が力任せに次々と PC システムにデータを送ったときには 踏みつぶし が起きるかもしれません. そのような踏みつぶし は NFS ユニット では保証されていません. 踏みつぶしが起こったとき, 影響を受けたユニットは再送されます. そして受信され, 組み立てられ, 肯定応答される公平な機会が与えられるでしょう. Diskless operation 原作: &a.martin; 訳: &a.jp.yasu; netboot.com/netboot.rom によって, ディスクのないクライアントでネットワーク経由で FreeBSD マシンのブートを行い FreeBSD を走らせることができます. 2.0 ではローカルなスワップを持つことができます. NFS 経由のスワッピングもサポートされています. サポートされているイーサネットカード: Western Digital/SMC 8003, 8013, 8216 とその互換ボード, NE1000/NE2000 とその互換カード (再コンパイルが必要) セットアップの手順 サーバにするマシンを見つけます. このマシンには, FreeBSD 2.0のバイナリとbootpを 記憶するだけの十分なディスクスペースが必要です. tftp と NFS も使えます. テストしたマシン: HP9000/8xx / HP-UX 9.04以降 (9.04以前では動きません) Sun/Solaris 2.3. (bootpが必要) クライアントにIP,gateway,netmaskを提供する bootpサーバをセットアップします. diskless:\ :ht=ether:\ :ha=0000c01f848a:\ :sm=255.255.255.0:\ :hn:\ :ds=192.1.2.3:\ :ip=192.1.2.4:\ :gw=192.1.2.5:\ :vm=rfc1048: クライアントにブート情報を提供する TFTP サーバを (bootp サーバと同じマシンに) セットアップします. このファイルの名前は, cfg.X.X.X.X (もしくは /tftpboot/cfg.X.X.X.X )で, ここで X.X.X.X はクライアントの IP アドレスです. このファイルの内容は netboot コマンドで有効です. 2.0では, netboot は以下のようなコマンドを持ちます: help helpリストの表示 ip クライアントのIPアドレスの表示/セット server bootp/tftp サーバのアドレスの表示/セット netmask netmaskの表示/セット hostname name hostnameの表示/セット kernel カーネル名の表示/セット rootfs root ファイルシステムの表示/セット swapfs swap ファイルシステムの表示/セット swapsize diskless swapsize を KBytes単位でセット diskboot ディスクからのブート autoboot ブートプロセスの続行 trans | トランシーバのオン|オフ flags ブートフラグの設定 完全にディスクレスな場合の一般的な cfg ファイルは以下のようになります: rootfs 192.1.2.3:/rootfs/myclient swapfs 192.1.2.3:/swapfs swapsize 20000 hostname myclient.mydomain ローカルに swap を持つマシンについては以下のようになります: rootfs 192.1.2.3:/rootfs/myclient hostname myclient.mydomain NFS サーバがクライアントにroot(必要ならswapも) ファイルシステムをexportしているか, また, クライアントがこれらのファイルシステムに ルートアクセスできるか確認します. FreeBSDにおける一般的な /etc/exports ファイルは 以下のようになります: /rootfs/myclient -maproot=0:0 myclient.mydomain /swapfs -maproot=0:0 myclient.mydomain そして, HP-UX側では以下のようになります: /rootfs/myclient -root=myclient.mydomain /swapfs -root=myclient.mydomain NFS経由でスワッピングを行う場合 (完全にディスクレスな場合の設定), クライアントが使用する swap ファイルを dd で作成します. もし, swapfs コマンドが上記の例のように 引数 /swapfsを持ちそのサイズが 20000 である場合, myclientに対するスワップファイルは /swapfs/swap.X.X.X.X で呼び出されます. ここで X.X.X.X はクライアントの IP アドレスです. 例: &prompt.root; dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k count=20000 また, スワッピングが開始されるとクライアントの スワップスペースはセンシティブな情報を含むようになるので, 不正なアクセスを防止するため, このファイルへの 読み書きのアクセス制限がなされていることを確認して下さい: &prompt.root; chmod 0600 /swapfs/swap.192.1.2.4 クライアントがそれぞれのrootファイルシステムとして使う ディレクトリにrootファイルシステムを展開します. (上記の例では/rootfs/myclient). HP-UX システム: サーバはHP9000/800 シリーズのマシンで, HP-UX 9.04 以降が必要です. これ以前のバージョンでは NFS を経由するデバイスファイルが作成ができません. /rootfs/myclient に /dev を 展開する際に, いくつかのシステム (HPUX) では FreeBSD に合った デバイスファイルが作成されないので 注意してください. その際には最初の起動時にシングルユーザモードに 移行して (ブートの段階でCtrl-Cを押す), /dev に移って sh ./MAKEDEV all として, クライアントからこれを 修正してください. クライアントで netboot.com を実行するか, netboot.rom ファイルから EPROMを作成します. <filename>/</filename> および <filename>/usr</filename> ファイルシステムを共有して使用する 今のところ, これを行う公式に認められた方法はありませんが, 私はそれぞれのクライアントで /usr ファイルシステムと個々の / ファイルシステムを共有して使っています. どなたかこれをきちんと行うやり方の提案がありましたら, 私に, もしくは &a.core; グループに知らせてください. 特定の設定についてnetbootをコンパイルする /sys/i386/boot/netboot/Makefile の中の設定を変更して コンパイルすることで, netbootでNE1000/2000 カードをサポートします. このファイルの先頭にあるコメントを見てください. ISDN - 最終更新: &a.wlloyd;. + 最終更新: Bill Lloyd wlloyd@mpd.ca. 訳: &a.jp.kiroh;. 11 December 1996. ISDN 技術とハードウェアに関しては, Dan Kegel's ISDN Page がよい参考になるでしょう. ISDN の導入手順は, 簡単にいって以下のようになります. ヨーロッパ在住の方は, ISDN カードの節に進んでください. ISDN を使って, インターネットプロバイダに(専用線は使用せず), ダ イアルアップ接続しようとしている場合は, ターミナルアダプタの使用を考えてみてください. この方法はもっとも柔軟性があり, プロバイダを変更した場 合の問題も少ないでしょう. 2つの LAN の間を接続しようする場合や, ISDN 専用線を使用する場合 には, スタンドアローンルータ/ブリッジの使用を勧めます. どの方法を用いるかを決定するには, 費用が重要な要素になってきます. 以下に, 最も安価な方法から, 高価な方法まで順に説明していきます. ISDN カード 著者:&a.hm;. このセクションの記述は, DSS1/Q.931 ISDN 標準がサポートされている国のユーザにのみ有効です. 最近増えてきている PC ISDN カードのうちいくつかは, FreeBSD 2.2.x 以降で isdn4bsd ドライバパッケージによりサポートされています. 依然として開発中ではありますが, ヨーロッパ中でうまく動作しているという報告があります. 最新の isdn4bsd は, ftp://isdn4bsd@ftp.consol.de/pub/ から入手できます. この ftp サイトでは, ユーザ名として isdn4bsd を使い, パスワードにメールアドレスを使ってログインする 必要があります. ログインできたら pub ディレクトリに移動してください. ユーザー名 ftp や anonymous によるログインでは, 必要なファイルにたどりつけません. isdn4bsd は, IP over raw HDLC もしくは同期 PPP を利用して他の ISDN ルータと接続できます. 留守番電話アプリケーションも使えます. Siemens ISDN チップセット (ISAC/HSCX) を使用したものを主に多くのカードがサポートされています. 他のチップセット (Motorola, Cologn ChipDesigns) のサポートは現在開発中です. サポートされるカードの最新のリストは, README を参照してください. 他の ISDN プロトコルを追加したい場合や, サポートされていない ISDN PC カード サポートしたい場合など isdn4bsd を拡張したい場合は, hm@kts.org までご連絡ください. majordomoによるメーリングリストが利用できます. 参加するには, 本文に subscribe freebsd-isdn と記入したメールを &a.majordomo; 宛てに送ってください. ISDN ターミナルアダプタ ターミナルアダプタ (TA) はISDN に対して, 通常の電話線に対するモデムに相当するものです. ほとんどの TA は, 標準のヘイズ AT コマンドセットを使用しているので, 単にモデムと置き換えて使うことができます. TA は, 基本的にはモデムと同じように動作しますが, 接続方法は異なり, 通信速度も古いモデムよりはるかに速くなります. PPP の設定を, モデムの場合と同じように行ってください. とくにシリアル速度を 使用できる最高速度に設定するのを忘れないでください. プロバイダへの接続に TA を使用する最大のメリットは, 動的 PPP を行えることです. 最近 IP アドレスが不足してきているため, ほとんどのプロバイダは, 専用の IP アドレスを割り当てないようになっています. ほとんどのスタンドアローンルータは, 動的 IP アドレスに対応していません. 訳注: 最近の ISDN ルータでは, IP アドレスの動的割り当てに対応しているものも多いようです. ただし制限がある場合もありますので, 詳しくはメーカ に問い合わせてください. TA を使用した場合の機能や接続の安定性は, 使用している PPP デーモンに完全に依存します. そのため, FreeBSD で PPP の設定が完了していれば, 使用している既存のモデムを ISDN の TA に簡単にアップグレードすることができます. ただし, それまでの PPP のプログラムに問題があった場合, その問題は TA に置き換えてもそのまま残ります. 最高の安定性を求めるのであれば, ユーザープロセス iijPPP ではなく, カーネル PPPを使用してください. 以下の TA は, FreeBSD で動作確認ずみです. Motorola BitSurfer および Bitsurfer Pro Adtran 他の TA もほとんどの場合うまく動作するでしょう. TA のメーカーでは, TA がほとんどの標準モデム AT コマンドセットを受け付けるようにするよう, 努力しているようです. 外部 TA を使う際の最大の問題点は, モデムの場合と同じく良いシリアルカー ドが必要であるということです. シリアルデバイスの詳細, そして非同期シリアルポートと同期シリアルポートの差については, 同期・非同期の違いやシリアルデバイスについて説明したチュートリアル FreeBSD Serial Hardware を参照してください. 標準の PC シリアルポート(非同期)に接続された TA は, 128Kbs の接続を行っていても, 最大通信速度が 115.2Kbs に制限されてしまいます. 128Kbs の ISDN の性能を最大限に生かすためには, TA を同期シリアルカードに接続しなければなりません. 内蔵 TA を購入して, 同期／非同期問題を片付けてしまおうとは思わないでく ださい. 内蔵 TA には, 単に標準 PC シリアルポートのチップが内蔵されてい るだけです. 内蔵 TA の利点といえば, シリアルケーブルを買わなくていいと いうことと, 電源コンセントが一つ少なくて済むということくらいでしょう. 同期カードと TA の組合せは 386 の FreeBSD マシンの場合でも, スタンドア ローンのルータと同程度の速度は確保できます. またこの組合せでは, ルータより柔軟な設定が可能です. 同期カード/TA を選ぶか, スタンドアローンルータを選ぶかは, 多分に宗教的な問題です. メーリングリストでもいくつか議論がありました. 議論の内容に ついては, archives を参照してください. スタンドアローン ISDN ブリッジ/ルータ ISDN ブリッジやルータは, OS 特有のものではありません. もちろん FreeBSD 特有のものでもありません. ルーティングやブリッジング技術に関する詳細は, ネットワークの参考書をご覧ください. このページでは, ルータとブリッジにどちらでもあてはまるように記述します. ISDN ルータ/ブリッジは, ローエンドの製品のコストが下がってきていることもあり, より一般的に使用されるようになるでしょう. ISDN ルータは, 外見は小さな箱で, ローカルのイーサネットネットワーク(もしくはカード)と直接, 接続します. また, 自身で他のブリッジ/ルータとの接続を制御します. PPP や他のプロトコルを使用するためのソフトウェアは, すべて組み込まれています. ルータは, 完全な同期 ISDN 接続を使用するため, 通常の TA と比較してスループットが大幅に向上します. ISDN ルータ/ブリッジを使用する場合の最大の問題点は, 各メーカーの製品間に相性の問題がまだ存在することです. インターネットプロバイダとの接続を考えている場合には, プロバイダと相談することをお勧めします. 事務所の LAN と家庭の LAN の間など, 二つの LAN セグメントの間を接続しようとしている場合は, ブリッジ/ルータの使用がもっともメンテナンスが 簡単で, 努力が少なくてすむ方法です. 両側の機材を購入するのであれば, メーカー間の接続性の問題もないでしょう. たとえば家庭の LAN や出張所の LAN を本社のネットワークに接続するためには, 以下のような設定が使用できます. 出張所 LAN または 家庭 LAN ネットワークは, 10 Base T イーサネットです. ルータとネットワークの間は, 必要に応じて AUI/10BT トランシーバを使って接続します. ---Sun ワークステーション | ---FreeBSD マシン | ---Windows 95 (別に勧めているわけじゃありません) | スタンドアローンルータ | ISDN BRI ライン 家庭/出張所 LAN で, 一台しかコンピュータを接続しないのであれば, クロス のツイストペアケーブルを使用して, スタンドアローンルータと直結も可能です. 本社 LAN や他の LAN ネットワークは, ツイストペアイーサネットです. -------Novell サーバ | | |ハ ---Sun | | | ---FreeBSD | | |ブ ---Windows 95 | | |___---スタンドアローンルータ | ISDN BRI ライン ほとんどのルータ/ブリッジでは, 別々の二つのサイトに対して, 同時にそれ ぞれ独立した二つの PPP 接続が可能です. これは, 通常の TA ではサポートされない機能で, ルータ/ブリッジ接続の大きな利点です (シリアルポートを 二つもつ特殊(そして高価な) TA では可能です). チャンネル割り当てや MPP などと混同しないでください. これは, 大変便利な機能です. たとえば事務所で専用線 ISDN 接続を使用していて, 別の ISDN ラインを購入したくないとします. この場合, 事務所のルータは, 一つの専用線 B チャンネル接続(64Kbs)を維持しつつ, 別 の B チャンネルを他の用途に使用することができます. たとえば, 他の場所 とのダイアルイン, ダイアルアウトに使用したり, バンド幅を増やすために, インターネットとの接続への動的に割り当て(MPP など)に使用したりすることが可能です. またイーサネットブリッジは, IP パケットだけでなく IPX/SPX などすべての プロトコルのパケットを中継することが可能です. NIS/YP 原作: &a.unfurl;, 2000 年 1 月 21 日, 監修: Eric Ogren eogren@earthlink.net, Udo Erdelhoff ue@nathan.ruhr.de, 2000 年 6 月. NIS/YP とは? NIS とは Network Information Services の略で Sun Microsystems によって Unix の (もともとは SunOS の) 集中管理のために開発されました. 現在では事実上の業界標準になっており, 主要な Unix は (Solaris, HP-UX, AIX, Linux, NetBSD, OpenBSD, FreeBSD, 等々) すべてこれをサポートしています. NIS は元々, イエローページ (または yp) として知られていましたが, 著作権を侵害しているとして Sun はその名を変えさせられました. NIS は RPC を使ったクライアント/サーバシステムです. これを使うと NISドメイン内のマシン間で, 共通の設定ファイルを共有することができます. また, NIS を使うことでシステム管理者は最小限の設定データで NIS クライアントを立ち上げることができ, 1 ヶ所から設定データの追加, 削除, 変更が可能です. NIS は Windows NT のドメインシステムに似ています. 内部の実装は似ても似つかないものですが, 基本的な機能を 対比することはできます. 知っておくべき用語 / プロセス NIS サーバの立ち上げや NIS クライアントの設定など, NIS を FreeBSD に導入するにあたって, 目にするであろう用語や重要なユーザプロセスがいくつかあります. NIS ドメイン名. NIS マスターサーバ一つと そのクライアント (スレーブサーバを含む) は一つの NIS ドメイン名を 持ちます. NT のドメイン名同様, NIS ドメイン名は DNS とは何の関係もありません. portmap. portmap は RPC (Remote Procedure Call, NIS で使われるネットワークプロトコル) を利用するために実行しておかなければなりません. portmap が動いていなければ, NIS サーバの起動もクライアントとしての機能も得られません. ypbind. ypbind は NIS クライアントを NIS サーバに結び付けます. これは NIS ドメイン名をシステムから受け, RPC を用いてサーバに接続します. ypbind はクライアントとサーバのコミュニケーションの中枢であり, もしクライアントマシンの ypbind が機能を停止した場合は NIS サーバへアクセスできなくなります. ypserv. ypserv は NIS サーバでのみ実行されるもので, NIS のサーバプロセスそのものです. ypserv が機能を停止したときは, サーバは NIS リクエストに答えられなくなります (運が良ければ, スレーブサーバがいて代わりを努めるでしょう). 今まで使っていたサーバが機能を停止したとき, 別のサーバに再接続しに行かない NIS の実装もいくつかあります (FreeBSD のものは違います). そのような場合に復帰するための唯一の方法は, サーバプロセス (あるいはサーバ全体), もしくはクライアントの ypbind プロセスを再スタートすることです. rpc.yppasswdd. rpc.yppasswdd は NIS マスターサーバで動かされるべきもう一つのプロセスで, NIS クライアントから NIS パスワードを変更させるデーモンです. このデーモンが動いていないときは, ユーザは NIS マスターサーバに login し, そこでパスワードを変更することになります. 動作のしくみ NIS 環境にあるホストは, 次の 3 種類に分類されます. それは, マスターサーバ, スレーブサーバ, クライアントです. サーバは, ホストの設定情報の中心的な情報格納庫の役割をします. マスターサーバは元となる信頼できる情報を保持し, スレーブサーバは, 冗長性を確保するため, この情報をミラーします. そしてクライアントは, サーバから情報の提供を受けて動作します. この方法を用いることで, 数多くのファイルにある情報が共有できます. よく NIS で共有されるのは, master.passwd や group, hosts といったファイルです. クライアント上のプロセスで, 通常ローカルのファイルにある情報が必要 となったとき, クライアントは接続しているサーバに問い合わせを行い, その情報を得ます. マシンの分類 NIS マスターサーバ. このサーバは Windows NT で言うところのプライマリ ドメインコントローラにあたります. すべての NIS クライアントで利用されるファイルを保守し, passwd や group, その他 NIS クライアントが参照するファイルは, マスターサーバにあります. 一つのマシンが一つ以上の NIS ドメインのマスターサーバになることは可能です. しかし, ここでは比較的小規模の NIS 環境を対象としているため, そのような場合については扱いません. NIS スレーブサーバ. NT で言うところのバックアップドメインコントローラに似たもので, NIS スレーブサーバは NIS マスターサーバのデータファイルのコピーを保持します. NIS スレーブサーバは重要な環境で必要とされる冗長性を提供し, マスターサーバの負荷のバランスをとります. NIS クライアントは常に最初にレスポンスを返したサーバを NIS サーバとして接続しますが, これにはスレーブサーバも含まれます. NIS クライアント. NIS クライアントは大部分の NT ワークステーションのように, logon に際して NIS サーバに対して (NT ワークステーションの場合では NT ドメインコントローラに) 認証します. NIS/YP を使う この節では NIS 環境の立ち上げ例を取り上げます. この節ではあなたが FreeBSD 3.3 以降を使っているものとします. ここで与えられる指示はおそらく FreeBSD の 3.0 以降の, どのバージョンでも機能するでしょうが, それを保証するものではありません. 計画を立てる あなたが大学の小さな研究室の管理人であるとしましょう. この研究室は 15 台の FreeBSD マシンからなっていて, 現在はまだ集中管理されていません. すなわち, 各マシンは /etc/passwd と /etc/master.passwd を各々が持っています. これらのファイルは手動でお互いに同期させています. つまり現時点では, 新しいユーザをあなたが追加するとき, adduser を 15 ヶ所すべてで実行しなければなりません. これは明らかに変える必要があるため, あなたはこのうち 2 台をサーバにして NIS を導入することを決めました. その結果, 研究室の設定はこのようなものになります: マシンの名前 IP address 役割 ellington 10.0.0.2 NIS マスタ coltrane 10.0.0.3 NIS スレーブ basie 10.0.0.4 教員用のワークステーション bird 10.0.0.5 クライアントマシン cli[1-11] 10.0.0.[6-17] その他のクライアントマシン もし NIS によるシステム管理の設定を行なうのが初めてなら, どのようにしたいのか, ひととおり最後まで考えてみることをお勧めします. ネットワークの規模によらず, いくつか決めるべきことがあるからです. NIS ドメイン名を決める ここでいうドメイン名は, 今まであなたが使っていた, いわゆる ドメイン名 と呼んでいたものとは違います. 正確には NIS ドメイン名 と呼ばれます. クライアントがサーバに情報を要求するとき, その要求には自分が属する NIS ドメインの名前が含まれています. これは, 1 つのネットワークに複数のサーバがある場合に, どのサーバが要求を処理すれば良いかを決めるために使われます. NIS ドメイン名とは, 関連のあるホストをグループ化するための名前である, と考えると良いでしょう. 組織によってはインターネットのドメイン名を NIS ドメイン名に使っているところがありますが, これはネットワークのトラブルをデバッグするときに混乱の原因となるため, お勧めできません. NIS ドメイン名はネットワーク内で一意なければならないので, ドメイン名がドメインに含まれるマシンを表すようなものであれば, 分かりやすくなります. たとえば Acme 社のアート(Art)部門であれば, NIS ドメイン名を"acme-art"とすれば良いでしょう. しかしながら, オペレーティングシステムによっては, そのネットワークドメイン名を NIS のドメイン名として使うものもあります (特に SunOS). あなたのネットワークにそのような制限のあるマシンが 1 台でもあるときは, NIS のドメイン名としてインターネットのネットワークドメイン名を使わなければいけません. サーバマシンの物理的な条件とは NIS サーバとして使うマシンを選ぶ際には, いくつかの注意点があります. NIS における困ったことの一つに, クライアントのサーバへの依存度があります. クライアントが自分の NIS ドメインのサーバに接続できない場合, マシンが使用不能になることがよくあります. もし, ユーザやグループに関する情報が得られなければ, ほとんどのシステムは一時的にですが停止してしまいます. こういったことを念頭に置いて, しょっちゅうリブートされるマシンや, 開発に使われそうなマシンを選ばないようにしなければなりません. 理想的には, NIS サーバはスタンドアロンで NIS サーバ専用となるマシンにするべきです. ネットワークの負荷が重くなければ, 他のサービスを走らせているマシンを NIS サーバにしてもかまいません. ただし NIS サーバが使えなくなると, すべてのクライアントに影響をおよぼす, という点には注意しなければなりません. NIS サーバ 元となるすべての NIS 情報は, NIS マスターサーバと呼ばれる 1 台のマシンに置かれます. この情報が格納されるデータベースを NIS マップと呼びます. FreeBSDでは, このマップは /var/yp/[domainname] に置かれます. [domainname] は, サーバがサービスする NIS ドメインです. 1 台の NIS サーバが複数のドメインをサポートすることも可能です. つまり, このディレクトリを各々のドメインごとに作ることができ, 各ドメインごと, 独立したマップの集合を持つことになります. NIS のマスターサーバとスレーブサーバ上では, ypserv デーモンがすべての NIS 要求を処理します. ypserv は NIS クライアントからの要求を受け付け, ドメイン名とマップ名を対応するデータベースファイルへのパスに変換し, データをクライアントに返送します. NIS マスターサーバの設定 やりたいことにもよりますが, NIS マスターサーバの設定は比較的単純です. FreeBSD は初期状態で NIS に対応しています. 必要なことは以下の行を /etc/rc.conf に追加し, FreeBSD をリスタートすることだけです. nisdomainname="test-domain" この行はネットワークのセットアップ時に (すなわち再起動したときに) NIS のドメイン名を test-domain にセットします. nis_server_enable="YES" これは FreeBSD に, 次にネットワークが立ち上がったとき NIS のサーバプロセスを起動させます. nis_yppasswdd_enable="YES" これは rpc.yppasswdd デーモンを有効にします. 上述したようにこれはユーザが NIS のパスワードをクライアントのマシンから変更することを可能にします. あと, あなたがしなければいけないことはスーパユーザ権限でコマンド /etc/netstart を実行することです. これにより /etc/rc.conf で定義された値を使ってすべての設定が行なわれます. NIS マップの初期化 NIS マップ とは /var/yp ディレクトリにあるデータベースファイルです. これらは NIS マスタの /etc ディレクトリの設定ファイルから作られます. 唯一の例外は /etc/master.passwd ファイルです. これは, root や他の管理用アカウントのパスワードまでその NIS ドメインのすべてのサーバに伝えたくないという, もっともな理由によるものです. このため NIS マップの初期化の前に以下を行う必要があります. &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd あなたはシステムに関するアカウント (bin, tty, kmem, games, etc) をすべて削除しなければなりません. またあなたが NIS クライアントに伝えたくないと思うアカウント (たとえば root や他の UID が 0 (スーパユーザ) のアカウント) についても削除する必要があります. /var/yp/master.passwd が グループや全世界から読めるようになっていないようにしてください (モード 600)! 必要なら chmod コマンドを 使ってください. すべてが終わったらマップを初期化します! FreeBSD には, これを行うために ypinit という名のスクリプトが含まれています (詳細はそのマニュアルページをご覧ください). このスクリプトはほとんどの UNIX OS で存在しますが, すべてとは限らないことを覚えておいてください. Digital Unix/Compaq Tru64 Unix では ypsetup と呼ばれています. NIS マスタのためのマップを作るためには オプションを ypinit に与えます. 上述のステップを完了しているなら, 以下を実行して NIS マップを生成します. ellington&prompt.root; ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [..output from map generation..] NIS Map update completed. ellington has been setup as an YP master server without any errors. ypinit は /var/yp/Makefile を /var/yp/Makefile.dist から作成します. 作成されていれば, そのファイルはあなたが扱っているのが FreeBSD のみからなる, サーバが一つだけの NIS 環境であるという前提に立っています. test-domain はスレーブサーバを一つ持っていますので, /var/yp/Makefile を編集する必要があります. ellington&prompt.root; vi /var/yp/Makefile `NOPUSH = "True"' としている行を (もし既にコメントアウトされていないならば) コメントアウトしなければなりません. NIS スレーブサーバの設定 NIS スレーブサーバの設定はマスターサーバの設定以上に簡単です. スレーブサーバにログオンし /etc/rc.conf ファイルを前回と同様に編集します. 唯一の違うところは ypinit の実行に オプションを使わなければいけないことです. オプションは NIS マスターサーバの名前を要求し, コマンドラインは以下のようになります. coltrane&prompt.root; ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington. この例の場合, /var/yp/test-domain というディレクトリが必要になります. NIS マスターサーバのマップファイルのコピーはこのディレクトリに置かれますが, あなたは, これらが確実に最新のものに維持されるようにする必要があります. 次のエントリをスレーブサーバの /etc/crontab に追加することで, 最新のものに保つことができます. 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid この二行は, スレーブサーバにあるマップファイルをマスターサーバのマップファイルと同期させるものですが, 必須というわけではありません. なぜなら, マスターサーバは, NIS マップに対する変更をスレーブサーバに伝えようとするからです. しかし, サーバが管理するシステムにとってパスワード情報はとても重要なものですので, 強制的に更新してしまう方が良いでしょう. 特に, マップファイルの更新がきちんと行なわれるかどうかわからないくらい混雑するネットワークでは, 重要なポイントになります. コマンド /etc/netstart をスレーブサーバでも実行してください. NIS サーバを起動します. NIS クライアント NIS クライアントは ypbind デーモンを使って, 特定の NIS サーバとの間に結合 (binding) と呼ばれる関係を成立させます. ypbind はシステムのデフォルトのドメイン (domainname コマンドで設定されます) をチェックし, RPC 要求をブロードキャストパケットとしてローカルネットワークに送信します. この RPC 要求により, ypbind が結合を成立させようとしているドメイン名が指定されます. 要求されているドメイン名に対してサービスするよう設定されたサーバが ブロードキャストパケットを受信すると, サーバは ypbind に応答し, ypbind は応答のあったサーバのアドレスを記録します. 複数のサーバがある(たとえば一つのマスターサーバと, 複数のスレーブサーバがある)場合, ypbind は, 最初に応答したサーバのアドレスを使用します. これ以降, クライアントのシステムは, すべての NIS の要求をそのサーバに向けて送信します. ypbind は, サーバが順調に動作していることを確認するため, 時々 ping をサーバに送ります. 反応が戻ってくるべき時間内に ping に対する応答が来なければ, ypbind は, そのドメインを結合不能(unbound)として記録し, 別のサーバを見つけるべく, 再びブロードキャストパケットの送信を行います. NIS クライアントの設定 FreeBSD マシンにおける NIS クライアントの設定は非常に単純です. /etc/rc.conf ファイルを編集して以下の行を追加し, ネットワークのセットアップ時に NIS ドメイン名をセットして ypbind を起動させます. nisdomainname="test-domain" nis_client_enable="YES" NIS サーバにあるすべてのパスワードエントリを取り込むため, vipw コマンドで以下の行を /etc/master.passwd に追加します. +::::::::: この行によって NIS サーバのパスワードマップにアカウントがある人全員にアカウントが与えられます. この行を変更すると, さまざまな NIS クライアントの設定を行なうことが可能です. 詳細は netgroups の部分を, さらに詳しい情報については, O'Reilly の Managing NFS and NIS をお読みください. NIS サーバにあるすべてのグループエントリを取り込むため, 以下の行を /etc/group に追加します. +:*:: 上記の手順がすべて完了すれば, ypcat passwd によって NIS サーバの passwd マップが参照できるようになっているはずです. NIS セキュリティ 一般にドメイン名さえ知っていれば, どこにいるリモートユーザでも ypserv に RPC を発行して NIS マップの内容を引き出すことができます. こういった不正なやりとりを防ぐため, ypserv には securenets と呼ばれる機能があります. これはアクセスを決められたホストだけに制限する機能です. ypserv は起動時に /var/yp/securenets ファイルから securenets に関する情報を読み込みます. 上記のパス名は, オプションで指定されたパス名によって変わります. このファイルは, 空白で区切られたネットワーク指定とネットマスクのエントリからなっていて, # で始まる行はコメントとみなされます. 簡単な securenets ファイルの例を以下に示します. # allow connections from local host -- mandatory 127.0.0.1 255.255.255.255 # allow connections from any host # on the 192.168.128.0 network 192.168.128.0 255.255.255.0 # allow connections from any host # between 10.0.0.0 to 10.0.15.255 10.0.0.0 255.255.240.0 ypserv が上記のルールの一つと合致するアドレスからの要求を受け取った場合, 処理は通常に行なわれます. もしアドレスがルールに合致しなければ, その要求は無視されて警告メッセージがログに記録されます. また, /var/yp/securenets が存在しない場合, ypserv はすべてのホストからの接続を受け入れます. ypserv は Wietse Venema 氏による tcpwrapper パッケージもサポートしています. そのため, /var/yp/securenets の代わりに tcpwrapper の設定ファイルを使ってアクセス制御を行なうことも可能です. これらのアクセス制御機能は一定のセキュリティを提供しますが, どちらも特権ポートのテストのような IP spoofing 攻撃に対して脆弱です. すべての NIS 関連のトラフィックはファイアウォールでブロックされるべきです. /var/yp/securenets を使っているサーバは, 古風な TCP/IP 実装を持つ正しいクライアントへのサービスに失敗することがあります. これらの実装の中にはブロードキャストのホストビットをすべて 0 でセットしてしまったり ブロードキャストアドレスの計算でサブネットマスクを見落としてしまったりするものがあります. これらの問題はクライアントの設定を正しく行なうことで修正できますが, 他の問題は問題となっているクライアントシステムの撤去か /var/yp/securenets の放棄が必要です. このような古風な TCP/IP の実装を持つサーバで /var/yp/securenets を使うことは非常に悪い考えであり, あなたのネットワークの大部分において NIS の機能を失うことになるでしょう. tcpwrapper パッケージの使用はあなたの NIS サーバのレイテンシ (遅延) を増加させます. 追加された遅延は, 特に混雑したネットワークや遅い NIS サーバでクライアントプログラムのタイムアウトを引き起こすに十分なだけ長いでしょう. 一つ以上のクライアントシステムがこれらの兆候を示したなら, あなたは問題となっているクライアントシステムを NIS スレーブサーバにして自分自身に結び付くように強制すべきです. 何人かのユーザのログオンを遮断する わたしたちの研究室には basie という, 教員専用のマシンがあります. わたしたちはこのマシンを NIS ドメインの外に出したくないのですが, マスタ NIS サーバの passwd ファイルには教員と学生の両方が載っています. どうしたらいいでしょう? 当該人物が NIS のデータベースに載っていても, そのユーザがマシンにログオンできないようにする方法があります. そうするには, -username を クライアントマシンの /etc/master.passwd ファイルの末尾に付け足します. username はあなたがログインさせたくないと思っているユーザのユーザ名です. これは vipw で行うべきです. vipw は /etc/master.passwd への変更をチェックし, 編集終了後パスワードデータベースを再構築します. たとえば, ユーザ bill が basie にログオンするのを防ぎたいなら, 以下のようにします. basie&prompt.root; vipw [add -bill to the end, exit] vipw: rebuilding the database... vipw: done basie&prompt.root; cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie&prompt.root; netgroups の利用 netgroups の部分の原作: Udo Erdelhoff ue@nathan.ruhr.de. 2000 年 7 月. 前節までに見てきた手法は, 極めて少ないユーザ/マシン向けに個別のルールを必要としている場合にはうまく機能します. しかし大きなネットワークでは, ユーザに触られたくないマシンへログオンを防ぐのを忘れるでしょうし, そうでなくとも各マシンを個別に設定して回らなければならず, 集中管理という NIS の恩恵を失ってしまいます. NIS の開発者はこの問題を netgroups と呼ばれる方法で解決しました. 彼らの目的とその意味合いは UNIX のファイルシステムで使われている一般的なグループと比較できます. 主たる相違は数字による id を欠いていることと, ネットグループを定義するのにユーザアカウントと別のネットグループの, 両方を含められる機能です. ネットグループは百人/台以上のユーザとマシンを含む, 大きく複雑なネットワークを扱うために開発されました. もし, あなたがこのような状況を扱わなければならないなら便利なものなのですが, この複雑さは単純な例でネットグループの説明をすることをほとんど不可能にしています. この部の残りで使われている例は, この問題を実演しています. あなたの行なった, 研究室への NIS の導入の成功が上司の目に止ったとしましょう. あなたの次の仕事は, あなたの NIS ドメインをキャンパスの他のいくつものマシンを覆うものへ拡張することです. 二つの表は新しいユーザと新しいマシンの名前とその説明を含んでいます. ユーザの名前 説明 alpha, beta IT 学科の通常の職員 charlie, delta IT 学科の新しい見習い echo, foxtrott, golf, ... 一般の職員 able, baker, ... まだインターン マシンの名前 説明 war, death, famine, polution 最も重要なサーバ. IT 職員だけがログオンを許されます. pride, greed, envy, wraith, lust, sloth あまり重要でないサーバ. IT 学科の全員がログオンを許されます. one, two, three, four, ... 通常のワークステーション. 本当の 職員だけがログオンを許されます. trashcan 重要なデータの入っていないひどく古いマシン. インターンでもこのマシンの使用を許されます. もしあなたがこの手の制限を各ユーザを個別にブロックする形で実装するなら, あなたはそのシステムにログオンすることが許されていない各ユーザについて -user という 1 行を, 各システムのパスワードに追加しなければならなくなるでしょう. もしあなたが 1 エントリでも忘れればトラブルに巻き込まれてしまいます. 最初のセットアップの時にこれを正しく行えるのはありえることかも知れませんが, 遂には連日の業務の間に例の行を追加し忘れてしまうでしょう. 結局マーフィーは楽観主義者だったのです. この状況をネットグループで扱うといくつかの有利な点があります. 各ユーザを別個に扱う必要はなく, ユーザを一つ以上のネットグループに割り当て, ネットグループの全メンバのログインを許可したり禁止したりすることができます. 新しいマシンを追加するときはネットグループへログインの制限を定義するだけ, 新しいユーザを追加するときはそのユーザを一つ以上のネットグループへ追加するだけで, それぞれ行なうことができます. これらの変更は互いに独立なので, ユーザとマシンの組合わせをどうするか は存在しなくなります. あなたの NIS のセットアップが注意深く計画されていれば, マシンへのアクセスを認めるにも拒否するにも中心の設定をたった一カ所変更するだけです. 最初のステップは NIS マップ netgroup の初期化です. FreeBSD の ypinit はこのマップをデフォルトで作りませんが, その NIS の実装はそれが作られさえすればそれをサポートするものです. 空のマップを作るには, 単に ellington&prompt.root; vi /var/yp/netgroup とタイプして内容を追加していきます. わたしたちの例では, すくなくとも IT 職員, IT 見習い, 一般職員, インターンの 4 つのネットグループが必要です. IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) USERS (,echo,test-domain) (,foxtrott,test-domain) \ (,golf,test-domain) INTERNS (,able,test-domain) (,baker,test-domain) IT_EMP, IT_APP 等はネットグループの名前です. それぞれの括弧で囲まれたグループが一人以上のユーザアカウントをそれに登録しています. グループの 3 つのフィールドは その記述が有効なホスト(群)の名称. ホスト名を特記しなければそのエントリはすべてのホストで有効です. もしあなたがホスト名を特記するなら, あなたは闇と恐怖と全き混乱の領域となるでしょう. このネットグループに所属するアカウントの名称. そのアカウントの NIS ドメイン. もしあなたが一つ以上の NIS ドメインの不幸な仲間なら, あなたは他の NIS ドメインからあなたのネットグループにアカウントを導入できます. 各フィールドには, ワイルドカードが使えます. 詳細は &man.netgroup.5; をご覧ください. 8 文字以上のネットグループ名は, 特にあなたの NIS ドメインで他のオペレーティングシステムを走らせているときは使うべきではありません. 名前には大文字小文字の区別があります. そのためネットグループ名に大文字を使う事は, ユーザやマシン名とネットグループ名を区別する簡単な方法です. NIS クライアントの中には (FreeBSD 以外で) 多数のエントリを扱えないものもあります. たとえば SunOS の古い版では 15 以上のエントリを含むネットグループはトラブルを起こします. この制限は 15 ユーザ以下のサブ・ネットグループをいくつも作り, 本当のネットグループはこのサブ・ネットグループからなるようにすることで回避できます. BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe32,domain) (,joe33,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 単一のネットグループに 225 人以上のユーザをいれたいときは, このやり方を繰り返すことができます. 新しい NIS マップの有効化と配布は簡単です. ellington&prompt.root; cd /var/yp ellington&prompt.root; make これで新しい 3 つの NIS マップ netgroup, netgroup.byhost netgroup.byuser ができるはずです. 新しい NIS マップが利用できるか確かめるには &man.ypcat.1; を使います. ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser 最初のコマンドの出力は /var/yp/netgroup の内容に似ているはずです. 2 番目のコマンドはホスト別のネットグループを作っていなければ出力されません. 3 番目のコマンドはユーザに対するネットグループのリストを得るのに使えます. クライアント側の設定は非常に簡単です. サーバ war を設定するには, &man.vipw.8; を実行して以下の行 +::::::::: を +@IT_EMP::::::::: に入れ替えるだけです. 今, ネットグループ IT_EMP で定義されたユーザのデータだけが war のパスワードデータベースに読み込まれ, そのユーザだけがログインを許されています. 残念ながらこの制限はシェルの ~ の機能や, ユーザ名やユーザの数値 id の変換ルーチンにも影響します. 言い換えれば, cd ~user はうまく動かず, ls -l はユーザ名のかわりに数値の id を表示し find . -user joe -print は No such user で失敗します. これを避けるためには, すべてのユーザのエントリをサーバにログインすることを許さずに読み込むことが必要です. これはもう一行を /etc/master.passwd に追加することで実現できます. その行は +:::::::::/sbin/nologin を含んでおり, すべてのエントリを読み込むが, 読み込まれたエントリのシェルは /sbin/nologin で置き換えられる ということを意味します. passwd エントリの他のフィールドを /etc/master.passwd の既定値から置き換えることも可能です. +:::::::::/sbin/nologin の行が +@IT_EMP::::::::: の行より後ろに位置することに注意してください. さもないと NIS から読み込まれた全ユーザが /sbin/nologin をログインシェルとして持つことになります. この変更の後では, 新しい職員が IT 学科に参加しても NIS マップを一つ書き換えるだけで済みます. 同様にして, あまり重要でないサーバのローカルの /etc/master.passwd のかつての +::::::::: 行を以下のように置き換えます. +@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin この行は, 一般のワークステーションでは以下のようになります. +@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin これでしばらく順調に運用していましたが, 数週間後, ポリシに変更がありました. IT 学科はインターンを雇い始め, IT インターンは一般のワークステーションと余り重要ではないサーバを使うことが許され, IT 見習いはメインサーバへのログインが許されました. あなたは新たなネットグループ IT_INTERN を追加して新しい IT インターンたちをそのグループに登録し, すべてのマシンの設定を変えて回ることにしました. 古い諺にこうあります. 集中管理における過ちは, 大規模な混乱を導く. いくつかのネットグループから新たなネットグループを作るという NIS の機能は, このような状況に対処するために利用できます. その方法の一つは, 役割別のネットグループを作ることです. たとえば, 重要なサーバへのログイン制限を定義するために BIGSRV というネットグループを作り あまり重要ではないサーバへは SMALLSRV というネットグループを, そして一般のワークステーション用に USERBOX という第 3 のネットグループを 作ることができます. これらのネットグループの各々は, 各マシンにログインすることを許されたネットグループを含みます. あなたの NIS マップネットグループの新しいエントリは, 以下のようになるはずです. BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS このログイン制限の定義法は, 同一の制限を持つマシンのグループを定義できるときには便利なものです. 残念ながらこのようなケースは例外的なものです. ほとんどの場合, 各マシンに基づくログイン制限の定義機能が必要となるでしょう. マシンごとのネットグループの定義は, 上述したようなポリシの変更を扱うことができるもうひとつの方法です. このシナリオでは, 各マシンの /etc/master.passwd は ``+'' で始まる２つの行を含みます. 最初のものはそのマシンへのログインを許されたアカウントを追加するもので, 2 番目はその他のアカウントを/sbin/nologin をシェルとして追加するものです. マシン名をすべて大文字で記述したものをネットグループの名前として使うのは良いやり方です. 言い換えれば, 件の行は次のようになるはずです. +@BOXNAME::::::::: +:::::::::/sbin/nologin 一度, 各マシンに対してこの作業を済ませてしまえば, 二度とローカルの /etc/master.passwd を編集する必要がなくなります. 以降のすべての変更は NIS マップの編集で扱うことができます. 以下はこのシナリオに対応するネットグループマップに, いくつかの便利な定義を追加した例です. # Define groups of users first IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) DEPT1 (,echo,test-domain) (,foxtrott,test-domain) DEPT2 (,golf,test-domain) (,hotel,test-domain) DEPT3 (,india,test-domain) (,juliet,test-domain) ITINTERN (,kilo,test-domain) (,lima,test-domain) D_INTERNS (,able,test-domain) (,baker,test-domain) # # Now, define some groups based on roles USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS # # And a groups for a special tasks # Allow echo and golf to access our anti-virus-machine SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) # # machine-based netgroups # Our main servers WAR BIGSRV FAMINE BIGSRV # User india needs access to this server POLLUTION BIGSRV (,india,test-domain) # # This one is really important and needs more access restrictions DEATH IT_EMP # # The anti-virus-machine mentioned above ONE SECURITY # # Restrict a machine to a single user TWO (,hotel,test-domain) # [...more groups to follow] もしユーザアカウントを管理するデータベースの類を使っているなら, あなたはデータベースのレポートツールからマップの最初の部分を作れるようにしてあるべきです. この方法なら, 新しいユーザは自動的にマシンにアクセスできるでしょう. 最後に使用上の注意を: マシン別のネットグループを使うことが常に賢明というわけではありません. あなたが数ダースから数百の同一の環境のマシンを学生の研究室に配置しているのならば, NIS マップのサイズを手頃な範囲に押さえるために, マシン別のネットグループのかわりに役割別のネットグループを使うべきです. 忘れてはいけないこと NIS 環境にある今, 今までとは違ったやり方が必要なことが 2,3 あります. 研究室にユーザを追加するときは, それをマスター NIS サーバにだけ追加しなければならず, さらにNIS マップを再構築することを忘れてはいけません. これを忘れると新しいユーザは NIS マスタ以外のどこにもログインできなくなります. たとえば, 新しくユーザ jsmith をラボに登録したいときは以下のようにします. &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make test-domain pw useradd jsmith のかわりに adduser jsmith を使うこともできます. 管理用アカウントを NIS マップから削除してください. 管理用アカウントやパスワードを, それらのアカウントへアクセスされるべきでないユーザが居るかも知れないマシンにまで伝えて回りたいとは思わないでしょう. NIS のマスタとスレーブをセキュアに, そして機能停止時間を最短に保ってください. もし誰かがこれらのマシンをクラックしたり, あるいは単に電源を落としたりすると, 彼らは実質的に多くの人を研究室へログインできなくしてしまえます. これはどの集中管理システムにとっても第一の弱点で, そして最も重要な弱点でしょう. あなたの NIS サーバを守らなければ怒れるユーザと対面することになるでしょう! NIS v1 との互換性 FreeBSD の ypserv は, NIS v1 クライアントを部分的にサポートします. FreeBSD の NIS 実装は NIS v2 プロトコルのみを使用していますが, ほかの実装では, 古いシステムとの下位互換性を持たせるため v1 プロトコルをサポートしているものもあります. そのようなシステムに付いている ypbind デーモンは, 必要がないにもかかわらず NIS v1 のサーバとの結合を成立させようとします(しかも v2 サーバからの応答を受信した後でも, ブロードキャストをし続けるかも知れません). FreeBSD の ypserv は, クライアントからの通常のリクエストはサポートしていますが, v1 のマップ転送リクエストはサポートしていないことに注意してください. つまり FreeBSD の ypserv を, v1 だけをサポートするような古い NIS サーバと組み合わせて マスターやスレーブサーバとして使うことはできません. 幸いなことに, 現在, そのようなサーバが使われていることは ほとんどないでしょう. NIS クライアントとしても動作している NIS サーバ 複数のサーバが存在し, サーバ自身が NIS クライアントでもあるようなドメインで ypserv が実行される場合には, 注意が必要です. 一般的に良いとされているのは, 他のサーバと結合をつくるようにブロードキャストパケットの送信をさせるのではなく, サーバをそれ自身に結合させることです. もし, サーバ同士が依存関係を持っていて, 一つのサーバが停止すると, 奇妙なサービス不能状態に陥ることがあります. その結果, すべてのクライアントはタイムアウトを起こして 他のサーバに結合しようと試みますが, これにかかる時間はかなり大きく, サーバ同士がまた互いに結合してしまったりすると, サービス不能状態はさらに継続することになります. ypbind に オプションフラグを指定して実行することで, ホストを特定のサーバに結合することが可能です. libscrypt 対 libdescrypt NIS を実装しようする人の誰もがぶつかる問題の一つに, 暗号ライブラリの互換性があります. NIS サーバが DES 暗号ライブラリを使っている場合には, 同様に DES を使用しているクライアントしかサポートできません. サーバとクライアントがどのライブラリを使用しているかは, /usr/lib のシンボリックリンクを見ればわかります. あるマシンが DES ライブラリを使うように設定されている場合, リンクは以下のようになっています. &prompt.user; ls -l /usr/lib/*crypt* lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libdescrypt.a lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libdescrypt.so lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libdescrypt.so.2 lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libdescrypt_p.a -r--r--r-- 1 root wheel 13018 Nov 8 14:27 /usr/lib/libdescrypt.a lrwxr-xr-x 1 root wheel 16 Nov 8 14:27 /usr/lib/libdescrypt.so@ -> libdescrypt.so.2 -r--r--r-- 1 root wheel 12965 Nov 8 14:27 /usr/lib/libdescrypt.so.2 -r--r--r-- 1 root wheel 14750 Nov 8 14:27 /usr/lib/libdescrypt_p.a マシンが FreeBSD の標準の MD5 暗号ライブラリを使うように 設定されている場合には, 以下のようになります. &prompt.user; ls -l /usr/lib/*crypt* lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libscrypt.a lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libscrypt.so lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libscrypt.so.2 lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libscrypt_p.a -r--r--r-- 1 root wheel 6194 Nov 8 14:27 /usr/lib/libscrypt.a lrwxr-xr-x 1 root wheel 14 Nov 8 14:27 /usr/lib/libscrypt.so@ -> libscrypt.so.2 -r--r--r-- 1 root wheel 7579 Nov 8 14:27 /usr/lib/libscrypt.so.2 -r--r--r-- 1 root wheel 6684 Nov 8 14:27 /usr/lib/libscrypt_p.a NIS クライアントの認証でトラブルが発生した場合には, ここから問題となりそうな部分を探すと良いでしょう. NIS サーバを異種混在ネットワークに配置したいときは DES が最大公約数となるでしょうから, すべてのシステムで DES を使わなければいけなくなるでしょう. DHCP 原作: &a.gsutter;, 2000 年 3 月. DHCPとは何でしょう? DHCP (Dynamic Host Configuration Protocol) は, システムをネットワー クに接続するだけで, ネットワークでの通信に必要な情報を入手するこ とができる仕組みです. FreeBSD では, ISC (Internet Software Consortium) による DHCP の実装を使用しています. したがって, ここで の説明のうち, 実装によって異なる部分は ISC のもの用になっています. この節で説明していること ハンドブックのこの節では DHCP システムの, FreeBSD に組み込まれてい る部分についてだけ説明しています. ですから, サーバについては説明 していません. 後の節で紹介するリファレンスに加えて, DHCP のマニュアルページも有力な参考になることでしょう. DHCP の動作 クライアントとなるマシン上で DHCP のクライアントである dhclient を実 行すると, まず設定情報の要求をブロードキャストします. デフォルト では, このリクエストには UDP のポート 68 を使用します. サーバは UDP の ポート 67 で応答し, クライアントの IP アドレスと, ネットマスクやルー タ, DNS サーバなどの関連する情報を提供します. これらの情報の すべては DHCP の「リース」の形で送られ, DHCP サーバ管理者によって決 められたある一定の時間内でのみ有効になります. これによって, ネッ トワークに存在しなくなったホストの IP アドレスは自動的に回収される ことになります. DHCP クライアントはサーバから非常に多くの情報を取得することができます. &man.dhcp-options.5; に, その非常に大きなリストが載っています. FreeBSD への組み込み FreeBSD は ISC の DHCP クライアントである dhclient を完全に組み込んでいます. DHCP クラ イアントはインストーラと基本システムの両方で提供されています. ですから DHCP サーバを走らせているネットワーク上ではネットワー ク関係の設定についての詳細な知識は必要になりません. dhclient は, 3.2 以降の FreeBSD のすべての配布 に含まれています. DHCP は sysinstall でサポートされてお り, sysinstall でのネットワークインターフェイス設定の際は, 「こ のインターフェイスの設定として DHCP を試してみますか?」という質問 が最初になされます. これに同意することで dhclient が実行さ れ, それが成功すればネットワークの設定情報は自動的に取得されま す. システム起動時に, DHCP を使ってネットワーク情報を取得するように するには, 次の 2 つのステップを行なう必要があります. bpf デバイスがカーネルに組み込まれていることを確認します. これを組み込むには, カーネルコンフィグレーションファイルに pseudo-device bpf という行を追加し, カーネルを再構築します. カーネルの構築に関する詳細は, を参照してください. bpf デバイスは, FreeBSD の出荷時に用意されている GENERIC カーネルに組み込まれていますので, 自分で設定を変えたカスタムカーネルを使っているのでなければ, DHCP を動作させるためにカーネルを再構築する必要はありません. セキュリティに関心のある方向けに注意しておきます. bpf デバイスは, パケットスニファ (盗聴プログラム) を動作させることができる (ただし root 権限が必要) デバイスです. bpf は DHCP を動作させるために かならず必要ですが, セキュリティが非常に重要な場面では DHCP を本当に使う時まで bpf デバイスをカーネルに追加すべきではないでしょう. /etc/rc.conf を編集して, 次の行を追加してください. ifconfig_fxp0="DHCP" fxp0 の部分を, 動的に設定したいインター フェースの名前で置き換えることを忘れないようにしてください. もし, 使っているdhclient の場所を変更してい たり, dhclient にフラグを渡したい場合は, 同 様に下のように書き加えてください. dhcp_program="/sbin/dhclient" dhcp_flags="" DHCP サーバである dhcpd は, ports collectionに isc-dhcp2 として収録されていま す. この port はクライアント, サーバ, リレーエージェントから成 る ISC の DHCP 配布物をすべて含んでいます. 関連ファイル /etc/dhclient.conf dhclient は設定ファイル /etc/dhclient.conf を必要とします. 大抵の場合, このファイルはコメントだけであり, デフォルトが 通常使いやすい設定になっています. この設定ファイルは マニュアルページ &man.dhclient.conf.5; で説明しています. /sbin/dhclient dhclient は静的にリンクされており, /sbin に置かれています. マニュアルページ &man.dhclient.8; で dhclient コマンドについて より詳しく説明しています. /sbin/dhclient-script dhclient-script は FreeBSD 特有の, DHCP クラ イアント設定スクリプトです. これについてはマニュアルページ &man.dhclient-script.8; で説明されていますが, これを編集する 必要はほとんど発生しないでしょう. /var/db/dhclient.leases DHCP クライアントはこのファイルに有効なリースのデータベースを ログとして記録します. &man.dhclient.leases.5; にもうすこし詳 しい解説があります. 参考になる文献 DHCP のプロトコルは RFC 2131 に完全に記述されています. また, dhcp.org にも有用な 情報源が用意されています. diff --git a/ja_JP.eucJP/books/handbook/linuxemu/chapter.sgml b/ja_JP.eucJP/books/handbook/linuxemu/chapter.sgml index f93aee3788..86e63452ea 100644 --- a/ja_JP.eucJP/books/handbook/linuxemu/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/linuxemu/chapter.sgml @@ -1,793 +1,793 @@ Linux バイナリ互換機能 - オリジナルは &a.handy; と &a.rich; によるものですが, + オリジナルは Brian N. Handy handy@sxt4.physics.montana.edu と &a.rich; によるものですが, &a.jim; が 2000 年 3 月 22 日に再構成と一部の更新を行ないました. 訳: &a.jp.kiroh;, 1996 年 9 月 24 日. この章では この章では FreeBSD における Linux バイナリとの互換機能について, インストール方法やその仕組みを解説します. 現時点では, 一体なぜ FreeBSD が Linux バイナリを実行できるようにならなければならないのか自問しているのではないでしょうか? 答えはきわめて簡単です. Linux は現在コンピュータの世界では最もホットなモノなのでたくさんの会社や開発者たちが Linux のためだけに開発を行なっています. そのため, 残された私たち FreeBSD ユーザは彼らに対して FreeBSD ネイティブなアプリケーションも出すように言うしかないのです. 問題は, FreeBSD バージョンも出した場合にどれくらいの数のユーザーが使うのかわからない, ということであり, そのため Linux 版のみを開発しているということなのです. そこで FreeBSD では Linux バイナリ互換機能が役に立つのです. 簡単に言ってしまえば, この機能により全ての Linux アプリケーションの 90 % が修正なしに FreeBSD 上で起動できます. この中には Star Office や Linux 版の Netscape, Adobe Acrobat, RealPlayer 5 と 7, VMWare, Oracle, WordPerfect, Doom, Quake などがあります. また, ある状況においては Linux バイナリを Linux で動かすよりも FreeBSD で動かすほうが良いパフォーマンスが出るという報告もあります. しかしながら, いくつかの Linux に特有な OS の機能は FreeBSD ではサポートされていません. 例えば, Linux の /proc ファイルシステムを過度に使うような Linux バイナリは FreeBSD では動きません (FreeBSD の /proc ファイルシステムとは異なるのです) し, 仮想 8086 モードを有効にするような i386 特有の呼び出しも動きません. Linux バイナリ互換モードのインストールに関しては次のセクションをご覧ください. インストール 3.0-RELEASE以降であればカーネルのコンフィギュレーションファイルに options LINUX や options COMPAT_LINUX といった行を加える必要はありません. Linux バイナリ互換機能は今は KLD オブジェクト (Kernel LoaDable object) として実現されており, リブートしなくても on-the-fly で組み込むことができるのですが, /etc/rc.confに次の行を加える必要があります. linux_enable=YES この設定により, /etc/rc.i386 では次のような操作が行なわれます. # Start the Linux binary compatibility if requested. # case ${linux_enable} in [Yy][Ee][Ss]) echo -n ' linux'; linux > /dev/null 2>&1 ;; esac 望みの KLD モジュールがロードされているか確認したい時には kldstat を利用します. &prompt.user; kldstat Id Refs Address Size Name 1 2 0xc0100000 16bdb8 kernel 7 1 0xc24db000 d000 linux.ko 何らかの理由で Linux KLD をロードしたくない, あるいはロードできないような場合には, options LINUX をカーネルの設定ファイルに指定して, Linux バイナリ互換機能をカーネルにスタティックリンクしてください. そして, FreeBSD カーネルのコンフィギュレーション の記述にしたがって新しいカーネルをインストールしてください. Linux ランタイムライブラリのインストール これは, linux_base の port を用いるか, もしくは 手動でインストールします. linux_base の port を用いたインストール ランタイムライブラリをインストールするには最も簡単な方法です. ports コレクションから他の port をインストールするのと全く同じようにできます. &prompt.root; cd /usr/ports/emulators/linux_base &prompt.root; make install distclean これで Linux バイナリ互換機能が使えるはずです. いつかのプログラムはシステムライブラリのマイナーバージョンが違うと文句を言うかもしれませんが一般的には大した問題ではありません. 手動でのライブラリのインストール portsコレクションをインストールしていない場合, 代わりに手動でライブラリをインストールすることができます. プログラムが必要とする Linux のシェアードライブラリとランタイムリンカが必要です. また Linux ライブラリ用の shadow root ディレクトリ, /compat/linux, を作成する必要があります. FreeBSD で動作する Linux プログラムが使用するシェアードライブラリは, まずこのファイルツリーから検索されます. 例えば, Linux のプログラムが /lib/libc.so をロードしようとした場合には, FreeBSD はまず /compat/linux/lib/libc.so を開こうとします. これが存在しなかった場合には, 次に /lib/libc.so を試します. シェアードライブラリは, Linux の ld.so が報告するパスではなく, /compat/linux/lib 以下にインストールする 必要があります. Linux のプログラムが必要とする シェアードライブラリを探す必要があるのは, FreeBSD のシステムに Linux のプログラムをインストールする最初の数回だけでしょう. それが過ぎれば, 十分な Linux のシェアードライブラリがシステムにインストールされ, 新しくインストールした Linux のバイナリも余計な作業をせずに動作させることができるようになります. シェアードライブラリの追加 linux_base port をインストールした後に, アプリケーションが必要なライブラリが存在しないというエラーを出したらどうしたらよいでしょうか? Linux のバイナリがどのシェアードライブラリを必要とし, そしてどこで入手できるか, どのように探したらよいでしょうか? 基本的には, 以下の 2 種類の方法があります (以下の手順に従う場合には, 必要なインストール作業をおこなう FreeBSD システム上で root として作業をおこなう必要があります). Linux システムにアクセス可能ならば, そのアプリケーションがどういうシェアードライブラリを必要としているのか調べ, 単に FreeBSD にそのライブラリをコピーするだけです. 次の例を見てみましょう. FTP を使って Doom の Linux バイナリを取ってきて, アクセスできる Linux システムに置いたとしましょう. 次のように ldd linuxdoom とするだけでどのシェアードライブラリが必要かチェックできます. &prompt.user; ldd linuxxdoom libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0 libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0 libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 最後のカラムに表示されているすべてのファイルを持って来て, /compat/linux の下に置き, 最初のカラムに示されるファイル名にシンボリックリンクを張ります. すなわち, FreeBSD システムでは以下のようなファイルが必要となります. /compat/linux/usr/X11/lib/libXt.so.3.1.0 /compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0 /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29
最初のカラムに表示されているファイルとメジャーバージョンが同じ Linux シェアードライブラリを既にインストールしている場合は, 新たにコピーする 必要はありません. 既にあるライブラリで動作するはずです. ただ, 新しいバージョンのものをコピーすることをお奨めします. 新しいライブラリにシンボリックリンクを変更したら, 古いライブラリは削除してかまいません. /compat/linux/lib/libc.so.4.6.27 /compat/linux/lib/libc.so.4 -> libc.so.4.6.27 従って, 以上のようなライブラリがインストールされており, 新しいバイナリに対する ldd の出力が以下のようになる場合を考えます. libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29 このように最後の番号が1つか2つ古いだけならば, 普通は /lib/libc.so.4.6.29 をコピーする必要はありません. わずかに古いライブラリでもプログラムは動作するはずだからです. もちろん, 以下のように新しいライブラリと置き換えても構いません. /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29
シンボリックリンクのメカニズムは Linux バイナリにのみ必要なことに注意してください. FreeBSD のランタイムリンカはメジャーリビジョン番号の一致したライブラリを検索するので, ユーザが気にする必要はありません.
Linux の ELF バイナリのインストール ELF のバイナリを使うためには, マークをつける (branding) 作業が必要になります. マークのない ELF バイナリを実行しようとすると以下のようなエラーメッセージを受けとってしまうことでしょう. &prompt.user; ./my-linux-elf-binary ELF binary type not known Abort カーネルが FreeBSD の ELF バイナリと Linux のバイナリとを 見分けられるようにするためには, &man.brandelf.1; ユーティリティを以下のようにして使ってください. &prompt.user; brandelf -t Linux my-linux-elf-binary 今ではGNU のツールたちが ELF バイナリに自動的に適切なマークを付加するようになったので, 今後はこの作業もだんだんと必要なくなってゆくでしょう. ホストネームリゾルバの設定 DNS がうまく動作しなかったり, 以下のようなエラーメッセージが表示され る場合は, /compat/linux/etc/host.conf ファイルを設定する必要があります. resolv+: "bind" is an invalid keyword resolv+: "hosts" is an invalid keyword ファイルの内容を以下のように設定してください. order hosts, bind multi on ここで, order は /etc/hosts を最初に検索し, 次にDNSを検索するように指定します. /compat/linux/etc/host.conf がインストールされていない場合, Linux アプリケーションは FreeBSD の /etc/host.conf を使用しようとして, 文法の違いによる警告を出力します. /etc/resolv.conf を利用してネームサーバの設定をしていない場合には, bind を削除してください. Mathematica のインストール Mathematica 4.x 用に &a.murray; がアップデートし, Bojan Bistrovic bojanb@physics.odu.edu がマージしました. この章では, Mathematica 4.X Linux 版の FreeBSD へのインストールについて説明します. Linux 版の Mathematica は FreeBSD においても完璧に動きます. ただ, 実行する際に Linux ABI を用いる必要があることを FreeBSD に教えるために, Wolfram によって出荷されているバイナリにマーク付け (branded) をする必要があります. Mathematica や Mathematica for Students の Linux 版は Wolfram (http://www.wolfram.com/) から直接注文することができます. Linux バイナリへのマーク付け (branding) Linux 用バイナリは Wolfram の Mathematica CD-ROM の Unix ディレクトリにあります. インストーラーを起動する前にこのディレクトリをローカルディスクにコピーし, &man.brandelf.1; により Linux バイナリにマークを付けます. &prompt.root; mount /cdrom &prompt.root; cp -rp /cdrom/Unix/ /localdir/ &prompt.root; brandelf -t Linux /localdir/Files/SystemFiles/Kernel/Binaries/Linux/* &prompt.root; brandelf -t Linux /localdir/Files/SystemFiles/FrontEnd/Binaries/Linux/* &prompt.root; brandelf -t Linux /localdir/Files/SystemFiles/Installation/Binaries/Linux/* &prompt.root; brandelf -t Linux /localdir/Files/SystemFiles/Graphics/Binaries/Linux/* &prompt.root; brandelf -t Linux /localdir/Files/SystemFiles/Converters/Binaries/Linux/* &prompt.root; brandelf -t Linux /localdir/Files/SystemFiles/LicenseManager/Binaries/Linux/mathlm &prompt.root; cd /localdir/Installers/Linux/ &prompt.root; ./MathInstaller また以下のようにすると, マーク付けされていない ELF バイナリすべての扱いを, デフォルトで Linux バイナリとすることが可能です. &prompt.root; sysctl -w kern.fallback_elf_brand=3 これは FreeBSD システムに対して, マーク付けされていない ELF バイナリが Linux ABI を利用するように設定します. こうすることで, CDROM から直接インストーラを実行することが可能になります. Mathematica パスワードの取得 Mathematica を起動する前に Wolfram から自分の マシン ID に対応したパスワードを取得しなければいけません. 一旦 Linux 互換ランタイムライブラリをインストールし, Mathematica を展開すれば Install ディレクトリにある mathinfo プログラムを起動して マシン ID を得ることができます. このマシン ID は, 最初に見つかったイーサネットカードの MAC アドレスをベースに生成されます. &prompt.root; cd /localdir/Files/SystemFiles/Installation/Binaries/Linux &prompt.root; mathinfo disco.example.com 7115-70839-20412 電子メールや電話, FAXなどでWolfram に登録する時にはこの マシン ID を渡します. するといくつかの数字から構成されるパスワードが返されるので, 他の Mathematica プラットホームでするのと全く同じように最初に Mathematica を立ち上げる時にその情報を入力します. ネットワーク経由での Mathematica フロントエンドの起動 Mathematica は標準フォントセットにない特別な記号 (積分記号, 総和記号, ギリシャ文字など) を表示するために特殊なフォントを使用します. X プロトコルは, これらのフォントがローカルマシンにインストールされていることを要求します. これはつまり, ローカルマシンに (CD-ROM や Mathematica がインストールされているホストマシンから) そのフォントをコピーしなければならないということです. これらのフォントは通常, CD-ROM の /cdrom/Unix/Files/SystemFiles/Fonts か, もしくはハードディスクの /usr/local/mathematica/SystemFiles/Fonts に置かれており, 実際に使用されるフォントは Type1 と X のサブディレクトリに格納されています. これらを利用するには次のような二つ方法があります. 一つは, フォントファイルをすべて /usr/X11R6/lib/X11/fonts/ 以下にある既存のフォントディレクトリにコピーする方法です. この場合, fonts.dir にフォント名を追加し, 先頭行のフォント総数を変更することも必要になります. あるいは, フォントをコピーしたディレクトリで mkfontdir を実行するだけでもかまいません. もう一つの方法は, /usr/X11R6/lib/X11/fonts/ にフォントディレクトリごとコピーする方法です. &prompt.root; cd /usr/X11R6/lib/X11/fonts &prompt.root; mkdir X &prompt.root; mkdir MathType1 &prompt.root; cd /cdrom/Unix/Files/SystemFiles/Fonts &prompt.root; cp X/* /usr/X11R6/lib/X11/fonts/X &prompt.root; cp Type1/* /usr/X11R6/lib/X11/fonts/MathType1 &prompt.root; cd /usr/X11R6/lib/X11/fonts/X &prompt.root; mkfontdir &prompt.root; cd ../MathType1 &prompt.root; mkfontdir そして, フォントパスに新しいフォントディレクトリを追加します. &prompt.root; xset fp+ /usr/X11R6/lib/X11/fonts/X &prompt.root; xset fp+ /usr/X11R6/lib/X11/fonts/MathType1 &prompt.root; xset fp rehash XFree86 サーバを使用しているなら, /etc/XF86Config に加えることでこれらのフォントを自動的に読み込むことができます. /usr/X11R6/lib/X11/fonts/Type1 という ディレクトリが存在していない場合には, 上記例の MathType1 を Type1 とすることができます. Oracle のインストール Marcel Moolenaar 寄贈 marcel@cup.hp.com はじめに このドキュメントでは Oracle 8.0.5 と Oracle 8.0.5.1 Enterprise Edition の Linux 版を FreeBSD にインストールするための手順を解説します. Linux 環境のインストール まずは Ports Collection から linux_base と linux_devtools をインストールしてください. これらの ports は FreeBSD 3.2 のリリース後にコレクションに加えられました. もし FreeBSD 3.2 もしくはそれよりも古いものを使っている場合は ports コレクションをアップデートしましょう. ついでに FreeBSD をアップデートするのもいいでしょう. もし linux_base-6.1 や linux_devtools-6.1 でうまくいかなければ 5.2 を試してみてください. もし賢いエージェント (intelligent agent) を起動したいなら Red Hat TCL パッケージ tcl-8.0.3-20.i386.rpm もインストールする必要があるでしょう. 公式の RPM パッケージをインストールするには一般的に次のようにします. &prompt.root; rpm -i --ignoreos --root /compat/linux --dbpath /var/lib/rpm package パッケージのインストール時にエラーが出てはいけません. Oracle 環境の構築 Oracleをインストールする前に, 適切な環境を設定する必要があります. このドキュメントでは, Oracle のインストールガイドに書いてあるようなことではなく FreeBSD で Linux 用 Oracle を動かすために特別に必要なことのみを解説します. カーネルのチューニング Oracle インストールガイドにあるように, シェアードメモリーの最大サイズを設定しなければいけません. FreeBSD では SHMMAX を使わないようにしてください. SHMMAX は単に SHMMAXPGS と PGSIZE から計算されるだけなのです. 従って, SHMMAXPGS を使うようにしましょう. インストールガイドに記述されている他のオプションは使えます. 例えば以下のようにします. options SHMMAXPGS=10000 options SHMMNI=100 options SHMSEG=10 options SEMMNS=200 options SEMMNI=70 options SEMMSL=61 これらのオプションを意図した Oracle の使い方に合わせて設定してください. また, 次のオプションがカーネルのコンフィギュレーションファイルにあることも確認します. options SYSVSHM #SysV shared memory options SYSVSEM #SysV semaphores options SYSVMSG #SysV interprocess communication Oracle 用アカウント 他のアカウントを作るのと同じように Oracle 用のアカウントを作ります. Oracle 用のアカウントに特別なのは Linux のシェルを割り当てるところだけです. /etc/shells に /compat/linux/bin/bash を加え, Oracle 用のアカウントに設定します. 環境設定 ORACLE_HOME や ORACLE_SID といった通常の Oracle 用の変数の他に次の変数も設定しなければなりません. 変数 値 LD_LIBRARY_PATH $ORACLE_HOME/lib CLASSPATH $ORACLE_HOME/jdbc/lib/classes111.zip PATH /compat/linux/bin /compat/linux/sbin /compat/linux/usr/bin /compat/linux/usr/sbin /bin /sbin /usr/bin /usr/sbin /usr/local/bin $ORACLE_HOME/bin 全ての環境変数は .profile で設定することをお勧めします. 完璧なサンプルは以下の通りです. ORACLE_BASE=/oracle; export ORACLE_BASE ORACLE_HOME=/oracle; export ORACLE_HOME LD_LIBRARY_PATH=$ORACLE_HOME/lib export LD_LIBRARY_PATH ORACLE_SID=ORCL; export ORACLE_SID ORACLE_TERM=386x; export ORACLE_TERM CLASSPATH=$ORACLE_HOME/jdbc/lib/classes111.zip export CLASSPATH PATH=/compat/linux/bin:/compat/linux/sbin:/compat/linux/usr/bin:/compat/linux/usr/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:$ORACLE_HOME/bin export PATH Oracle のインストール インストーラーを起動する前に, /var/tmp に .oracle という名前のディレクトリを作る必要がありますが, これは Linux エミュレーターにおけるちょっとした不整合のためです. このディレクトリは誰でもが書けるか, もしくは oracle ユーザーのものにしておきます. これで特に問題なく Oracle がインストールできるでしょう. もし問題が起こったら, まずは Oracle の配布物や設定をチェックしてください. Oracle のインストールが終わったら次の二つのサブセクションで解説するパッチを当てます. よくあるトラブルは, TCP プロトコルアダプターが正しくインストールされていないことです. そのため, 一切 TCP リスナーを起動することができないのです. 次の操作はこの問題を解決するのに役立ちます. &prompt.root; cd $ORACLE_HOME/network/lib &prompt.root; make -f ins_network.mk ntcontab.o &prompt.root; cd $ORACLE_HOME/lib &prompt.root; ar r libnetwork.a ntcontab.o &prompt.root; cd $ORACLE_HOME/network/lib &prompt.root; make -f ins_network.mk install もう一度 root.sh を起動するのを忘れないように! root.sh へのパッチ Oracle をインストールする時, root で行なう必要のあるいくつかの操作は root.sh と呼ばれるシェルスクリプトに記録されます. root.sh は orainst ディレクトリにあります. 次のパッチを root.sh に当てて 正しい場所にある chown コマンドを使うようにするか, 代わりに Linux ネイティブなシェルのもとでスクリプトを走らせましょう. *** orainst/root.sh.orig Tue Oct 6 21:57:33 1998 --- orainst/root.sh Mon Dec 28 15:58:53 1998 *************** *** 31,37 **** # This is the default value for CHOWN # It will redefined later in this script for those ports # which have it conditionally defined in ss_install.h ! CHOWN=/bin/chown # # Define variables to be used in this script --- 31,37 ---- # This is the default value for CHOWN # It will redefined later in this script for those ports # which have it conditionally defined in ss_install.h ! CHOWN=/usr/sbin/chown # # Define variables to be used in this script CD-ROM からのインストールでない場合は root.sh のソースにパッチを当ててもいいでしょう. rthd.sh という名前でソースツリーの orainst というディレクトリにあります. genclntsh へのパッチ genclntsh スクリプトは一つの共有クライアントライブラリを生成するのに用いられます. これはデモを作る時に使われます. PATH の定義をコメントアウトするために次のパッチを当ててください. *** bin/genclntsh.orig Wed Sep 30 07:37:19 1998 --- bin/genclntsh Tue Dec 22 15:36:49 1998 *************** *** 32,38 **** # # Explicit path to ensure that we're using the correct commands #PATH=/usr/bin:/usr/ccs/bin export PATH ! PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin export PATH # # each product MUST provide a $PRODUCT/admin/shrept.lst --- 32,38 ---- # # Explicit path to ensure that we're using the correct commands #PATH=/usr/bin:/usr/ccs/bin export PATH ! #PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin export PATH # # each product MUST provide a $PRODUCT/admin/shrept.lst Oracle の起動 インストラクションに従えば, Linux でと同じように Oracle を起動できるでしょう. 高度なトピックス Linux バイナリ互換機能がどのような仕組みなのか興味がある人はこのセクションを読んでください. 以下の文章で説明されていることのほとんどは &a.chat; に投稿された Terry Lambert (tlambert@primenet.com) 氏のメール (Message ID: <199906020108.SAA07001@usr09.primenet.com>). をもとにしています. どのように動くのでしょう? FreeBSD は, “実行クラスローダ(execution class loader)” と呼ばれる抽象的な機構を持っています. これは &man.execve.2 システムコールへの楔という形で実装されています. FreeBSD は, シェルインタプリタやシェルスクリプトを実行するための #! ローダを持った単一のプログラムローダではなく, ローダのリストを持っているのです. 歴史的には, UNIX プラットフォーム上の唯一のローダーがマジックナンバー (一般的にはファイルの先頭の 4 ないし 8 バイトの部分) の検査を行ないシステムで実行できるバイナリかどうかを検査し, もしそうならバイナリローダーを呼び出すというようになっていました. もし, そのシステム用のバイナリでない場合には, &man.execve.2; システムコールの呼び出しは失敗の戻り値を返し, シェルがシェルコマンドとして実行しようと試みていたわけです. この仮定は現在利用しているシェルがどのようなものであっても変わりません. 後に &man.sh.1; に変更が加えられ, 先頭の 2 バイトを検査した結果 :\n であれば代わりに &man.csh.1; を呼び出す, というようになりました(この変更は SCO が最初に行なったと思われます). 現在の FreeBSD は, プログラムローダリストを走査します. その際, 空白文字までの文字列をインタプリタとして認識する, 通常の #! ローダを用いるため, 該当するものが存在しなければ最終的に /bin/sh がロードされます. Linux ABI をサポートするため, FreeBSD は ELF バイナリを示すマジックナンバを確認します. (ただし, この段階では FreeBSD, Solaris, Linux, そしてその他の ELF イメージ形式を使っている OS を区別することはできません). ELF ローダは, 特殊なマーク (brand) があるかどうか探します. このマークとは, ELF イメージのコメントセクションのことです. SVR4/Solaris の ELF バイナリには, このセクションは存在しません. Linux バイナリを実行するためには, ELF バイナリに &man.brandelf.1; で説明されている Linux のマークが付けられていなければなりません. &prompt.root; brandelf -t Linux file 上のようにすることで, 指定されたファイルは Linux のマークが付けられ, ELF ローダが認識できるようになります. ELF ローダが Linux マークを確認すると, ローダは proc 構造体内の ある一つのポインタを置き換えます. システムコールは全て, このポインタ (伝統的な UNIX システムではこれは構造体の配列 sysent[] で, システムコールが含まれています) を通してインデックスされます. さらに, そのプロセスには Linux カーネルモジュールに必要な シグナルトランポリンコード(訳注: シグナルの伝播を実現するコード) 用の特殊なトラップベクタの設定や, 他の(細かな)調整のための設定が行なわれます. Linux システムコールベクタは, さまざまなデータに加えて sysent[] エントリーのリストを含んでおり, それらのアドレスはカーネルモジュール内にあります. Linux バイナリがシステムコールを発行する際, トラップコードは proc 構造体を用いてシステムコール関数ポインタを 解釈します. そして FreeBSD ではなく Linux 用のシステムコールエントリポイントを得るわけです. さらに, Linux モードは状況に応じてファイルシステム本来のルートマウントポイントを置き換えてファイルの参照を行ないます. これは, union オプションを指定してマウントされたファイルシステム (unionfs ではありません!)が行なっていることと同じです. ファイルを検索する際にはまず /compat/linux/original-path ディレクトリを, それから見つけられなかったときにのみ, /original-path を調べます. こうすることで, 他のバイナリを要求するバイナリの実行を可能にしています (したがって, Linux 用プログラムツールは Linux ABI サポート環境下で完全に動作するわけです). またこれは, もし対応する Linux バイナリが存在しない場合に Linux バイナリが FreeBSD バイナリをロードしたり, 実行したりすることが可能であること, その Linux バイナリに自分自身が Linux 上で実行されていないことを 気付かせないようにする目的で, &man.uname.1; コマンドを /compat/linux ディレクトリに置くことができる, ということを意味します. 要するに, Linux カーネルが FreeBSD カーネルの内部に存在しているわけです. カーネルによって提供されるサービス全ての実装の基礎となるさまざまな関数は FreeBSD システムコールテーブルエントリと Linux システムコールテーブルエントリの両方で共通に利用されています. これらにはファイルシステム処理, 仮想メモリ処理, シグナル伝送, System V IPC などが含まれますが, FreeBSD バイナリは FreeBSD グルー (訳注: glue; 二者の間を仲介するという意味) 関数群, そして Linux バイナリは Linux グルー関数群を用いる, という点だけが異なります(過去に存在したほとんどの OS は, 自分自身のためのグルー関数群しか備えていません. 前述したように, システムコールを発行する際, 各々のプロセスの proc 構造体内にある, ローダによって動的に初期化されるポインタを参照してアドレスを得る代わりに, 静的でグローバルな sysent[] 構造体の配列に システムコール関数のアドレスが直接格納されているのです). さて, どちらを本来の FreeBSD ABI (訳注: Applications Binary Interface; 同じ CPU を利用したコンピュータ間でバイナリを共有するための規約のこと) と呼ぶべきなのでしょうか? 実は, どちらが本来のものであるかということを論ずることに意味はありません. 基本的に, FreeBSD グルー関数群はカーネルの中に静的にリンクされていて, Linux グルー関数群は静的にリンクすることも, カーネルモジュールを介して利用することもできるようになっている, という違いがあるだけ (ただしこれは現時点においての話であり, 将来のリリースで変更される可能性がありますし, おそらく実際に変更されるでしょう) です. あ, 「でもこれは本当にエミュレーションと呼べるのか」って? 答えは「いいえ」です. これは ABI の実装であり, エミュレーションとは異なります. エミュレータが呼び出されているわけではありません (シミュレータでもないことをあらかじめ断っておきましょう). では, これがよく Linux エミュレーションと呼ばれるのは何故でしょうか? それはもちろん FreeBSD の売りにするため 8-) でもあるのですが, 実際には, 次のような理由によります. この機能が初めて実装された頃, 動作原理を説明する以外にこの機能を表現する言葉はありませんでした. しかし, コードをコンパイルしたりモジュールをロードしない場合, 「FreeBSD 上で Linux バイナリを実行する」という表現は, 厳密に考えると適切ではありません. そこで, その際にロードされているもの自身を表現する言葉—すなわち Linux エミュレータが必要だったのです. diff --git a/ja_JP.eucJP/books/handbook/mail/chapter.sgml b/ja_JP.eucJP/books/handbook/mail/chapter.sgml index ec23999241..d48fff99ef 100644 --- a/ja_JP.eucJP/books/handbook/mail/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/mail/chapter.sgml @@ -1,540 +1,540 @@ 電子メール - オリジナルは &a.wlloyd; によるものですが 1999 年 12 月 2 に + オリジナルは Bill Lloyd wlloyd@mpd.ca によるものですが 1999 年 12 月 2 に &a.jim; が書き直しました. 訳: &a.jp.mihoko;. 14 January 1997. この章では email 電子メール 電子メール, emailとしてのほうが知られているでしょう, は現代で最も広く利用されているコミュニケーション手段の一つです. 何百万人という人が毎日 email を使っており, この文章を偶然にもオンラインで読んでいるという人はこのカテゴリーに入るでしょうし, 複数の email アドレスを持っていたりもするかもしれません. 電子メールの設定は多くのシステム管理書籍のテーマになっています. もし自分のネットワーク用に一つメールホストを設定することよりもさらに高度なことをしようとするなら, しっかりとしたヘルプが必要でしょう. DNS email の設定におけるいくつかの部分は Domain Name System (DNS) の管理下にあります. 自分の DNS サーバーを立ち上げようと思っているなら, 必ず /etc/namedb と man -k named を一通り読むようにしてください. 電子メールを使う POP IMAP email の交換には 5 つの主要な部分があります. それらは ユーザープログラム, サーバーデーモン, DNS, POP もしくは IMAP のデーモン, そしてもちろん メールホストです. ユーザープログラム いくつか名前を挙げれば, mutt, pine, elm, そして mail, といったコマンドラインプログラムや balsa, xfmail のような GUI プログラム, WWW ブラウザーのようにさらに洗練されたものまであります. これらのプログラムは, email の処理を server daemons を呼び出したり TCP 経由で渡したり, といった手段でローカルの メールホストに任せるだけです. メールホストサーバデーモン メールサーバデーモン sendmail メールサーバデーモン postfix メールサーバデーモン qmail メールサーバデーモン exim 通常, これは sendmail (FreeBSD のデフォルト) や qmail, postfix, もしくは exim といった他のメールサーバーデーモンの一つです. 他にもあるのですが、以上のものが広く使われています. サーバーデーモンは通常 2 つの機能 — やってくるメールを受け取るのと出ていくメールを配送する, を持っています. メールを読むために POP や IMAP で接続する, ということはできません. そのためにはもう一つデーモンが必要なのです. いくつかの古いバージョンの sendmail には深刻なセキュリティー問題がありますが, 現在のバージョンを使っているおれば特に問題ないことに注意してください. 例のごとく, どんなソフトウェアを利用する時にも最新の状態にしておくのが大事なのです. Email and DNS Domain Name System (DNS) とそのデーモンである named は email の配送において大変重要な役割を担ってます. あなたのサイトからもう一つのサイトへメールを配送するためには, サーバーデーモンは DNS からそのサイトを探し, メールの受け取り先のホストを決定します. メールがあなたに送られた場合にも同じような仕組みになっています. DNS にはホスト名と IP アドレス, ホスト名とメールホストをマッピングするデータベースがあります. IP アドレスは A レコードで指定されます. MX (Mail eXchanger) レコードはあなた宛のメールを受け取るホストを指定します. あなたのホスト名に対する MX レコードがない場合には, メールは直接あなたのホストに配送されます. メールの受け取り email 受け取り メールはメールホストが受け取ります. このホストは送られてきたメールを集め, (ユーザーが) 読んだりピックアップしたりするために保存します. 保存されているメールをピックアップするにはメールホストに接続する必要があります. これは POP や IMAP を用いて行なわれます. メールホスト上で直接メールを読みたい時は POP や IMAP のサーバーは必要ありません. POP IMAP POP や IMAP のサーバーを走らせるためには 2 つのことをやらなければいけません. POP や IMAP のデーモンをports コレクションからインストールします. /etc/inetd.conf を修正して POP や IMAP のサーバーが起動されるように設定します. メールホスト メールホスト メールホストとは責任をもってメールを配送したり, あなたのホストや, もしかするネットワークも, に宛てたメールを受け取ったりするホストに与えられる名前です. トラブルシュート email トラブルシューティング ここには、いくつかのよく聞かれる質問とその答があります. それらは FAQ からこちらに移りました. どうして自分のサイトのホストなのに FQDN を使わなければいけないのですか? 恐らく, そのホストは実際には別のドメインにあるのでしょう. 例えば foo.bar.edu ドメインにいて, bar.edu というドメイン内の mumble というホストにアクセスしたいとします. この時は単に mumble ではなく mumble.bar.edu と FQDN で参照しなければなりません. BIND そもそも, BSD BIND のリゾルバー (resolver) ではこのようなことが可能でしたが, FreeBSD に入っている最新版の BIND では自分のドメイン以外に対する FQDN でない省略形は許されません. 従ってホストを mumble と曖昧に指定した場合は mumble.foo.bar.edu という名前があればそれになり, そうでなければ root ドメインから検索されます. これは, mumble.bar.edu と mumble.edu ということなったドメイン名に対してホスト名のサーチがおこなわれていた以前の振る舞いとは異なったものです. このような事が悪い例もしくはセキュリティホールとみなされる理由については RFC 1535 を見てください. /etc/resolv.conf で domain foo.bar.edu と書いてある行を search foo.bar.edu bar.edu と書き換えることで上のようなことができます. しかし, RFC 1535 にあるように検索順序が内部 (local) と外部 (public) の管理の境界をまたがないようにしてください. sendmail が mail loops back to myself というメッセージを出すのですが. sendmail FAQ に次のように書いてあります. * Local configuration error というメッセージが出ます. 例えば, 553 relay.domain.net config error: mail loops back to myself 554 <user@domain.net>... Local configuration error のような感じですが, どうしたら解決できますか? これは, 例えば domain.net のようなドメイン宛てのメールを MX レコードで特定のホスト(ここでは relay.domain.net) に送ろうとしたのに, そのホストでは domain.net 宛てのメールを受け取れるような設定になっていない場合です. 設定の際に FEATURE(use_cw_file) を指定してある場合には /etc/sendmail.cw の中に domain.net を追加してください. もしくは, /etc/sendmail.cf の中に Cw domain.net を追加してください. sendmail FAQ は /usr/src/usr.sbin/sendmail にありますので, メールの設定におかしなことがあれば常に読んでください. PPP ダイアルアップ PPP ホストで電子メールを使うにはどうしたらいいの? LAN 上にある FreeBSD マシンを, インターネットに接続したいとします. FreeBSD マシンは, その LAN でのメールゲートウェイになります. FreeBSD マシンは専用線接続ではありません (訳注:ダイアルアップ接続など). これには, 少なくとも二つの方法があります. UUCP 一つは UUCP を使うことです. このとき鍵になるのは, あなたのドメインに対するセカンダリ MX サービスを提供してくれるインターネットサイトをみつけることです. 例えば以下のように. bigco.com. MX 10 bigco.com. MX 20 smalliap.com. 最終的なメール受信先としては, 一つのホストだけが定義されるべきです (bigco.com 上の /etc/sendmail.cf ファイルに, Cw bigco.com を追加します). 送信側の sendmail が, メールを配送しようとしている時, モデムの接続を 介してあなたのところに接続しようとします. 大抵の場合, あなたのマシンがオンラインでないために, 接続はタイムアウト してしまうでしょう. sendmail は自動的に, メールをセカンダリの MX サイト に (あなたのインターネットプロバイダ) に配送します. セカンダリ MX サイトは, (/etc/rc.conf ファイル に sendmail_flag = "-bd -q15m"と書かれている場合) 15 分ごとに, プライマリ MX サイトにメールを配送しようと, あなたのホストに接続しに いきます. ログインスクリプトとして, このようなものを使うとよいでしょう. #!/bin/sh # Put me in /usr/local/bin/pppbigco ( sleep 60 ; /usr/sbin/sendmail -q ) & /usr/sbin/ppp -direct pppbigco ユーザごとにログインスクリプトを作りたい場合には, 上記 のスクリプトの代わりに, sendmail -qRbigco.com を使用する こともできます. このようにすると, キューの中の bigco.com に対する すべてのメールは, すぐに強制的に処理されます. さらに, 次のような改良もできます. 以下は, &a.isp; メイリングリストから抜粋してきたメッセージです. > 私たちはお客様に対して, セカンダリ MX を提供しています. > お客様は一日に何回か私たちのサービスに接続し, メールを彼らのプライマリ MX > に受け取ります (彼らのドメインに対するメールが到着した時には, > 私たちは彼らのサイトを呼び出しません). > 私たちの sendmail は, 30 分ごとにメールキューに溜っているメールを配送します. > ちょうどその時に, すべてのメールがプライマリ MX に送られたかどうかを確かめるためには, > 彼らは 30 分は オンラインでいなければなりません. > > すべてのメールを今すぐ送るために sendmail を初期化するコマンドはあるでしょうか? > もちろん私たちのマシン上には, ユーザはルート (root) 権限を持っていません. sendmail.cf の privacy flags セクションに, Opgoaway,restrictqrun の定義があります. root 以外のユーザがキューを処理できるようにするには, restrictqrun を削除してください. また, MX の再調整が必要かもしれません. あなたがたは, 顧客のサイトに対する一番優先度の高い MX なので, 次のように定義します: # If we are the best MX for a host, try directly instead of generating # local config error. OwTrue このようにすると, リモートサイトからのメールが, 顧客のマシンと接続しようとせず, 直接あなたがたのホストマシンに配送されるようになります. ホストマシンに配送されたメールは, 続いて顧客のマシンに送られます. これはホスト名にのみ有効なので, 顧客のメールマシンに, host.customer.com とは別に, customer.comも定義する必要があります. DNS 上で, customer.comに対する A レコードを定義してください. 先進的なトピックス これからのセクションでは, メールの設定やドメイン全体のためのメールの設定といったさらに突込んだ話題について触れます. 基本事項 email 設定 あなたのマシンに FreeBSD を普通にインストールして, /etc/resolv.conf ファイルを設定するか, またはネームサーバを走らせれば, 他のホストへ電子メールを送ることができるようになります. あなたのホスト宛のメールを特定のホストに配送するようにしたい場合には, 次の二つの方法があります. 自身でネームサーバーを実行し, 自分のドメインを持つ. 例えば FreeBSD.org. あなたのホストへ直接メールが配送されるようにする. これはメールがあなたのマシンの現在の DNS 名に直接配送されるようにすることにより実現できます. たとえば example.FreeBSD.org. SMTP 上のどちらを選ぶ場合でも, 自分のホストに直接メールが配送されるようにするには恒久的 (静的) な IP アドレス (動的な PPP ダイアルアップではない) を持っていなければなりません. もしファイアーウォールの中にいるならば, SMTP トラフィックが通過してくれないといけません. もし自分のホストでメールを受け取りたいならば, 次の二つのうちの一つができていることを確認してください. MX レコード 自分のドメインでの MX レコードが自分のホストの IP アドレスを差していることを確認する. 自分のドメインの中に自分のホスト用の MX がないことを確認する. 上のどちらかが設定されていれば, 自分のホストでメールを受け取ることができるでしょう. 次のコマンドを実行してみてください. &prompt.root; hostname example.FreeBSD.org &prompt.root; host example.FreeBSD.org example.FreeBSD.org has address 204.216.27.XX もしあなたのマシンが上記のメッセージだけを出力したならば, yourlogin@example.FreeBSD.org へのメールは問題なく配送されるでしょう. 上記のメッセージの代わりに, &prompt.root; host example.FreeBSD.org example.FreeBSD.org has address 204.216.27.XX example.FreeBSD.org mail is handled (pri=10) by hub.FreeBSD.org というメッセージが出力された場合は, あなたのホスト (example.FreeBSD.org) に宛てたメールは全て直接配送されずに hub 上の同じユーザー名に配送されます. 上の情報は DNS サーバーが扱います. メールルーティング情報をもつ DNS レコードは, Mail eXchange エントリーです. MX エントリが存在しない場合には, IP アドレスにしたがって, 直接宛先ホストに配送されます. freefall.FreeBSD.org の現時点での MX エントリは, 次のようになっています. freefall MX 30 mail.crl.net freefall MX 40 agora.rdrop.com freefall MX 10 freefall.FreeBSD.org freefall MX 20 who.cdrom.com freefall は多くの MX エントリを持っています. もっとも MX の値が小さいホストが最終的にメールを受け取ります. もし freefall が他の処理で忙しかったり, ダウンしているような場合には, 他のホストが一時的にメールをキューにいれます. 使い勝手をよくするためには, 代替の MX サイトは, それぞれ 別の経路でインターネットへ接続しているとよいでしょう. インターネットプロバイダまたは他の関連サイトが, このサービスを 提供することができます. あなたのドメインに対するメール設定 メールホスト (メールサーバーとしても知られています) をセットアップするためには, いろいろなワークステーションに宛てた全てのメールを受ける必要があります. 基本的には, あなたのドメイン (この場合だと *.FreeBSD.org) 宛ての全てのメールをハイジャックし, そのメールをあなたのメールサーバーに配送し, ユーザーが POP を通じてあるいはサーバー上で直接, メールをチェックできるようにします. DNS 話を簡単にするために, あるユーザーのアカウントはどのマシンでも同じユーザー名にすべきです. そのためには adduser を使ってください. 使用する予定のメールホストは, 各ワークステーションごとにメール交換が できるように設定されていなければなりません. これは, DNS (すなわち BIND や named) の設定で次のように行なうことができます. example.FreeBSD.org A 204.216.27.XX ; ワークステーション MX 10 hub.FreeBSD.org ; メールホスト これは, ワークステーションの A レコードがどこを指していようとも そのワークステーション宛てのメールをメールホストに転送する, というものです. 自前で DNS サーバを運用しているのでなければ, この作業は自分では行なえおこなえません. 自分で DNS サーバを運用しないとかできないという場合は, インターネットプロバイダ等に依頼して作業をおこなってもらってください. この作業により, このワークステーション宛のメールは, MX (メールエクスチェンジャ) ホストに送られるようになります. A レコードがどのマシンを指しているかどいうことには関係なく, メールは MX ホストに送られます. もしバーチャル電子メールホストを運用するなら次の情報が役に立つでしょう. 例として,あなたには自分のドメイン, ここでは customer1.org, を持っている顧客がいるとしましょう. あなたは customer1.org 宛ての全てのメールを mail.myhost.com という名前のメールホストに集めたいとします. DNS エントリーは次のようになるでしょう. customer1.org MX 10 mail.myhost.com そのドメインに対して電子メールを送りたいだけなら, A レコードは必要ありません. これは, customer1.org に対して ping を実行しても, A レコードが存在しない限りうまくいかないことに留意しておいてください. やらなければいけない最後のことは, メールホスト上の sendmail に対してどんあドメインやホスト宛のメールを受け取るのか, を教えることです. いくつかの方法がありますが次のどちらかでいいでしょう. FEATURE(use_cw_file) を使っているなら, /etc/sendmail.cw ファイルにホストを加えます. もし sendmail 8.10 かそれ以降のものであれば該当ファイルは /etc/mail/local-host-names です. /etc/sendmail.cf もしくは sendmail 8.10 以降なら /etc/mail/sendmail.cf といったファイルに Cwyour.host.com という行を加えます. diff --git a/ja_JP.eucJP/books/handbook/ppp-and-slip/chapter.sgml b/ja_JP.eucJP/books/handbook/ppp-and-slip/chapter.sgml index ebcccef0b6..507d34457e 100644 --- a/ja_JP.eucJP/books/handbook/ppp-and-slip/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/ppp-and-slip/chapter.sgml @@ -1,2792 +1,2794 @@ PPP と SLIP 改訂: &a.jim;, 2000 年 3 月 1 日. この章では もしあなたがモデムを使ってインターネットに接続したり, 他の人々に FreeBSD によるインターネットへのダイヤルアップ接続を 提供しようとしているのでしたら, PPP または SLIP 接続を選択することができます. この節では 3 種類の PPP について説明しています. それは ユーザ, カーネル, そして PPPoE (PPP オーバイーサネット) です. また SLIP のクライアントとサーバの設定についても記述しています. 最初に説明するのは, ユーザ PPP です. ユーザ PPP は FreeBSD に 2.0.5-RELEASE の時に, 既に存在していたカーネル実装の PPP に加えて導入されました. ユーザ PPP とカーネル PPP の主な違いは何かと疑問に思われるかも 知れませんが, その答えは簡単です. ユーザ PPP はデーモンとしては実行されず 必要に応じて実行されるのです. PPP インタフェイスを組み込んだカーネルは 必要ではなく, ユーザプロセスとして実行されカーネルとのデータの やり取りにはトンネルデバイスドライバ (tun) を 使用します. この節ではこれ以降ユーザ PPP のことは, pppd のような他の PPP ソフトウエアと特に区別する必要がある場合を除いて, 単に ppp と記述します. またこの節に記述されているコマンドは すべて root で実行されなければなりません. ユーザ ppp の利用 原作: &a.brian;, 協力: - &a.nik;, &a.dirkvangulik;, &a.pjc;. + &a.nik;, Dirk-Willem van Gulik Dirk.vanGulik@jrc.it, + Peter Childs pjchilds@imforei.apana.org.au. + ユーザ PPP 前提条件 以下の情報を手に入れておく必要があるでしょう: PPP で接続するインターネットサービスプロバイダ (ISP) のアカウント. さらに, 接続済みのモデム (またはその他のデバイス) があり, プロバイダとの接続が可能なように正しく設定されている. プロバイダの電話番号. ログイン名とパスワード. これは通常の unix 形式のログイン名と パスワードの組という場合もありますし, PPP PAP または CHAP の ログイン名とパスワードの組という場合もあります. 一つ以上のネームサーバの IP アドレス. 通常, プロバイダから IP アドレスを二つ指示されている はずです. 一つすら提供されていないならば, ppp.conf ファイル中で enable dns コマンドを使って ppp にネームサーバを設定するよう 指示できます. プロバイダからは以下の情報が提供されているはずですが, どうしても必要というわけではありません: プロバイダのゲートウェイの IP アドレス. ゲートウェイとは, あなたがそこに接続をおこなって, デフォルトルート として設定することになるマシンです. プロバイダがこのアドレスを明示していなくても, 最初は 適当に設定しておいて, 接続時にプロバイダの PPP サーバから 正しいアドレスを教えてもらうことができます. このアドレスは, ppp から HISADDRとして参照されます. プロバイダのネットマスク設定. プロバイダが明示していないとしても, ネットマスクとして 255.255.255.0 を使用しておけば問題ありません. もしプロバイダから固定の IP アドレスとホスト名の割り当てを 受けていれば, その情報を指定しておくこともできます. 割り当てを受けていなければ, 接続先から適切な IP アドレスを指定してもらいます. もし, 必要な情報が不足していれば, プロバイダに連絡を取って 確認しておいてください. ppp 対応カーネルの構築 説明でも述べているように, ppp はカーネルの tun デバイスを使います. 使っているカーネルがどれであっても, tun デバイスを設定しなければなりません. FreeBSDに付属しているデフォルトの GENERIC カーネルに合うように tun デバイスは前もって設定されています. しかしながら, 自分で修正したカーネルをインストールするのであれば, pppが正しく動くよう, カーネルが設定されているか確認しなくてはいけません. これを確認するには, カーネルコンパイルディレクトリ (/sys/i386/conf または /sys/pc98/conf) に移動して, カーネルコンフィグレーションファイルを調べます. 以下の行がどこかに含まれている必要があります. pseudo-device tun 1 この行がカーネルコンフィグレーションファイルに 含まれていない場合, この行を追加して カーネルの再コンパイルとインストールをおこなう必要があります. 元々の GENERIC カーネルは 標準でこれを含んでいますので, カスタムカーネルをインストールしているのではなかったり, /sys ディレクトリが存在しないのであれば, 何も変更する必要はありません. カーネルコンフィグレーションの詳細については, FreeBSD カーネルのコンフィグレーション を参照してください. 以下のコマンドを実行することで, 現在のカーネルにトンネルデバイスが いくつ組み込まれているかを調べることができます: &prompt.root; ifconfig -a tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 200.10.100.1 --> 203.10.100.24 netmask 0xffffffff tun1: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 576 tun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 203.10.100.1 --> 203.10.100.20 netmask 0xffffffff tun3: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 FreeBSD 4.0やより最近のリリースでは, すでに使われている tun デバイスしか見つけることが できないでしょう. これは, 全く tun デバイスを見つけることが できないかもしれないということです. しかし, もしこうなって しまっても, 心配することはありません. そのデバイスは ppp が使おうとする時に動的に作られるはず だからです. この例ではトンネルデバイスが四つ存在し, そのうち二つに 設定がおこなわれ, 使用中であることがわかります. 上の例で RUNNING フラグがオンになっている ものがありますが, これは そのインターフェースが何かに使用されていることを示している だけであるということに注意してください. つまり, RUNNING になっていない インターフェースがあったとしても, それはエラーではありません. トンネルデバイスがカーネルに組み込まれておらず, 何らかの理由で カーネルの再構築ができない場合でも, 方法がないわけではありません. 動的にデバイスをロードすることができるはずです. 詳細については &man.modload.8; や &man.lkm.4; など, 適切なマニュアルを参照してください. tun デバイスの確認 ほとんどのユーザは tun デバイス (/dev/tun0) が一つあれば充分でしょう. より多くのデバイスを使う場合 (すなわち, カーネルコンフィグレーション ファイルで pseudo-device tun の行に 1 以外の数値を指定している場合), 以下で tun0 と書かれている部分をすべて, あなたが使うデバイスの番号に あわせて読みかえてください. tun0 デバイスが正しく作成されていることを確認する最も簡単な方法は, それを作り直すことです. そのためには, 以下のコマンドを実行します: &prompt.root; cd /dev &prompt.root; ./MAKEDEV tun0 カーネルに 16 個のトンネルデバイスを組み込んだのであれば, tun0 だけでなく他の tun デバイスも作成しておく必要があるでしょう: &prompt.root; cd /dev &prompt.root; ./MAKEDEV tun15 また, カーネルが正しく設定されているかどうかを調べるために 以下のコマンドを実行して, このような出力が得られることを確認します: &prompt.root; ifconfig tun0 tun0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1500 まだ RUNNING フラグがセットされていない場合もあります. その時は以下のような出力が得られるでしょう: &prompt.root; ifconfig tun0 tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 前述したように, FreeBSD 4.0 以降のリリースでは tun デバイスは要求に応じて 作られるので, もしそのデバイスがまだ使われていなければ, 見つけられないかもしれないということを思い出してください. 名前の解決に関する設定 リゾルバ (resolver) はシステムの一部分で, IP アドレスとホスト名との 変換をおこないます. IP アドレスとホスト名を対応させるためのマップを, 二つの場所のうちの一つから探すように設定できます. 一つめは /etc/hosts (man 5 hosts) と呼ばれるファイルです. 二つめはインターネット ドメインネームサービス (DNS) と呼ばれる 分散データベースですが, これに関する議論は このドキュメントで扱う範囲を 越えていますので, これについての説明はおこないません. リゾルバは名前のマッピングを おこなうシステムコールの集合体です. ただし どこからマッピング情報を見つけるのかは, 最初に指示しておく必要があります. これは まず /etc/host.conf ファイルを編集することでおこないます. 混乱の元になりますので, このファイルを /etc/hosts.conf と 呼んだりしてはいけません (余分な s がついていますね). <filename>/etc/host.conf</filename> ファイルの編集 このファイルには 以下の 2 行が (この順番で) 書かれているはずです: hosts bind これは, 最初に /etc/hosts ファイルを調べ, そこで目的の名前が 見つけられなかった場合に DNS を引きにいくようリゾルバに指示します. /etc/hosts(5) ファイルの編集 このファイルはローカルネットワーク上に存在するマシンの IP アドレスと ホスト名を含んでいるはずです. 最低でも ppp を動作させるマシンのエントリが 含まれている必要があります. そのマシンのホスト名が foo.bar.com で, IP アドレスが 10.0.0.1 であると仮定すると, /etc/hosts は 以下の行を含んでいなければいけません: 127.0.0.1 localhost.bar.com localhost 127.0.0.1 localhost.bar.com. 10.0.0.1 foo.bar.com foo 10.0.0.1 foo.bar.com. 一つめの行は localhost を現在のマシンの別名として定義しています. マシン固有の IP アドレスが何であっても, この行の IP アドレスは 常に 127.0.0.1 でなければいけません. 二つめの行はホスト名 foo.bar.com (と, その省略形 foo) を IP アドレス 10.0.0.1 にマップします. もしプロバイダから固定の IP アドレスとホスト名を割り当てられて いるのであれば, それを 10.0.0.1 エントリのかわりに使ってください. <filename>/etc/resolv.conf</filename> ファイルの編集 /etc/resolv.conf はリゾルバの振舞いを指定します. もし自前の DNS サーバを走らせているのなら, このファイルは空のままに しておくこともできます. 通常は, 以下のように書いておく必要があるでしょう: domain bar.com nameserver x.x.x.x nameserver y.y.y.y x.x.x.x と y.y.y.y はプロバイダから指示されたアドレスで, 接続するプロバイダが提供しているネームサーバを すべて書いてください. domain に指定するのは このマシンのデフォルトのドメイン名で, おそらく 書かなくても問題は無いでしょう. このファイルの各エントリの詳細については, resolv.conf のマニュアルページを参照してください. バージョン 2 以降の ppp を使用している場合には, enable dns コマンドを使用してネームサーバのアドレスを プロバイダに問い合わせるように指示することができます. 上の指定とは異なるアドレスをプロバイダが指定してきた場合 (または /etc/resolv.conf でネームサーバが指定されていない場合), ppp はプロバイダが指定したアドレスで resolv.conf を書きかえます. <command>ppp</command> の設定 ユーザ ppp と pppd (カーネルレベルの PPP 実装) は どちらも /usr/share/examples/ppp ディレクトリに置かれた設定ファイルを使います. ここには設定ファイルのサンプルが用意されていて, ユーザ ppp の設定を おこなう際に大変参考になりますので, 削除したりしないでください. ppp の設定をするためには, 必要に応じていくつかのファイルを編集する必要が あります. 書き込む内容は, プロバイダが静的に IP アドレスを割り当てる (つまり, 固定の IP アドレスを一つ与えられて, 常にそれを使う) か, または動的に IP アドレスを割り当てる (つまり, PPP セッションごとに IP アドレスが変化する可能性がある) かということに ある程度依存します. 静的 IP アドレスによる PPP 接続 まず /etc/ppp/ppp.conf という設定ファイルを作成する必要があります. これは以下の例とほとんど同じようなものになるでしょう. : で終る行は 1 カラム目から始め, その他の行はスペースまたはタブで以下の例のように 段をつける (インデントする) 必要があります. 1 default: 2 set device /dev/cuaa0 3 set speed 115200 4 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\TTIMEOUT 40 CONNECT" 5 provider: 6 set phone "(123) 456 7890" 7 set login "TIMEOUT 10 \"\" \"\" gin:--gin: foo word: bar col: ppp" 8 set timeout 300 9 set ifaddr x.x.x.x y.y.y.y 255.255.255.0 0.0.0.0 10 add default HISADDR 11 enable dns ファイルでは行番号を取り除いておいてください. これは解説の際に参照する行を示すためにつけたものです. Line 1: デフォルトエントリを指定します. このエントリ中のコマンドは ppp が起動された際に自動的に実行されます. Line 2: モデムが接続されているデバイスを指定します. COM1: は /dev/cuaa0 に, COM2: は /dev/cuaa1 になります. Line 3: 通信速度 (DTE 速度) を指定します. もし 115200 が使えない (最近のモデムなら大抵使えるはずですが) 場合には, かわりに 38400 を指定してみてください. Line 4: ダイアルスクリプトを指定します. ユーザ PPP は &man.chat.8; 言語に似た, 受信待ち文字列と 送信文字列の対からなるスクリプトを使用します. この言語の機能に関しては, マニュアルページを参照してください. Line 5: 接続するプロバイダの名前 provider を エントリ名として指定します. Line 6: このプロバイダの電話番号を指定します. 複数の電話番号を : や | で区切って指定することができます. これら区切り文字の違いについては, &man.ppp.8 に 詳しく書かれています. 要約すると, 毎回違う番号に かけたいのであれば : を使います. 常に まず先頭の番号にかけてみて, つながらない時にだけ 2 番目以降の番号に かけたいのであれば | を使います. 例に示されているように, 常に電話番号全体を引用符で くくって (クォートして) おきます. Line 7: ダイアルスクリプトと同様に, ログインスクリプトも chat 言語風の記述をおこないます. この例は, 以下のようなログインセッションを使用する プロバイダのためのものです: J. Random Provider login: foo password: bar protocol: ppp このスクリプトは必要に応じて 書きかえなければならないでしょう. 初めてスクリプトを書く時には, 予想した通りに 処理が進んだかどうかを確認するため, chat ログを とるようにしておいた方が良いでしょう. PAP や CHAP を使用する場合には, ここでログインすることは ありませんから, ログイン文字列は空白のままにしておくべきです. 詳細については PAP および CHAP による認証を参照してください. Line 8: デフォルトの接続タイムアウト時間を (秒数で) 指定します. この例では, 300 秒間 通信がおこなわれなければ 自動的に接続を切るように指定しています. タイムアウトさせたくない場合には, この値を 0 に設定します. Line 9: インターフェースのアドレスを指定します. 文字列 x.x.x.x は プロバイダに割り当てられた IP アドレスで置きかえてください. 文字列 y.y.y.y はプロバイダから指示されたゲートウェイ (接続先となるマシン) の IP アドレスで置きかえてください. プロバイダがゲートウェイのアドレスを 指示していない場合は, 10.0.0.2/0 を使用しておいてください. もし 仮の アドレスを使用する必要がある場合には, 動的 IP アドレスによる PPP 接続に関する指示に従って, /etc/ppp/ppp.linkup にエントリを作成していることを 確認してください. この行が省略されている場合, ppp を モードで動作させることはできません. Line 10: プロバイダのゲートウェイへの経路を デフォルトルートとして 追加します. 特殊文字列 HISADDR は, 9 行目で指定された ゲートウェイのアドレスで置きかえられます. HISADDR は 9 行目までは初期化されていませんので, その行よりも後でしか使えないことに 注意してください. Line 11: ネームサーバのアドレスが正しいか どうかを確認するため, プロバイダに問い合わせをおこなうよう ppp に指示します. プロバイダがこの機能をサポートしていれば, ppp は /etc/resolv.conf のネームサーバエントリを 正しいアドレスに更新することができます. 静的な IP アドレスを持っていて, 接続が完了する前にルーティングテーブルの エントリが正しく設定されているのであれば, ppp.linkup に エントリを追加する必要はありません. しかし, この場合でもエントリを追加して, 接続が完了した時点で プログラムを呼び出したいことがあるかもしれません. これについては後ほど sendmail を例として説明します. これらの設定ファイルのサンプルが /usr/share/examples/ppp ディレクトリに 置かれています. 動的 IP アドレスによる PPP 接続 プロバイダが静的な IP アドレスの割り当てをおこなっていない場合, ppp が相手側のホスト (ゲートウェイ) と交渉して, こちら側と相手側のアドレスを 決めるように設定することができます. これは, 起動時には仮のアドレスを使っておいて, 接続後に IP コンフィグレーション プロトコル (IPCP) を使用して ppp が IP アドレスを正しく設定できるようにすることで実現されます. 静的 IP アドレスによる PPP 接続に 以下の変更を加える以外は, ppp.conf の設定は同じです: 9 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 繰り返しますが, 行番号は取り除いておいてください. これは解説の際に参照する行を示すためにつけたものです. なお, 少なくともスペース 1 個分の段づけ (インデント) が必要です. Line 9: / 文字の後ろの数字は, アドレス交渉の際に固定しておきたい ビットの数です. 場合によっては, もっと適切な IP アドレスを 指定しておきたいこともあるかもしれませんが, ほとんどの場合には 上の例の通りで問題ありません. 最後の引数 (0.0.0.0) は, アドレスの交渉の際に 10.0.0.1 ではなく 0.0.0.0 を使用するよう ppp に指示するためのものです. set ifaddr コマンドの最初の引数として 0.0.0.0 を指定してはいけません. さもないと, モードで動作させる際に 初期経路を設定することができなくなります. バージョン 1.X の ppp を使用する場合, /etc/ppp/ppp.linkup にもエントリを作成しておく必要があります. ppp.linkup は接続が確立された後に使用されます. この時点では, ppp は実際にどの IP アドレスを使うべきなのか わかっているはずです. 以下のエントリは存在する仮の経路を削除し, 正しい経路を作成します: 1 provider: 2 delete ALL 3 add default HISADDR Line 1: 接続を確立する際に, ppp は以下のルールに従って ppp.linkup のエントリを検索します: まず ppp.conf で使用されたのと同じラベルを探します. もし見つからなければ, ゲートウェイの IP アドレスのエントリを 探します. このエントリは 4 オクテットの IP アドレス形式の ラベルです. それでも まだエントリが見つからなければ, MYADDR エントリを探します. Line 2: この行は, 使用する tun インターフェースに関する既存の経路を (ダイレクトルートのエントリを除き) すべて削除するよう ppp に指示します. Line 3: この行は HISADDR への経路をデフォルトルートとして 追加するように ppp に指示します. HISADDR は IPCP で 決定されたゲートウェイの IP アドレスで置きかえられます. 詳細なサンプルについては, /usr/share/examples/ppp/ppp.conf.sample ファイル中のpmdemand エントリと /usr/share/examples/ppp/ppp.linkup.sample を参照してください. バージョン 2 の ppp から sticky routes が導入されました. MYADDR や HISADDR を含む add コマンドと delete コマンドを記憶して, MYADDR や HISADDR の アドレスが変化した際には経路の再設定をおこないます. したがって, これらのコマンドを ppp.linkup に 繰り返し記述する必要は無くなりました. かかってきた電話を <command>ppp</command> で受けるには かかってきた電話を ppp が受けるように設定する際に, そのマシンが LAN に接続されているのであれば, パケットを LAN に転送するかどうかを決定する必要があります. 転送をおこなう場合には, その LAN のサブネットから IP アドレスを ppp クライアントに割り当て, 以下のコマンドを指定するのが良いでしょう. gateway_enable=YES どの getty を使いますか? getty でダイアルアップサービスをおこなう場合の優れた解説が FreeBSD でダイアルアップサービスをおこなうための設定 にあります. getty に代わるものとしては, mgetty があります. これは getty をより柔軟にしたもので, ダイアルアップ回線での使用を意図して 設計されています. mgetty を使う場合の利点は, mgetty が積極的にモデムと通信する ということです. つまり, もし /etc/ttys でポートを閉じている場合, モデムは電話をとらなくなります. 最近のバージョンの mgetty (0.99beta 以降) では, PPP ストリームの 自動検出もサポートされています. これにより, クライアント側で スクリプトを準備しなくてもサーバに アクセスすることができます. mgetty に関する, より詳細な情報については Mgetty と AutoPPP を参照してください. ppp の実行許可 ppp は通常, ID 0 のユーザ (root) として動作しなければいけませんが, 以下で説明するように, ppp を通常のユーザとしてサーバモードで実行させたい 場合には, そのユーザを /etc/group の network グループに 追加して, ppp を実行する許可を与えておかなければいけません. また, そのユーザが設定ファイル内の目的のエントリに アクセスできるように, 以下のように allow コマンドで許可を与えておく必要があります: allow users fred mary このコマンドがデフォルトエントリに 書かれている場合には, 指定されたユーザは すべてのエントリをアクセスできるようになります. 動的 IP ユーザのための ppp シェルの設定 /etc/ppp/ppp-shell という名前で, 以下のような内容のファイルを 作成します: #!/bin/sh IDENT=`echo $0 | sed -e 's/^.*-\(.*\)$/\1/'` CALLEDAS="$IDENT" TTY=`tty` if [ x$IDENT = xdialup ]; then IDENT=`basename $TTY` fi echo "PPP for $CALLEDAS on $TTY" echo "Starting PPP for $IDENT" exec /usr/sbin/ppp -direct $IDENT このスクリプトには実行可能属性をつけておきます. 次に, 以下のコマンドを実行し, ppp-dialup という名前で このスクリプトへのリンクを作成します: &prompt.root; ln -s ppp-shell /etc/ppp/ppp-dialup すべてのダイアルアップ ppp ユーザのログインシェルとして このスクリプトを使用します. 以下は pchilds というユーザ名の ダイアルアップユーザを /etc/password へ登録した場合の例です. (パスワードファイルを直接エディタで編集したりせず, vipw を使ってください) pchilds:*:1011:300:Peter Childs PPP:/home/ppp:/etc/ppp/ppp-dialup 任意のユーザが読むことのできる, /home/ppp ディレクトリを 作成します. /etc/motd が表示されないようにするため, このディレクトリには以下のように大きさが 0 バイトのファイルを 作成しておきます. -r--r--r-- 1 root wheel 0 May 27 02:23 .hushlogin -r--r--r-- 1 root wheel 0 May 27 02:22 .rhosts 静的 IP ユーザのための PPP シェルの設定 上記と同じように ppp-shell ファイルを作成し, 静的な IP アドレスを割り当てるアカウントそれぞれについて ppp-shell へのシンボリックリンクを作成します. 例えば, クラス C ネットワークの経路制御を必要とする, 三人のダイアルアップユーザ fred, sam, mary がいるとすると, 以下のコマンドを実行することになります: &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-sam &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-mary これらのユーザのダイアルアップアカウントでは, 上で作成した それぞれのシンボリックリンクを ログインシェルとして設定しておきます. (つまり, ユーザ mary のログインシェルは /etc/ppp/ppp-mary に なります). 動的 IP ユーザのための ppp.conf の設定 /etc/ppp/ppp.conf ファイルは, 大体以下のような内容になるでしょう: default: set debug phase lcp chat set timeout 0 ttyd0: set ifaddr 203.14.100.1 203.14.100.20 255.255.255.255 enable proxy ttyd1: set ifaddr 203.14.100.1 203.14.100.21 255.255.255.255 enable proxy 上の例のように段をつける (インデントする) 必要があることに注意してください. default: エントリはセッションごとにロードされます. /etc/ttys で有効にしてある各ダイアルアップ回線ごとに一つ, 上記の ttyd0: のようなエントリを作成します. 各行の相手側アドレスとして, それぞれ別の IP アドレスを 動的 IP ユーザのための IP アドレスのプールから割り当てておく必要があります. 静的 IP ユーザのための <filename>ppp.conf</filename> の設定 上のサンプルの /usr/share/examples/ppp/ppp.conf の内容に加えて, 静的に IP を割り当てられたダイアルアップユーザ それぞれのためのエントリを追加する必要があります. ここでも fred, sam, mary の例を使うことにしましょう. fred: set ifaddr 203.14.100.1 203.14.101.1 255.255.255.255 sam: set ifaddr 203.14.100.1 203.14.102.1 255.255.255.255 mary: set ifaddr 203.14.100.1 203.14.103.1 255.255.255.255 必要であれば, それぞれの静的 IP ユーザに対する経路制御情報も /etc/ppp/ppp.linkup ファイルに書いておくべきでしょう. 以下の例ではクライアントの PPP リンクを経由する, クラス C の 203.14.101.0 ネットワークへの経路を追加しています. fred: add 203.14.101.0 netmask 255.255.255.0 HISADDR sam: add 203.14.102.0 netmask 255.255.255.0 HISADDR mary: add 203.14.103.0 netmask 255.255.255.0 HISADDR <command>mgetty</command>, AutoPPP, マイクロソフト拡張の詳細 <command>mgetty</command> と AutoPPP AUTO_PPP オプションつきでコンパイルした mgetty を使えば, mgetty が PPP 接続の LCP フェーズを検出して, 自動的に PPP シェルを起動するように 設定することができます. しかし この場合, デフォルトの login/password シーケンスは発生しないので, ユーザの認証は PAP または CHAP を使っておこなう必要があります. このセクションでは, ユーザ (あなた) が問題なく AUTO_PPP オプションつきの mgetty (v0.99beta またはそれ以降) の設定, コンパイル, インストールができているものと仮定しています. /usr/local/etc/mgetty+sendfax/login.config ファイルが 以下の行を含んでいることを確認してください: /AutoPPP/ - - /etc/ppp/ppp-pap-dialup これにより, PPP 接続を検出したら mgetty が ppp-pap-dialup スクリプトを実行するようになります. /etc/ppp/ppp-pap-dialup という名前で, 以下のような内容のファイルを 作成します (このファイルには実行可能属性を つけておく必要があります): #!/bin/sh exec /usr/sbin/ppp -direct pap さらに, かかってきた電話すべてを自分で扱うエントリを /etc/ppp/ppp.conf に作成します. pap: enable pap set ifaddr 203.14.100.1 203.14.100.20-203.14.100.40 enable proxy この方法でログインする それぞれのユーザは, PAP によるユーザ認証を おこなうために /etc/ppp/ppp.secret ファイルにユーザ名とパスワードを 書いておくか, または /etc/password ファイルを使うように, enable passwdauth ユーザに静的な IP アドレスを割り当てる場合には, そのアドレスを /etc/ppp/ppp.secret の第三引数として指定することができます. サンプルについては, /usr/share/examples/ppp/ppp.secret.sample を参照してください. マイクロソフト拡張 クライアントからの要求に応じて, ppp が DNS や NetBIOS ネームサーバの アドレスを通知するように 設定をおこなうこともできます. バージョン 1.X の ppp で これらの拡張機能を有効にするには, 以下の行を /etc/ppp/ppp.conf の適切なセクションに追加する必要があるでしょう. enable msext set ns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 バージョン 2 以降の ppp では, 以下のようになります: accept dns set dns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 これにより, クライアントはプライマリと セカンダリのネームサーバアドレス および NetBIOS ネームサーバホストを知ることができます. バージョン 2 以降の ppp では, set dns の行を省略した場合には /etc/resolv.conf に書かれているネームサーバのアドレスを使用します. PAP および CHAP による認証 いくつかのプロバイダでは, PAP または CHAP のいずれかの認証メカニズムを 使用して接続時の認証をおこなうように システムを設定しています. この場合, プロバイダは接続の際に login: プロンプトを送信せず, 最初から PPP で通信を始めようとするでしょう. PAP ではパスワードがそのまま送られてしまうため, CHAP に比べると安全性が 低くなりますが, このパスワードはシリアル回線のみを通して送られます. そのため, クラッカーが 盗み聞き する余地は多くないので, 通常ここの セキュリティは問題にはなりません. 静的 IP アドレスによる PPP 接続または 動的 IP アドレスによる PPP 接続の セクションに戻って, 以下の変更をおこないます: 7 set login … 12 set authname MyUserName 13 set authkey MyPassword これまでと同様に, 行番号は取り除いておいてください. これは解説の際に参照する行を示すためにつけたものです. なお, 少なくともスペース 1 個分の段づけ (インデント) が必要です. Line 7: PAP または CHAP を使用する場合, 通常 プロバイダはサーバへの ログインを必要としません. そのため, set login 文字列を 無効にしておかなければいけません. Line 12: この行は PAP/CHAP ユーザ名を指定します. MyUserName に 正しい値を入れておく必要があります. Line 13: この行は PAP/CHAP パスワードを指定します. MyPassword に 正しい値を入れておく必要があります. PAP と CHAP はデフォルトで両方とも 受け付けられるようになって いますが, PAP や CHAP を使用するという 意思を明示するために, 15 accept PAP または 15 accept CHAP という行を追加しておくのも良いでしょう. 動作中の ppp の設定変更 適切な診断ポートが設定されている場合には, バックグラウンドで動作中の ppp プログラムと通信することができます. この設定をおこなうためには, 以下の行を設定ファイルに追加しておきます: set server /var/run/ppp-tun%d DiagnosticPassword 0177 これにより, ppp は指定された unix ドメインの ソケットをモニタして, クライアントから正しいパスワードを受け取った後に アクセスを許可します. このソケット名に含まれる %d は, この ppp が使用している tun デバイスの デバイス番号で置きかえられます. 一旦ソケットの設定が終了したら, スクリプト中で &man.pppctl.8; を 使用して, 動作中の ppp を操作することができるでしょう. システムの最終設定 これで ppp の設定は終りました. しかし ppp を動かす前に, まだ少し必要なことがあります. それらの設定は, すべて /etc/rc.conf ファイルを 編集することでおこないます. (このファイルは以前には /etc/sysconfig と呼ばれていました) このファイルを上から順に設定していきます. まずは hostname= の行が設定されていることを確認します. 例えば以下のように: hostname="foo.bar.com" もしプロバイダが静的な IP アドレスとホスト名を割り当てているのなら, ホスト名としてそれを使うのが おそらくベストでしょう. 次に network_interfaces 変数を調べます. 必要に応じて (on demand) プロバイダにダイアルするようにシステムを設定したい場合には, tun0 デバイスがこのリストに追加されていることを確認しておきます. それ以外の場合には, tun0 デバイスをリストから削除しておきます. network_interfaces="lo0 tun0" ifconfig_tun0= ifconfig_tun0 変数が空で, /etc/start_if.tun0 という名前の ファイルが作成されていなければなりません. このファイルの内容は以下のようになります. ppp -auto mysystem このスクリプトはネットワークの設定時に実行され, ppp デーモンを自動モードで立ち上げます. このマシンがもし LAN のゲートウェイであれば, スイッチも使用したいと思うかもしれません. 詳細に関しては, マニュアルページを参照してください. 以下のようにルータプログラムを NO に設定します. router_enable="NO" routed は, ppp が作成したデフォルトのルーティングテーブル エントリを削除してしまう場合がありますので, (初期設定では起動されるようになっている) routed デーモンが 起動されないようにしておくことが重要です. sendmail_flags 行が オプションを含まないように 設定しておいた方がよいでしょう. さもないと, sendmail が アドレスを調べようとして発信をおこなってしまう場合があります. 以下のような設定で良いでしょう: sendmail_flags="-bd" この結果, PPP リンクを立ち上げた時には いつでも以下のコマンドを実行して, キューにたまっているメールを sendmail に送信させる作業が必要になるでしょう. &prompt.root; /usr/sbin/sendmail -q ppp.linkup 中で !bg コマンドを使用することで, これを自動的に おこなうこともできます: 1 provider: 2 delete ALL 3 add 0 0 HISADDR 4 !bg sendmail -bd -q30m こうするのが嫌であれば, SMTP トラフィックをブロックするように dfilter を設定しておくこともできます. 詳細についてはサンプルファイルを参照してください. 後はマシンをリブートするだけです. リブートが終ったら, &prompt.root; ppp コマンドを実行し, 続いて PPP セッションを開始させるために dial provider と入力することもできますし, (start_if.tun0 スクリプトを作成していない場合に), 外部へのトラフィックが発生した時に, ppp が自動的に セッションを確立してくれるようにしたいのであれば, 以下のコマンドを実行することもできます. &prompt.root; ppp -auto provider まとめ 要約すると, 初めて ppp を設定する際には, 以下のステップが不可欠です: クライアント側: カーネルに tun デバイスが組み込まれていることを確認. /dev ディレクトリに tunX デバイスファイルが 存在することを確認. /etc/ppp/ppp.conf にエントリを作成. ほとんどのプロバイダでは, pmdemand の例で充分でしょう. 動的 IP アドレスを使用するなら, /etc/ppp/ppp.linkup に エントリを作成. /etc/rc.conf (または sysconfig) ファイルを更新. 必要に応じてダイヤル (demand dialing) したいのであれば, start_if.tun0 スクリプトを作成. サーバ側: カーネルに tun デバイスが組み込まれていることを確認. /dev ディレクトリに tunX デバイスファイルが 存在することを確認. (&man.vipw.8; コマンドを使って) /etc/passwd にエントリを作成. このユーザのホームディレクトリに ppp -direct direct-server か何かを実行するプロファイルを作成. /etc/ppp/ppp.conf にエントリを作成. direct-server の例で充分でしょう. /etc/ppp/ppp.linkup にエントリを作成. /etc/rc.confファイルを更新. カーネル PPP の利用 - 原作: &a.gena;, &a.rhuff;. + 原作: Gennady B. Sorokopud gena@NetVision.net.il, Robert Huff rhuff@cybercom.net. 訳: &a.jp.graphite;. 1996 年 9 月 6 日. カーネル PPP の設定 PPP の設定を始める前に, pppd が /usr/sbin にあり, また /etc/ppp という ディレクトリが存在することを確認してください. pppd はふたつのモードで動作します. クライアント モード. シリアル接続やモデムを利用して, そのマシンを 外部のネットワークに PPP 接続したい場合に用います. サーバ モード. そのマシンがネットワーク上にあるときに, PPP を使って ほかのコンピュータを接続する際に用います. どちらの場合でも, オプションファイルを設定する必要があります (/etc/ppp/options または, そのマシン上で PPP を使用する人が 複数いる場合には ~/.ppprc). また, ダイヤルとリモートホストへの接続をおこなうために, シリアル接続やモデムを 操作する, なんらかのソフトウェアが必要です (kermit が適しているでしょう). PPP クライアントとしての動作 わたしは, CISCO ターミナルサーバの PPP 回線に接続するために, 下記のような /etc/ppp/options を使用しています. crtscts # enable hardware flow control modem # modem control line noipdefault # remote PPP server must supply your IP address. # if the remote host doesn't send your IP during IPCP # negotiation , remove this option passive # wait for LCP packets domain ppp.foo.com # put your domain name here :<remote_ip> # put the IP of remote PPP host here # it will be used to route packets via PPP link # if you didn't specified the noipdefault option # change this line to <local_ip>:<remote_ip> defaultroute # put this if you want that PPP server will be your # default router 接続方法: kermit (またはその他のモデム操作プログラム) を使ってリモートホストに ダイヤルし, 接続してください. そして, あなたのユーザ名とパスワード (必要 であれば, その他にもリモートホストで PPP を有効にするための操作) を入力 します. kermit を抜けてください. (回線を切断せずに) 下記のように入力します: &prompt.root; /usr/src/usr.sbin/pppd.new/pppd /dev/tty01 19200 (通信速度とデバイス名には, あなたの環境に適したものを入れてください) これでこのコンピュータは PPP で接続されました. もし, なんらかの理由で 接続に失敗したならば, /etc/ppp/options ファイルに オプションを追加して, 問題点を突き止めるために, コンソールに表示される メッセージを調べてください. 下記の /etc/ppp/pppup スクリプトは, 上記の作業を すべて自動的におこないます: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.dial pppd /dev/tty01 19200 /etc/ppp/kermit.dial は kermit 用のスクリプトで, ダイヤルして, リモートホストでの認証に必要なすべての処理をおこないます. (そのようなスクリプトの例は この文書の終わりに添付してあります) PPP 接続を切断するには, 下記のような /etc/ppp/pppdown スクリプトを 使用します: #!/bin/sh pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ X${pid} != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill -TERM ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi /sbin/ifconfig ppp0 down /sbin/ifconfig ppp0 delete kermit -y /etc/ppp/kermit.hup /etc/ppp/ppptest PPP が動作中かどうかを調べます (/usr/etc/ppp/ppptest): #!/bin/sh pid=`ps ax| grep pppd |grep -v grep|awk '{print $1;}'` if [ X${pid} != "X" ] ; then echo 'pppd running: PID=' ${pid-NONE} else echo 'No pppd running.' fi set -x netstat -n -I ppp0 ifconfig ppp0 モデム回線を切断します (/etc/ppp/kermit.hup): set line /dev/tty01 ; put your modem device here set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 echo \13 exit 次は kermit の代わりに chat を使う方法です. - 原作: &a.rhuff;. + 原作: Robert Huff rhuff@cybercom.net. pppd 接続を確立するためには, 次の二つのファイルの設定だけで十分です. /etc/ppp/options: /dev/cuaa1 115200 crtscts # enable hardware flow control modem # modem control line connect "/usr/bin/chat -f /etc/ppp/login.chat.script" noipdefault # remote PPP serve must supply your IP address. # if the remote host doesn't send your IP during # IPCP negotiation, remove this option passive # wait for LCP packets domain <your.domain> # put your domain name here : # put the IP of remote PPP host here # it will be used to route packets via PPP link # if you didn't specified the noipdefault option # change this line to <local_ip>:<remote_ip> defaultroute # put this if you want that PPP server will be # your default router /etc/ppp/login.chat.script: (実際には一行になります.) ABORT BUSY ABORT 'NO CARRIER' "" AT OK ATDT<phone.number> CONNECT "" TIMEOUT 10 ogin:-\\r-ogin: <login-id> TIMEOUT 5 sword: <password> 正しくインストールし編集した後は, 必要な事はこれだけです &prompt.root; pppd このサンプルは主に Trev Roydhouse <Trev.Roydhouse@f401.n711.z3.fidonet.org> から寄せられた情報に基づいており, 承諾を得て使用しています. PPP サーバとしての動作 /etc/ppp/options: crtscts # Hardware flow control netmask 255.255.255.0 # netmask ( not required ) 192.114.208.20:192.114.208.165 # ip's of local and remote hosts # local ip must be different from one # you assigned to the ethernet ( or other ) # interface on your machine. # remote IP is ip address that will be # assigned to the remote machine domain ppp.foo.com # your domain passive # wait for LCP modem # modem line 下記のような /etc/ppp/pppserv スクリプトで, そのマシンを PPP サーバにすることができます. #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi # reset ppp interface ifconfig ppp0 down ifconfig ppp0 delete # enable autoanswer mode kermit -y /etc/ppp/kermit.ans # run ppp pppd /dev/tty01 19200 PPP サーバを終了するには, この /etc/ppp/pppservdown スクリプト を使用します: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.noans 下記の kermit スクリプトは, モデムの自動応答機能を有効, または無効にします (/etc/ppp/kermit.ans): set line /dev/tty01 set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 inp 5 OK echo \13 out ATS0=1\13 ; change this to out ATS0=0\13 if you want to disable ; autoanswer mod inp 5 OK echo \13 exit この /etc/ppp/kermit.dial スクリプトは, リモートホストに ダイヤルし, 認証手続きをするのに使用します. あなたは必要に応じて, これを 変更しないといけないでしょう. あなたのユーザ名とパスワードをこの スクリプトに書かなければいけませんし, モデムやリモートホストからの 応答によっては, 入力待ちの文を変更する必要もあります. ; ; put the com line attached to the modem here: ; set line /dev/tty01 ; ; put the modem speed here: ; set speed 19200 set file type binary ; full 8 bit file xfer set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none set modem hayes set dial hangup off set carrier auto ; Then SET CARRIER if necessary, set dial display on ; Then SET DIAL if necessary, set input echo on set input timeout proceed set input case ignore def \%x 0 ; login prompt counter goto slhup :slcmd ; put the modem in command mode echo Put the modem in command mode. clear ; Clear unread characters from input buffer pause 1 output +++ ; hayes escape sequence input 1 OK\13\10 ; wait for OK if success goto slhup output \13 pause 1 output at\13 input 1 OK\13\10 if fail goto slcmd ; if modem doesn't answer OK, try again :slhup ; hang up the phone clear ; Clear unread characters from input buffer pause 1 echo Hanging up the phone. output ath0\13 ; hayes command for on hook input 2 OK\13\10 if fail goto slcmd ; if no OK answer, put modem in command mode :sldial ; dial the number pause 1 echo Dialing. output atdt9,550311\13\10 ; put phone number here assign \%x 0 ; zero the time counter :look clear ; Clear unread characters from input buffer increment \%x ; Count the seconds input 1 {CONNECT } if success goto sllogin reinput 1 {NO CARRIER\13\10} if success goto sldial reinput 1 {NO DIALTONE\13\10} if success goto slnodial reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 60 goto look else goto slhup :sllogin ; login assign \%x 0 ; zero the time counter pause 1 echo Looking for login prompt. :slloop increment \%x ; Count the seconds clear ; Clear unread characters from input buffer output \13 ; ; put your expected login prompt here: ; input 1 {Username: } if success goto sluid reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 10 goto slloop ; try 10 times to get a login prompt else goto slhup ; hang up and start again if 10 failures :sluid ; ; put your userid here: ; output ppp-login\13 input 1 {Password: } ; ; put your password here: ; output ppp-password\13 input 1 {Entering SLIP mode.} echo quit :slnodial echo \7No dialtone. Check the telephone line!\7 exit 1 ; local variables: ; mode: csh ; comment-start: "; " ; comment-start-skip: "; " ; end: PPP オーバイーサネット (PPPoE) の利用 原作: &a.jim; ( node.to より) 10 Jan 2000. 以下の解説は, PPPoE として知られる, PPP オーバイーサネットの設定法です. 必要なもの あなたのシステムで PPPoE を適切に機能させるためには, 以下のものが必要です. FreeBSD 3.4やそれより新しいバージョンのカーネルソース FreeBSD 3.4やそれより新しいバージョンのppp カーネルコンフィギュレーション 以下に示すオプションをカーネルコンフィギュレーションファイルに 追加して, その後 新しいカーネルを コンパイルする必要があります. options NETGRAPH 以下は任意 options NETGRAPH_PPPOE options NETGRAPH_SOCKET この機能は実行時には有効ではありませんが, 要求に応じて ppp は関係のあるモジュールを 読み込みます. <filename>ppp.conf</filename> の設定 これは動作している ppp.conf の 例です: default: # or name_of_service_provider set device PPPoE:xl1 # replace xl1 with your ethernet device set mru 1492 set mtu 1492 set authname YOURLOGINNAME set authkey YOURPASSWORD set log Phase tun command # you can add more detailed logging if you wish set dial set login set ifaddr 10.0.0.1/0 10.0.0.2/0 add default HISADDR nat enable yes # if you want to enable nat for your local net papchap: set authname YOURLOGINNAME set authkey YOURPASSWORD オプションを付けてPPPoE を起動する際には注意するべきです. <application>PPP</application> の起動 以下を root 権限において実行することで, 起動させることができます.: &prompt.root; ppp -ddial name_of_service_provider システム起動時に <application>PPP</application> を立ち上げる /etc/rc.conf ファイルに以下の行を追加 してください: ppp_enable="YES" ppp_mode="ddial" ppp_nat="YES" ppp_profile="default" # or your provider SLIP の利用 原作: &a.asami;,&a.ghelmer;, 協力: &a.wilko;, &a.piero;. 訳: &a.hanai; 1996 年 8 月 8 日. SLIPクライアントのセットアップ ここには FreeBSD マシンを静的アドレスのネットワークにつなげる場合の SLIPのセットアップの一つの方法を書いてあります. ホスト名を動的に割り当てる(つまり, ダイヤルアップするたびにアドレスが かわる)ためには, おそらくもっと凝ったことが必要です. まず, モデムがどのシリアルポートにつながっているか決めましょう. 私は /dev/cuaa1 から /dev/modemへというシンボリックリンクを張り, コンフィグレーションではその名前だけを使っています. /etc や.kermrc など, システム全体に散らばっているファイルを修正する 必要がでるとまったく煩わしいのです! ここで, /dev/cuaa0は COM1であり, cuaa1はCOM2です. カーネルのコンフィグレーションファイルに pseudo-device sl 1 という記述があるのを確認してください. これは GENERIC カーネルに含まれている ので削除していない限り大丈夫でしょう. 最初の設定 /etc/hosts ファイルにあなたのマシンのゲートウェイとネームサーバ を加えてください. 私のは以下のようになっています. 127.0.0.1 localhost loghost 136.152.64.181 silvia.HIP.Berkeley.EDU silvia.HIP silvia 136.152.64.1 inr-3.Berkeley.EDU inr-3 slip-gateway 128.32.136.9 ns1.Berkeley.edu ns1 128.32.136.12 ns2.Berkeley.edu ns2 /etc/host.conf ファイル中で が よりも前にあること を確認してください. さもないとヘンなことが起こるかもしれません. /etc/rc.conf ファイルを編集してください. なお, お使いの FreeBSD が 2.2.2 よりも前のバージョンのものの場合は, /etc/sysconfig を編集してください. 行 hostname=myname.my.domain を編集してホスト名をセットしてください. 完全なInternetホスト名を与えるべきです. 行 network_interfaces="lo0" を network_interfaces="lo0 sl0" へ変更することにより ネットワークインタフェースのリストに sl0 を加えてください. 行 ifconfig_sl0="inet ${hostname} slip-gateway netmask 0xffffff00 up" を加えて sl0 のスタートアップフラグをセットしてください. 行 defaultrouter=NO を defaultrouter=slip-gateway へ変更してデフォルトのルータを 指定してください. 次の domain HIP.Berkeley.EDU nameserver 128.32.136.9 nameserver 128.32.136.12 という内容を含むファイル /etc/resolv.conf を作ってください. 見ればわかるように, これらはネームサーバホストを設定しています. もちろん, 実際のドメイン名やアドレスは あなたの環境に依存します. root と toor (及びパスワードを持っていない他のアカウントすべて) のパスワード を設定してください. passwdコマンドを使いましょう. /etc/passwd や /etc/master.passwd といったファイルを編集してはいけません! マシンを再起動して正しいホスト名で 立ち上がることを確認してください. SLIP接続をおこなう モデムを起動, つながったらプロンプトで slipとタイプし, マシン名と パスワードを入力してください. 入力する必要があるものは環境に よって異なります. 私は次のようなスクリプトでkermitを使っています. # kermit setup set modem hayes set line /dev/modem set speed 115200 set parity none set flow rts/cts set terminal bytesize 8 set file type binary # The next macro will dial up and login define slip dial 643-9600, input 10 =>, if failure stop, - output slip\x0d, input 10 Username:, if failure stop, - output silvia\x0d, input 10 Password:, if failure stop, - output ***\x0d, echo \x0aCONNECTED\x0a (もちろん, ホスト名とパスワードは変える必要があります). 接続するためには kermit のプロンプトで slipとタイプするだけです. ファイルシステムのどんなところにもプレインテキスト にパスワードを書いておくのは一般的にはよくありません. 覚悟の上で やってください. 私は単に不精なだけです. ここでkermitから抜け出し (zでkermitをサスペンドできます), root で &prompt.root; slattach -h -c -s 115200 /dev/modem と入力しましょう. もしルータの向う側のホストへ ping できるなら接続成功です! もしうまく いかなければslattachへの引数として の代わりにとやってみてください. 接続の切り方 slattachを殺すためにrootで &prompt.root; kill -INT `cat /var/run/slattach.modem.pid` とタイプしてください. そして kermit に戻り (もしkermitをサスペンドしていたなら fg), kermitから抜けてください (q). slattachのマニュアルページにはインタフェースを落すために ifconfig sl0 downをしなければいけないと書いていますが, 私には差がないように見えます. (ifconfig sl0とやっても同じ結果が得られる.) 時にはモデムがキャリアを落すのを 拒絶するかもしれません(私のは よくそうなります). その時は単にkermitをスタートしてまた終了 してください. 普通は2回目で落ちます. トラブルシューティング もし動かなければ自由に私に質問してください. 今までいろんな人がつまずいた のは次のようなことです. slattach で や を使わなかった(私はなぜこれが致命的になり得るのか わかりませんが, このフラグを付けることで少なくとも一人の 問題は解決しました.) の代わりに を使った(いくつかのフォントでは見分けるのは難しい かもしれません). インタフェースの状態を見るために ifconfig sl0 をやってみてください. 私は, &prompt.root; ifconfig sl0 sl0: flags=10<POINTOPOINT> inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00 となります. また, pingが no route to host というメッセージを返す時には netstat -rでルーティングテーブルを確認しましょう. 私のは, &prompt.root; netstat -r Routing tables Destination Gateway Flags Refs Use IfaceMTU Rtt Netmasks: (root node) (root node) Route Tree for Protocol Family inet: (root node) => default inr-3.Berkeley.EDU UG 8 224515 sl0 - - localhost.Berkel localhost.Berkeley UH 5 42127 lo0 - 0.438 inr-3.Berkeley.E silvia.HIP.Berkele UH 1 0 sl0 - - silvia.HIP.Berke localhost.Berkeley UGH 34 47641234 lo0 - 0.438 (root node) となります. (これはたくさんのファイルを転送した後でのもので, あなたの見る数字はもっと小さいかも しれません). SLIPサーバのセットアップ方法 訳: &a.jp.ts;. 1996 年 9 月 6 日. この文書の目的は, SLIPサーバ機能を FreeBSDシステムのもとで設定するため の助言を提供することです. SLIPサーバ機能を設定するということは, リモー トの SLIPクライアントがログインできるようにするために, 自動的に接続処 理をおこなうようにすることです. この文書は著者の経験に基づいておりますが, 実際のシステム構成や要望は異なりますから, すべての疑問にこの文書が答え ることはできません. なお, ここでの助言を試みた結果, あなたのシステムへ の悪影響やデータの損失が生じたとしても, 著者が責任を持つことはできませ んのでご了解をお願いします. 前提 この文書の内容はテクニカルなものなので, 前提知識が必要です. すなわち, TCP/IPネットワークプロトコルについての知識, 特に, ネットワークとノード のアドレス指定をはじめ, ネットワークアドレスマスク, サブネット化, ルー ティング, および RIPなどのルーティングプロトコルなどに関する知識を前提 としています. ダイヤルアップサーバで SLIP機能を設定するためには, これ らの概念についての知識が必要ですから, もし不案内であると思われる方は, O'Reilly & Associates, Inc.から出版されている Craig Hunt氏の TCP/IP Network Administration (ISBN 0-937175-82-X)か, または Douglas Comer氏の TCP/IPプロトコルに関する一連の書籍をお読みください. 前提知識に加え, さらに, モデムの設定が完了しており, そのモデムを経由し てログインできるように, システムファイル群が適切に記述できているものと 仮定しています. もしモデムの準備ができていないときには, あらかじめダイヤ ルアップ機能の設定についてのチュートリアルをお読みください. Webブラ ウザが使えるのであれば http://www.FreeBSD.org/ におけるチュー トリアルの一覧を調べてください. あるいは, この文書を見つけた場所を調べ て, dialup.txt やそれに類似した名前の文書をお読みください. 関連す るマニュアルページとしては, シリアルポート向けデバイスドライバについて の &man.sio.4; をはじめ, モデムからのログインを 受理できるようにシステ ムを設定するための &man.ttys.5;, &man.gettytab.5;, &man.getty.8;, &man.init.8; など, さらには, シリアルポート関連パラメタ ( たと えば直接接続シリアルインタフェースの clocal ) についての &man.stty.1; なども助けになるかもしれません. 概要 一般的な設定内容で FreeBSDを SLIPサーバとして利用すると, その動作は次 のようになります. まず, SLIPユーザが FreeBSD による SLIPサーバへ電話し て, SLIP専用IDでログインします. なお, このIDを持ったユーザはシェルとし て /usr/sbin/sliplogin を使います. この sliplogin は, ファイル /etc/sliphome/slip.hosts の中から, ログインIDと一致する 記述行を探します. もし一致する行があれば, ログインしたシリアル回線を, 利用可能な SLIPインタフェースへ接続し, その後にシェルスクリプト /etc/sliphome/slip.login で SLIPインタフェースを設定します. SLIPサーバへのログイン例 仮に SLIPユーザIDが Shelmerg とします. すると, /etc/master.passwd における Shelmerg のエントリは次のよ うなものになります (実際には一つの行に続いている) . Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP:/usr/users/Shelmerg:/usr/sbin/sliplogin Shelmerg がログインすると, sliplogin は, ファイル /etc/sliphome/slip.hosts からユーザIDと一致する行を探しま す. いま仮に, /etc/sliphome/slip.hosts に次のような記述がなされていたとします. Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp sliplogin が上記のエントリを見つけると, Shelmerg が使用して いるシリアル回線を, 利用可能な SLIPインタフェースのなかの最初のものへ 接続し, 次の内容の /etc/sliphome/slip.login を実行します. /etc/sliphome/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp もし上記の手順が正常に処理されると, /etc/sliphome/slip.login は, sliplogin が割り当てた SLIPインタフェース (この例では slip.login で与えられたパラメタのうちで最初の値である SLIP インタフェース0である) に対して ifconfig を実行し, ローカル IPアドレス (dc-slip)をはじめ, リモート IPアドレス (sl-helmer), SLIPインタフェースへのネットワークマスク (0xfffffc00), およびその他のフラグ (autocomp)を設定 します. 逆に, さきほどの手順が正常に終了しなかった場合, 通常は sliplogin は十分な情報を syslog の daemon 機能経由で /var/log/messages へ記録します ( &man.syslogd.8; や &man.syslog.conf.5; のマニュアルページを参照のうえ, さらに /etc/syslog.conf を調べて syslogd がどのファイルへ記 録するかを確認のこと) . 例はこのくらいにして, さっそくシステムのセットアップを始めてみましょう. カーネルのコンフィグレーション FreeBSD のデフォルトのカーネルには, 通常, 二つの SLIPインタフェースが 準備されています (sl0 と sl1) . これらのインタフェー スが使用中のカーネルに準備されているかどうかを調べるには, netstat -i を実行してください. netstat -i の出力例 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ed0 1500 <Link>0.0.c0.2c.5f.4a 291311 0 174209 0 133 ed0 1500 138.247.224 ivory 291311 0 174209 0 133 lo0 65535 <Link> 79 0 79 0 0 lo0 65535 loop localhost 79 0 79 0 0 sl0* 296 <Link> 0 0 0 0 0 sl1* 296 <Link> 0 0 0 0 0 netstat -i の出力に sl0 と sl1 のインタフェー スが含まれているということから, カーネルには二つの SLIPインタフェー スが組み込まれているということを示しています. (sl0 と sl1 に付いたアスタリスクは, netstat -i の実行時点で はインタフェースが ダウン していることを表しています. ) なお, パケットのフォワード機能は FreeBSD のデフォルトのカーネルでは設定 されていません (すなわちルータとしては動作しない) . もしインターネット 接続ホストについての RFC要件 ( RFC 1009 [Requirements for Internet Gateways] と 1122 [Requirements for Internet Hosts — Communication Layers], おそらく 1127 [A Perspective on the Host Requirements RFCs] も ) に準拠して, FreeBSDによる SLIPサー バをルータとして動作させたいときには, /etc/rc.conf (バージョ ン 2.2.2 より前の FreeBSD では /etc/sysconfig) ファイル の gateway_enable 変数を としてください. もし古いシステ ムで /etc/sysconfig ファイルすらないときには, 次のコマン ドを /etc/rc.local へ追加してください. sysctl -w net.inet.ip.forwarding = 1 この新しい設定を有効とするには, リブートする必要があります. デフォルトのカーネルコンフィグレーションファイル (/sys/i386/conf/GENERIC) の最後の部分に, 次のような行がありま す. pseudo-device sl 2 この行によって, 使用可能な SLIPデバイスの総数が決まります. すなわち, 行 末の数値が, 同時に動作可能な SLIP接続の最大数となります. カーネルの再構築については, FreeBSDカー ネルのコンフィグレーション を参照ください. Sliploginのコンフィグレーション すでにご説明したように, /usr/sbin/sliplogin のコンフィグレー ションのために, 3種類のファイルが/etc/sliphome ディレクトリに あります (sliplogin についての実際のマニュアルページとしては &man.sliplogin.8; を参照のこと) . ファイル slip.hosts は SLIPユーザおよびその IPアドレスを決めます. 通常, ファイル slip.login は, SLIPインタフェースを設定することだけに使 用します. slip.logout はオプションのファイルで, slip.login で設定した内容を, シリアル接続が終了した時点で解除 するときに使用します. <filename>slip.hosts</filename> のコンフィグレーション /etc/sliphome/slip.hosts には, 少なくとも 4 つの項目をホワイ トスペース (スペースやタブ) で区切って指定します. SLIPユーザのログインID SLIPリンクのローカル (SLIPサーバ側) アドレス SLIPリンクのリモートアドレス ネットワークマスク ホスト名をローカルおよびリモートのアドレスとして 記述できます (IPアドレ スの決定は, /etc/host.conf の指定内容に応じて, /etc/hosts か DNSのいずれかによって決定される) . また, ネット ワークマスクも /etc/networks ファイルに記述された名前を参照す ることで, 指定することもできると思います. これまでの例としてあげたシス テムでの /etc/sliphome/slip.hosts は次のようになります. # # login local-addr remote-addr mask opt1 opt2 # (normal,compress,noicmp) # Shelmerg dc-slip sl-helmerg 0xfffffc00 autocomp それぞれの行の最後には, 次に示すオプションを一つ以上指定できます. — ヘッダを圧縮しない — ヘッダを圧縮する — リモートの設定に応じて, ヘッダを圧縮する — ICMPパケットを禁止する ( ping パケットは送出されず, バンド幅を占有しない) なお, FreeBSDバージョン2の初期リリースの sliplogin は, 旧 FreeBSD 1.xでは有効であった上記のオプションを無視していましたので, , , , そして などのオプションは FreeBSD 2.2でサポートされるまでは効果がありませんでした (た だしこれらのフラグを使うためには slip.login スクリプトへ記述する 必要がある) . SLIPリンクでのローカルとリモート向けのアドレスの 選び方は, TCP/IPサブネッ トを専用に割り当てるか, または プロキシ ARP を SLIPサーバへ用いるかによって違います ( プロキシ ARP という用語のここでの使い方は本来のものではないが, 説明のためにこの用語を使う) . もし, どちらの方式を選ぶべきか判らなかったり, IPアドレスの割り当て方が不明のときには, 上述の 前提 の節で紹介した TCP/IP関連書籍を参考になさるか, またはあなたの IPネットワークを管理している方に相談なさると よいでしょう. 独立したサブネットを SLIPクライアントへ適用するときには, すでに割り当てられている IPネットワーク番号の範囲からサブネット番号を割り当て, 同 時にそのサブネットの範囲内で有効な IPアドレスを SLIPクライアントの IP 番号として割り当てる必要があります. さらに, この SLIPサブネットから SLIPサーバを経由して最も近い IPルータへの経路を静的に設定するか, または gated を FreeBSDによる SLIPサーバへインストールして, 適当 なルーティングプロトコルを使って, SLIPサーバ経由のサブネットへの経路情 報をルータ群へ通知できるように設定するか, のいずれかをおこなう必要があります. プロキシ ARP 方式を採用するときには, SLIPクライアント向けの IPアドレス として, SLIPサーバのサブネットの範囲から 選んで割り当てるとともに, &man.arp.8; コマンドを使うために /etc/sliphome/slip.login と/etc/sliphome/slip.logout のスクリプトを修正して, SLIPサー バにおける ARPテーブル内のプロキシ ARPエントリへ 反映させる必要がありま す. <filename>slip.login</filename> のコンフィグレーション ファイル /etc/sliphome/slip.login の一般的な内容は次にようになります. #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 この slip.login ファイルの役目は単に, SLIPインタフェースにつ いてのローカルとリモートのアドレス, およびそのネットワークマスクを ifconfig コマンドで設定することです. もし プロキシ ARP 方式を採用する (SLIPクライアントへ独立したサブネットを使わない) ときには, ファイル /etc/sliphome/slip.login は次のような内容になります. #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 # Answer ARP requests for the SLIP client with our Ethernet addr /usr/sbin/arp -s $5 00:11:22:33:44:55 pub この slip.login で追加された行 arp -s $5 00:11:22:33:44:55 pub は, SLIPサーバにおける ARPテーブルへ新たなエントリを作ります. SLIPサーバ は, この ARPエントリが作られると, SLIPクライアントの IPアドレスと話し たい他の IPノードが要求してきたときにはいつも, SLIPサーバ の Ethernet MACアドレスを返すようになります. 上記の例を実際に流用なさるときには, 例にある Ethernet MACアドレス (00:11:22:33:44:55) を, あなたのシステムの実際のEthernetカー ドの MACアドレスと置き換えなければ プロキシ ARP はうまく動作しません! SLIPサーバの Ethernet MACアドレスを調べるには netstat -i コマ ンドを利用してください. 実行結果の第2行は次のようなものになるはずです. ed0 1500 <Link>0.2.c1.28.5f.4a 191923 0 129457 0 116 この例での Ethernet MACアドレスは 00:02:c1:28:5f:4a であると 読みます. なお &man.arp.8; における MAC アドレスの指定に際しては, コマンド netstat -i が付けた Ethernet MACアドレスのピリオド記 号をコロン記号と置き換え, かつ単一桁の 16 進数にはゼロを先頭に加える必 要があります. この指定についての正確な情報は &man.arp.8; を参照く ださい. /etc/sliphome/slip.login と /etc/sliphome/slip.logout を作成したならば, ファイル属性の 実行 ビット (すなわち chmod 755 /etc/sliphome/slip.login /etc/sliphome/slip.logout) を 設定しなければなりません. さもなければ sliplogin が うまく実行されません. <filename>slip.logout</filename> のコンフィグレーション ファイル /etc/sliphome/slip.logout は必ずしも必要なものではあ りません (ただし プロキシ ARP を利用する場合を除く) . もしこのファイルを 作成するときには, 次に示す標準的な slip.logout スクリプト例を 参考にしてください. #!/bin/sh - # # slip.logout # # logout file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 down プロキシ ARP を利用する場合, この /etc/sliphome/slip.logout を 使って, 特定の SLIPクライアント向けの ARPエントリを削除したくなるようなときがあります. #!/bin/sh - # # @(#)slip.logout # # logout file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 down # Quit answering ARP requests for the SLIP client /usr/sbin/arp -d $5 コマンド arp -d $5 は, SLIPクライアントがログインした 際に, プロキシ ARP を使った slip.login によって追加され た ARPエントリを削除します. これによって, 繰り返して利用することができるわけです. 必ず, /etc/sliphome/slip.logout を作成した後に, 実行ビットを設定し てください ( chmod 755 /etc/sliphome/slip.logout ) . ルーティングについての考慮点 プロキシ ARP 方式を利用せずに SLIPクライアントとその他のネットワーク (Internetも含む) の構成要素との間でパケットをルーティングするときには, SLIPサーバ経由で SLIPクライアントが属するサブネットまでの経路を, 最も 近いデフォルトのルータ群へ静的な経路情報として 追加しなければならないか, または gated を FreeBSDによる SLIPサーバへインストールして, SLIP サブネットについての経路情報を, 適当なルーティングプロトコルでルー タ群へ通知できるように設定するか, のどちらかをおこなわなければなりません. 静的な経路 静的な経路を最も近いデフォルトの ルータ群へ追加することが困難なことがあ ります (経路情報を追加できる権限がなければそもそも不可能となる). もし あなたの組織に複数のルータで構成された ネットワークがあるならば, ある種 のルータ (たとえば Ciscoや Proteonなど) は, 静的な経路を SLIPサブネッ トへ使うようにルータを設定しなければならないだけでなく, その静的経路を 他のどのルータへ知らせるのかもあらかじめ 指定しておく必要がありますから, 静的経路に基づくルーティングを軌道に乗せるには それなりの専門的技術やト ラブルシューティングやコツが必要だと思います. <command>gated</command>の稼働 静的経路についての頭痛への代替手段は, gated を FreeBSDによる SLIPサー バへインストールして, 適切なルーティングプロトコル (RIP/OSPF/BGP/EGP) を使って SLIPサブネットについての経路情報を他のルータへ知らせるように 設定することです. ports コレクションから gated を用いることもできますし, the GateD 匿名 FTP サイト から探して自分自身で構築することもで きます. この文章を執筆時点の最新バージョンは gated-R3_5Alpha_8.tar.Z であり, このファイル だけで FreeBSDで 動作させることができます. gated についてのすべての情報と文書 は Merit GateD コンソーシアム からはじまる Web 上で入手でき ます. gated のコンパイルとインストールを行ったならば, 独自の 設定のために /etc/gated.conf ファイルを記述してください. 次の 例は, 筆者が FreeBSDによる SLIP サーバで使っている内容と類似のものです. # # gated configuration file for dc.dsu.edu; for gated version 3.5alpha5 # Only broadcast RIP information for xxx.xxx.yy out the ed Ethernet interface # # # tracing options # traceoptions "/var/tmp/gated.output" replace size 100k files 2 general ; rip yes { interface sl noripout noripin ; interface ed ripin ripout version 1 ; traceoptions route ; } ; # # Turn on a bunch of tracing info for the interface to the kernel: kernel { traceoptions remnants request routes info interface ; } ; # # Propagate the route to xxx.xxx.yy out the Ethernet interface via RIP # export proto rip interface ed { proto direct { xxx.xxx.yy mask 255.255.252.0 metric 1; # SLIP connections } ; } ; # # Accept routes from RIP via ed Ethernet interfaces import proto rip interface ed { all ; } ; この gated.conf ファイルの例では, SLIPのサブネット xxx.xxx.yy についての経路情報を RIPを使って Ethernetへブロー ドキャストしています. もし ed ドライバ以外の Ethernetドライバを使うのであれば, ed インタフェースの記述を適切なものに置き換えてくだ さい. またこの例では, gatedの動作をデバッグするために, /var/tmp/gated.output へトレース情報を出力するように指示して います. gated が希望通りに動作したならば, このトレースオプショ ンを止めることができます. なお, 例における xxx.xxx.yy を, あ なた自身の SLIPサブネットのネットワークアドレスに換えてください (また proto direct 部分のネットワークマスクも換えることを忘れないこ と) . gated のコンパイルとインストールが終了し, コンフィグレーショ ンファイルの作成も完了したら, FreeBSDシステムではデフォルトの routedに代わって gated を起動してください. そのため には, /etc/netstart の routed/gated 起動パラメタを 適切な値に設定してください. gated のコマンドラインパラメタにつ いての情報は, gated のマニュアルページを参照してください. diff --git a/ja_JP.eucJP/books/handbook/printing/chapter.sgml b/ja_JP.eucJP/books/handbook/printing/chapter.sgml index 7528eb2f51..e482297911 100644 --- a/ja_JP.eucJP/books/handbook/printing/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/printing/chapter.sgml @@ -1,5315 +1,5315 @@ プリンタの利用 - 原作: &a.kelly;, 1995 年 9 月 30 日. + 原作: Sean Kelly kelly@ad1440.net, 1995 年 9 月 30 日. 改訂: &a.jim;, 2000 年 3 月 訳: &a.jp.kimura;, 1996 年 9 月 3 日 この章では LPD スプーリングシステム 印刷 FreeBSD でプリンタを使用するためには, バークレーラインプリンタスプーリングシステム (LPD スプーリングシステムとしても知られています) が機能するようにプリンタをセットアップする必要があります. 本章では設定例を通して, LPD スプーリングシステム (大抵の場合, 単に LPD と呼ばれる) について紹介します. もし, LPD や他のプリンタスプーリングシステムについてすでに詳しい知識をお持ちの方は, スプーリングシステムのセットアップから読み始めても構いません. はじめに LPD はあるホストのプリンタに関する制御の一切を行ないます. ここで言う制御としては, 次のことがあげられます. ホストに接続されたプリンタ, あるいはネットワーク上の他ホストに接続されたプリンタに対するアクセス制御を行ないます. プリントジョブ ファイルをプリントする要求に対して許可を与えます. この要求は特にジョブと呼ばれています. 各々のプリンタのキューを管理することにより, 複数のユーザがあるプリンタに対して同時にアクセスすることを防ぎます. ヘッダページ (バナーまたは バーストページとしても知られています) をプリントすることができます. これにより, プリントアウトの山の中から自分がプリントしたジョブを見つけやすくなります. シリアルポートに接続したプリンタ用に通信パラメータを管理します. ネットワーク経由で他のホスト上の LPD スプーラにジョブを送ることができます. 様々なプリンタ言語やプリンタの能力に応じてジョブの形式を整えるため, 特別なフィルタを起動することができます. プリンタの使用に対して課金を行なうことができます. 設定ファイルを通して, あるいは特別なフィルタプログラムを用いることにより, 多種多様なプリンタ機器に対して, 上述の機能の全部または一部を LPD システムに行なわせることができます. どうしてスプーラを使うべきなのか あなたのシステムを利用するのがあなた一人だけだとしたら, アクセス制御もヘッダページも プリンタ利用に対する課金も必要ないのに, なぜわざわざスプーラに煩わされなければならないのか疑問に思うかも知れません. プリンタに対する直接アクセスを許可することもできるのですが, とにかくスプーラを使用するべきです. その理由は, LPD はジョブをバックグラウンドで処理します. データがプリンタに送信されるまで待つ必要がなくなります. TeX LPD ではジョブをフィルタを通してプリントすることが簡単にできます. これにより, 印刷物のヘッダに時刻や日付を入れたり, 特別なファイル形式 (TeX の DVI ファイルなど) をプリンタが処理できる形式に変更することができ, これらの作業を手動で行なう必要がなくなります. プリント処理を行なうフリー, または商用のプログラムのほとんどは, システムのスプーラとやりとりするように作られています. スプーリングシステムをセットアップすることで, 今後加えるかもしれない, あるいは, すでに持っている別のソフトウェアをより簡単にサポートすることができるでしょう. 基本的なセットアップ LPD スプーリングシステムを用いてプリンタを使用するためには, プリンタ機器と LPD 用ソフトウェアの両方を準備する必要があります. 本文書では次の二段階のレベルに分けて説明をします. プリンタを接続する方法, プリンタにどのように通信するかを LPD に指示する方法や, プレインテキストをプリンタで印字する方法については, プリンタの簡単な設定をご覧ください. 様々な形式のファイルを印字する方法, ヘッダページを印字する方法, ネットワーク経由でプリンタに印字する方法, プリンタを制御する方法, プリンタの使用に対する課金を行なう方法についてはプリンタ設定 上級編をご覧ください. プリンタ設定導入編 この節では, プリンタ機器やプリンタを使用するための LPD 用ソフトウェアを設定する方法について述べます. この節の概要は次のとおりです. プリンタ機器の設定では, プリンタをコンピュータに接続するためのヒントがいくつか書かれています. ソフトウェアの設定では, LPDのスプーラ設定ファイル /etc/printcap の設定方法について書かれています. データをプリンタに送るためにシリアルまたはパラレルインタフェースではなく, ネットワークプロトコルを使用する場合は, ネットワークにおけるデータストリームインタフェースを持つプリンタをご覧ください. この節のタイトルはプリンタ設定導入編ですが, 実際の設定はかなり複雑です. プリンタをコンピュータに接続し, LPD スプーラを起動させることは一番困難な作業です. ヘッダページを出力させたり課金したりするオプションの設定は, 一度プリンタがうまく動くようになればとても簡単です. プリンタ機器の設定 この節では, プリンタに PC を接続するための様々な方法について説明しています. ここでは, ポートやケーブルの種類, FreeBSD がプリンタとの通信に必要なカーネルコンフィグレーションについても言及しています. もしプリンタが既に接続されていて, 他のオペレーティングシステム上でプリンタからの印字に成功している場合は, ソフトウェアの設定まで読み飛ばすことが多分できるでしょう. ポートとケーブル 最近の PC 用のプリンタほとんどには次のインタフェースの一つもしくは両方がついています. プリンタ シリアル シリアルインタフェースでは, プリンタにデータを送信するためにコンピュータにあるシリアルポートが使用されます. シリアルインタフェースはコンピュータ業界で共通して使用されています. そのケーブルは容易に手に入りますし, 簡単に自作することもできます. シリアルインタフェースの場合は時々, 特別なケーブルや何か複雑な通信方式選択の設定が必要になることがあります. プリンタ パラレル パラレルインタフェースではプリンタにデータを送信するために, コンピュータにあるパラレルポートを使用します. パラレルインタフェースは PC 業界では良く使われます. ケーブルの入手は容易ですが, 自作するのはシリアルよりも困難です. パラレルインタフェースには通常, 通信方式の選択はなく, 設定は極めて単純です. セントロニクス パラレルプリンタ パラレルインタフェースはセントロニクスインタフェースとして知られています. これは, プリンタ用のコネクタタイプとして採用された後に名付けられました. シリアルインタフェースはパラレルインタフェースよりも普通はデータの伝送速度が遅くなります. パラレルインタフェースでは, 通常, (コンピュータからプリンタへの) 単方向通信のみを行なうのに対して, シリアルインタフェースは双方向通信を行ないます. FreeBSD でも IEEE1284 準拠のケーブルを使えば, 最近のパラレルポートとプリンタの多くで双方向通信を行なうことができます. PostScript 通常, プリンタで双方向通信が必要となるのは, プリンタが PostScript 言語に対応しているときだけです. PostScript プリンタは非常に冗長に動作させることができます. 事実, PostScript によるジョブでは, プログラムを本当にプリンタに送信します. このことは, 印字作業を必ずしもする必要がないことを意味しますし, そのプログラムの結果はコンピュータに直接返されるかも知れません. PostScript プリンタでは双方向通信を使って PostScript プログラムのエラーや紙づまりといった問題をコンピュータに報告します. ユーザはそれらの情報を知りたいと思うかも知れません. また, PostScript プリンタで課金作業をもっとも効率よく行なうためには, 双方向通信が必要となります. この方法ではまず, プリンタの現在のページカウント (起動してから今まで何枚の紙を印字したか) の情報を得ます. 次に, ユーザのジョブを実行し, 終了後, 再びページカウントを得ます. この二つの数を差によって, 課金対象となる紙の枚数を知ることができるのです. パラレルポート プリンタをパラレルインタフェースを使って接続する場合は, セントロニクスケーブルでプリンタとコンピュータを接続してください. 詳しい説明はプリンタやコンピュータに付属する説明書に書かれているはずです. その際, どのパラレルポートを使用したかを覚えておいてください. FreeBSDでは最初のポートは /dev/lpt0, 二番目 /dev/lpt1 であ り, 三番目以降も同様に続きます. シリアルポート シリアルインタフェースを使ってプリンタを使う場合は, 適切なシリアルケーブルでプリンタとコンピュータを接続してください. 詳しい説明はプリンタ, コンピュータ, あるいは両方に付属する説 明書に書かれているはずです. 適切なシリアルケーブルが良くわからないときは, 次のどれかを試してみてください. モデム用ケーブルでは, それぞれのピンは他方のコネクタの対応するピンと線でつながっています. このタイプのケーブルは DTE-DCE 間ケーブルとしても知られています (訳注: 日本ではストレートケーブルという名前で売られています). ヌルモデム用ケーブル ヌルモデム用ケーブルでは, あるピンは対応するピンとを接続していますが, あるピン (たとえば, データ送信用とデータ受信用のピン) が交差して接続したり, いくつかのピンは内部で短絡していたりします. このタイプのケーブルは, DTE-DTE 間ケーブルと呼ばれています (訳注: 日本ではクロスケーブルという名前で売られています). A シリアルプリンタ用ケーブルは, ある特定のプリンタで必要とされるものです. ヌルモデムケーブルと似ていますが, 内部で短絡させる代わりに, ある信号を他方側に送るために使用しています. ボーレート パリティ フローコントロールプロトコル この他に, プリンタ用の通信パラメータを設定する必要があります. 通常, プリンタのフロントパネルや DIP スイッチによって制御します. コンピュータとプリンタの双方で設定できる最高の通信速度 [bps] (ビット/秒. ボーレートと示されているときもある) を選んでください. そして, データビット (7 または 8), パリティ(偶/奇/なし), ストップビット (1 または 2) を選んでください. そして, フローコントロールの有無 (制御なし, または XON/XOFF (イン・バンド または ソフトウェアフローコントロールとも呼ばれる)) を選びます. 以下に続くソフトウェアの設定のために, ここでの設定を覚えておいてください. ソフトウェアの設定 本節では FreeBSD の LPD スプーリングシステムで印字をおこなうために 必要となるソフトウェアの設定について説明しています. 本節の概要は次のようになります. プリンタで使用するポートのために, 必要があれば, カーネルの書き変えをおこないます. 「カーネルの変更」で, このためにしなくてはならないことを説明しています. パラレルポートを使用している場合は, パラレルポートのための通信モードの設定します. 詳細は, 「 パラレルポートの通信モードを設定する 」で説明しています. オペレーティングシステムからプリンタにデータが送ら れているかをテストします. 「 プリンタとの通信状況を調べる」で, どのようにテストするかの提案をいくつかおこなっています. ファイル/etc/printcapを変更し, LPDの設定を おこないます. この節で, どのように変更するかを 説明しています. カーネルの変更 オペレーティングシステムのカーネルの コンパイルをおこなうことによって, 指定されたのデバイスが機能するようになります. シリアル, または, パラレルインタフェースをプリンタで使用する場合, 必要なデバイスがこの指定の中に含まれていなくてはなりません. したがって, 必要なデバイスがカーネルに組み込まれていない場合, 追加のシリアル, または, パラレルポートをサポートするために, カーネルの再コンパイルが必要となるかもしれません. シリアルポートが現在使用しているカーネルで サポートされているかどうかを調べるためには, 次のように入力します. &prompt.root; dmesg | grep sioN ここで, N はシリアルポートの番号を示し, この番号は0から 始まります. 次のような出力があった場合, カーネルはそのポートをサポートしています. sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A パラレルポートが現在使用しているカーネルで サポートされているかどうかを調べるためには, 次のように入力します. &prompt.root; dmesg | grep lptN ここで, N はパラレルポートの番号を示し, この番号は 0 から始まります. 次のような出力があった場合, カーネルはそのポートをサポートしています. lpt0 at 0x378-0x37f on isa 上記の出力が得られない場合, プリンタを使うため, オペレーティングシステムにパラレル, または, シリアルポートを認識し, 使用できるようにするためには カーネルを変更する必要があります. シリアルポートをサポートさせるには, 「 FreeBSDカーネルのコンフィグレーション」の節をご覧く ださい. パラレルポートをサポートさせる場合も, その節と, あわせて, この節に続く節もご覧ください. ポート用エントリを <filename>/dev</filename> に追加する カーネルがシリアル, または, パラレルポートを通じての通 信をサポートしていたとしても, システム上で動いているプログ ラムがデータの送受信をおこなうための ソフトウェアインタフェースがさらに必要になります. そのインタフェースは, /dev ディレクトリにあるエントリに相当します. /dev エントリにポートを加えるために &man.su.1; コマンドで root になります. suコマンド でパスワードを聞かれたら, ルート用のパスワードを入力し ます. /dev ディレクトリに移動します. &prompt.root; cd /dev 次のように入力します. &prompt.root; ./MAKEDEV port ここで, port は, 作成するポート名です. 1番目 のパラレルポートのときは lpt0 に, 2番目のときは lpt1 になり, 以降同様になります. 1番目のシリア ルポートのときは, ttyd0 に, 2番目のときは ttyd1 になり, これも以降同様となります. 次を入力し, デバイスのエントリができたか確認します. &prompt.root; ls -l port パラレルポートの通信モードを設定する パラレルインタフェースを使用している場合, FreeBSDでは, 割り込み駆動型にするか, プリンタとの通信の状況をカーネルに監 視させるかのいずれかを選択できます. GENERIC カーネルでは割り込み駆動方式が, デフォルトになっています. この方式では, オペレーティングシ ステムはプリンタがデータを受け付けられるかどうかを調べ るために, IRQ ラインを一つ使用します. 監視方式では, オペレーティングシステムにプ リンタがもっとデータを受け付けられるかどうかを繰り返し 尋ねるように指示します. そして, 受け付けるという応答を 受けたとき, カーネルはさらなるデータを送信します. 割り込み駆動方式は, いくらか高速になりますが, 貴重な IRQ ラインを一つ消費します. うまく機能するものをお使いください. 通信モードを設定するためには2つの方法があります. 1つはカー ネルを変更することで, もう一つは &man.lptcontrol.8; プログラムを使用する方法です. カーネルを設定することによって, 通信モードを変更する. カーネルコンフィグレーションファイルを変更します. lpt0 のエントリを探すか追加してください. 2番目 のパラレルポートを設定するときは, 代わりに lpt1 を使います. 以下, 3番目のポートは lpt2 となってい きます. イベント駆動方式にする場合は, irq 指定を追加します. device lpt0 at isa? port? tty irq N vector lptintr ここで, N はパラレルポート用の IRQ 番号です. 監視方式を使用する場合は, irq を追加してはいけません. device lpt0 at isa? port? tty vector lptintr ファイルをセーブし, config プログラムを起動し, カーネルの構築, インストールをおこないます. そして, リブートしてください. 詳細は, 「 FreeBSDカーネルのコンフィグレーション」を参照 してください. &man.lptcontrol.8; で通信モードを設定する場合 lptN をイベント駆動方式に設定する場合は, 次のように入力します. &prompt.root; lptcontrol -i -u N lptN を監視方式に設定する場合は, 次のように入力します. &prompt.root; lptcontrol -p -u N これらのコマンドを /etc/rc.local ファイルに追加 しておくと, システムをブートする度に通信モードを設定する ことができます. 詳細については, &man.lptcontrol.8; をご覧ください. プリンタとの通信状況を調べる スプーリングシステムの設定に進む前に, オペレーティング システムがプリンタにデータを送ることに成功しているかどうか を確かめるべきでしょう. これにより, 印字がうまくいかないと き, プリンタとの通信が問題なのか, スプーリングシステムが問 題なのかを分けて調べることがかなり容易になります. プリンタをテストするためには, プリンタに何かのテキストを送 信してみます. 送信した文字をすぐに印字してくれるプリンタに は, &man.lptest.1; コマンドを使うと有用です. このコマンドは印 字可能な96文字のASCII文字すべてを96行生成します. PostScript PostScript (または他の言語に対応した) プリンタの場合 は, もっと巧妙なテストが必要になります. 次のような, 簡単な PostScript プログラムを使えば十分でしょう. %!PS 100 100 moveto 300 300 lineto stroke 310 310 moveto /Helvetica findfont 12 scalefont setfont (Is this thing working?) show showpage 上の PostScript コードはファイルに保存し, 以降の節で例として示されているように利用することができます. PCL このドキュメントでプリンタ用言語を参照するときは, PostScript のような言語を仮定しており, Hewlett Packard の PCL は考慮していません. PCL は非常に機能的なの ですが, プレインテキストにエスケープシーケンスを混ぜること ができます. PostScript ではプレインテキストを直接印字 することはできません. このような種類のプリンタ言語に対しては, 特別な対応をおこなわなければなりません. パラレルポートのプリンタとの接続を調べる プリンタ パラレル この節では, FreeBSDがパラレルポートに接続されたプリ ンタと通信できているかどうかを調べる方法について説明し ています. パラレルポートのプリンタをテストするために &man.su.1; コマンドで root になります. プリンタにデータを送ります. プリンタがプレインテキストを印字できる場合, &man.lptest.1; コマンドを使います. 次のように入力してください. &prompt.root; lptest > /dev/lptN ここで, N はパラレルポートの番号で, 番号は 0から始まります. プリンタが PostScript か他のプリンタ 言語を使用している場合, そのプリンタに簡単なプロ グラムを送信してください. 次のように入力します. &prompt.root; cat > /dev/lptN そして, 一行一行, プログラムを慎重に入力して 下さい. RETUREN または ENTER キーを入力してしま うと, その行は編集できなくなります. プログラムの 入力が終わったら, CONTROL+Dか, あなたが設定して いるファイル終了のキーを押してください. もしくは, プログラムを入力したファイルがある 場合は, 次のように入力してください. &prompt.root; cat file > /dev/lptN ここで, file はプログラムが格納されていて, プリンタに送信するファイルの名前です. これで何かがプリントされることでしょう. 印字されたテキ ストがおかしくても心配しなくても構いません. それについ ては, 後で修正します. シリアルポートのプリンタとの接続を調べる プリンタ シリアル この節では, FreeBSDがシリアルポートに接続されたプリ ンタと通信できているかどうかを調べる方法について述べられ ています. シリアルポートのプリンタをテストするために &man.su.1; コマンドで root になります. /etc/remote ファイルを編集します. 次のエントリを加えてください. printer:dv=/dev/port:br#bps-rate:pa=parity bit/秒 シリアルポート パリティ ここで, port シリアルポート (ttyd0, ttyd1 など) のデバイスエントリで, bps-rateは プリンタとの通信の転送速度[bit/秒], parityはプリ ンタとの通信で必要とされるパリティ (even, odd, none, zeroのいずれか) を表わしていま す. 次の例は, プリンタをシリアルケーブルでパリティなし, 転送速度 19200bpsで第3番目のシリアルポートに接続した場 合です. printer:dv=/dev/ttyd2:br#19200:pa=none &man.tip.1; コマンドでプリンタと接続します. 次のように入力してください. &prompt.root; tip printer これがうまくいかなかった場合は, /etc/remoteを編集して, /dev/ttydN の代わりに /dev/cuaaN を試してみてください. プリンタにデータを送ります. プリンタがプレインテキストを印字できる場合, &man.lptest.1; コマンドを使います. 次のように入力してください. ~$lptest プリンタが PostScript か他のプリンタ 言語を使用している場合, そのプリンタに簡単なプロ グラムを入力します. 一行一行, プログラムを慎 重に入力してください. バックスペースキーや他の編集用のキーは, プリンタの制御コードに割り当てられ ているかもしれません. プログラムが終了したことを プリンタに伝えるための特別なファイル終了キーを入 力する必要があるかもしれません. PostScript プリンタの場合, CONTROL+Dを入力します. もしくは, プログラムを入力したファイルがある 場合は, 次のように入力してください. ~>file ここで, file はプログラムが格納されているファイル名です. &man.tip.1; コマンドでファイルを送信した後は, ファイル終了を表わすキーを入力する必要があります. これで何かがプリントされることでしょう. 印字されたテキ ストがおかしくても心配しなくても構いません. それについては, 後で修正します. スプーラに許可を与える: <filename>/etc/printcap</filename> ファイル ここまでで, プリンタはコンピュータに接続され, (必要なら) プリンタと通信できるようにカーネルを変更し, 簡単なデータをプ リンタに送信することができているはずです. これで, LPDにプリ ンタへのアクセスを 制御させる設定をおこなう準備が整いました. LPDの設定は /etc/printcap を編集することでおこないます. LPDスプーリングシステムはスプーラが使われる毎にこのファイル を参照します. そのため, ファイルを更新するとすぐにその変更が 反映されます. プリンタ ケイパビリティ &man.printcap.5; ファイルの書式は簡単です. /etc/printcap の編集はお好みのテキストエディタをお 使いください. このファイルの書式は, /usr/share/misc/termcap や /etc/remote といった他のケイパビリティファイルと一致しています. この書式 のついての詳細な情報については &man.cgetent.3; をご覧ください. スプーラの単純な設定法は, 次のステップでおこないます. プリンタに名前 (と簡単な別名2〜3個) を付け, それを /etc/printcap ファイルに記述します. これについては, 「 プリンタに名前を付ける」 を参照してください. ヘッダページ sh の項目を追加することで, ヘッダページの出力を禁止します (デフォルトは許可). これについては, 「 ヘッダページの印字を禁止する」 を参照してください. スプール用のディレクトリを作成し, その位置を sd 項目で指定します. これについては, 「 スプーリングディレクトリの作成」 を参照してください. プリンタを使用するために /dev エントリを設定し, /etc/printcap の lp 項目でそのエントリを指定します. これについては, 「 プリンタデバイスの特定」 を参照してください. プリンタをシリアルポートに接続した場合は, fs, fc, xs, xc の項目を設定する必要があります. こちらについては, 「 スプーラのための通信パラメータの設定」 を参照してください. プレインテキスト用の入力フィルタのインストールを おこないます. 「 テキストフィルタのインストール」 を参照してください. &man.lpr.1; コマンドで何かを印字することで設定のテス トをおこないます. 印字してみよう と トラブルシューティング を参照してください. PostScript プリンタのような, プリンタ言語を使用しているプリンタには, プレインテキストを直接印字させることができません. 上にアウトラインを示し, 以下の節で説明する簡単な設定方法の説明では, そのようなプリンタを設置している場合は, プリンタが認識できるファイルだけを印字の対象としているという 仮定をしています. 多くの場合, 利用者はシステムに設置されているプリンタすべてで プレインテキストが印字できることを期待しています. 印字作業をおこなうために LPD のインタフェースを利用するプログラムでも, 通常, そのような仮定を置きます. プリンタ言語を使用するプリンタを設置しており, そのプリンタ言語で記述されたジョブと, これに加えて, プレインテキストのジョブも印字できるようにしたいならば, 上で示した簡単な設定方法に加えて, さらなる設定をおこなうことを強くお勧めします. すなわち, 原始的なプレインテキストから PostScript (もしくは, 他のプリンタ言語) に変換するプログラムをインストールしてください. 「 プレインテキストのジョブを PostScript プリンタで印字する」 で, それをどのようにおこなえばよいのかが説明されています. 訳注 日本語を印字したい場合は, プリンタ言語を使用し ていない「日本語プリンタ」についても, プリンタ固有のエスケープシーケンスを送る必要があります. また, 漢字コードをプリン タが設定しているものに変換したりする必要があり, 各プリンタ毎に, 日本語用のフィルタが必要になります. プリンタに名前を付ける 最初の (簡単な) ステップで, プリンタの名前を考えます. プリンタには別名をいくつか付けることもできるので, 機能的な名前 でも風変わりな名前でもどちらを選んでもまったく 問題はありません. 少なくとも1つのプリンタには, /etc/printcap の中で, lp という別名を持たせるべきでしょう. この名前はデフォルトのプリンタ名になっています. ユーザが環境変数 PRINTER を設定しておらず, かつ, LPDコマンドのコマンドラインで プリンタの名前が指定されていない場合, lp がデフォルトのプリンタ名となり, そのプリンタに出力されます. それから, これは共通の慣習ですが, プリンタの最後の別名には, メーカーやモデル名を含むプリンタの完全な名称をつけることに なっています. 名前と別名のいくつかを決めたら, /etc/printcap ファイルに設定します. プリンタ名は一番左のカラムから書き始めます. 別名はそれぞれ縦棒によって区切られ, 最後の別名の後ろにコロンを置きます. 次の例では, 2台のプリンタ (Diablo 630 ラインプリンタと Panasonic KX-P4455 PostScript レーザライタプリンタ) が定義 されている /etc/printcap のスケルトンを記しています. # # /etc/printcap for host rose # rattan|line|diablo|lp|Diablo 630 Line Printer: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4: この例では, 最初のプリンタに rattan という名前と別名として, line, diablo, lp そして Diablo 630 Line Printer が付けられています. 別名とし て lp があるので, このプリンタはデフォルトのプリンタとなっ ています. 2 番目は bamboo と名付けられ, 別名として, ps と PS, S, panasonic, Panasonic KX-P4455 PostScript v51.4 が付けられています. ヘッダページの印字を禁止する 印刷 ヘッダページ LPDスプーリングシステムでは, デフォルトでジョブ毎に ヘッダページを印字します. ヘッダページにはジョブを要求したユーザ名, ジョブが送られたホスト名, そして, ジョブの名前が素晴 らしい大きな文字で印字されています. 残念なことに, この余分なテキストすべてが, 簡単なプリンタ設定法のデバッグの際に紛れ込んできてしまいます. このため, ヘッダページの出力を禁止しておきます. ヘッダページの出力を禁止するには, /etc/printcap にあるプリンタのエントリに sh の項目を追加します. 次 に, sh を加えた /etc/printcap の例を示します. # # /etc/printcap for host rose - no header pages anywhere # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh: この書式を正しく使うための注意をしておきます. 最初の行は左端のカラムから始まります. それに続く行は TAB ひとつ分だけ字下げします. 最後の行以外のすべての行は, 行末にバックスラッシュを記述します. スプーリングディレクトリの作成 プリンタスプール プリントジョブ スプーラの簡単な設定の次のステップでは, スプーリングディレクトリを作成します. プリンタに送られるジョブは, その印字が終了するまでこのディレクトリに置かれます. また, 他のたくさんのスプーラもこのディレクトリにファイルを置きます. 様々な事情によりスプーリングディレクトリは, 通常, 慣例 として /var/spool の下に置きます. また, スプーリングディレクトリの内容は バックアップをする必要はありません. &man.mkdir.1; によってディレクトリを 作るだけでスプーリングディレクトリの復旧は完了します. スプーリングディレクトリの名前は, これも慣例ですが, 次のようにプリンタの名前と同じにします. &prompt.root; mkdir /var/spool/printer-name しかしながら, ネットワーク上に使用可能なプリンタがたく さんあるならば, LPDで印字するための専用のディレクトリに スプーリングディレクトリを置きたいと思うかもしれません. 例に出てきたプリンタ rattan と bamboo について, この方式を採用すると, 次のようになります. &prompt.root; mkdir /var/spool/lpd &prompt.root; mkdir /var/spool/lpd/rattan &prompt.root; mkdir /var/spool/lpd/bamboo 各ユーザが印字するジョブのプライバシを守りた いと考えているならば, スプーリングディレクトリを保護し て, これを誰からでもアクセスできないようにしたいと思う かもしれません. スプーリングディレクトリは, deamon ユー ザと daemon グループに所有され, 読み込み, 書き込み, 検 索可能であり, 他からはアクセスできないようにするべきで す. 例題のプリンタに対して, 次のようにすることにしましょ う. &prompt.root; chown daemon:daemon /var/spool/lpd/rattan &prompt.root; chown daemon:daemon /var/spool/lpd/bamboo &prompt.root; chmod 770 /var/spool/lpd/rattan &prompt.root; chmod 770 /var/spool/lpd/bamboo 最後に, /etc/printcap ファイルで, これらのディ レクトリの位置を LPD に伝える必要があります. スプーリ ングディレクトリのパス名は sd 項目で指定します. # # /etc/printcap for host rose - added spooling directories # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo: プリンタ名が最初のカラムから始まっており, そのプリンタ に関して記述される他のエントリは TAB で字下げされてい ること, 各行がバックスラッシュで終わっていることに注意 してください. sd によりスプーリングディレクトリが指定されていな い場合, スプーリングシステムは /var/spool/lpd デフォルト値として使用します. プリンタデバイスの特定 「ポート用エントリを /dev に追加する」では, FreeBSD でプリン タとの通信に使用される /dev ディレクトリ内のエントリを特定します. そして, LPD にその情報を伝えます. 印字するジョブを受け取ると, スプーリングシステムは, (プリンタにデータを渡す義務がある) フィルタプログラムに 代わって指定されたデバイスをオープンします. /etc/printcap ファイルで lp 項目を使って /dev エントリを記入します. ここでの例では, rattan は1番目のシリアルポートに, bamboo は6番目のシリアルポートに接続されていることにしましょう. このとき, /etc/printcap には 次のようになります. # # /etc/printcap for host rose - identified what devices to use # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5: /etc/printcap でプリンタの lp 項目が指定 されていない場合は, LPD はデフォルトとして /dev/lp を使用します. /dev/lp は, 現在の FreeBSD には存在していません. 設置したプリンタがパラレルポートに 接続されている場合は, 「 テキストフィルタのインストール」 まで読み飛ばしてください. そうでない場合は, 次節の説明に続いてください. スプーラのための通信パラメータの設定 プリンタ シリアル シリアルポートにプリンタを接続した場合, プリンタにデータを送信するフィルタプログラムに代わり, 通信速度やパリティ, その他のシリアル通信パラメータを設定することができます. このことによる利点は, /etc/printcap を編集するだけで, 様々な通信パラメータを試してみることができます. フィルタプログラムを再コンパイルする必要はありません. スプーリングシステムで, シリアル通信の設定が異なっているかもしれない複数のプリンタに 同じフィルタプログラムを使うことが可能になります. 次の /etc/printcap の項目で, lp で指定された デバイスのシリアル通信パラメータを制御できます. br#bps-rate デバイスの通信速度を bps-rate に設定します. ここ で, bps-rate は 50, 75, 110, 134, 150, 200, 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, 38400[bit/秒] のいずれかです. fc#clear-bits デバイスをオープンした後で, sgttyb 構造体の clear-bits フラグビットをクリアします. fs#set-bits sgttyb 構造体の clear-bits フラグビットをセットします. xc#clear-bits デバイスをオープンした後で, ローカルモードビット clear-bits をクリアします. xs#set-bits ローカルモードビット set-bits をセットします. fc, fs, xc, そして xs のビットに関する詳しい情報については, /usr/include/sys/ioctl_compat.h を参照してください. 項目 lp で指定されたデバイスを LPD がオープンするとき, LPD は sgttyb 構造体のフラグビットを読み出します. そして, 項目 fc の全ビットをクリアします. 次に, 項目 fs のビットをセットし, その結果を設定します. ローカルモードビットに関しても同様におこなわれます. 例題のプリンタで6番目のシリアルポートに接続された プリンタの設定を追加してみましょう. 通信速度は38400bpsに設定します. フラグビットとして, TANDEM, ANYP, LITOUT, FLUSHO, PASS8 をセットします. ローカルモードビットでは, LITOUT と PASS8 フラグをセットします. bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000c1:xs#0x820: テキストフィルタのインストール プリントフィルタ ここまでで, プリンタにジョブを送るために使うテキストフィ ルタを LPD に設定する準備が整いました. テキストフィルタとは, 入力フィルタとしても知られていますが, 印字するジョブがあるときに LPD が起動するプログラムです. LPD がプリンタのためにテキストフィルタを起動するとき, LPD はフィルタの標準入力からプリントするジョブを入力し, フィルタの標準出力に項目 lp で指定されたプリンタデバイスを接続します. フィルタは, 標準入力からジョブを読み込み, プリンタのための必要な変換をおこなった後, その結果を標準出力に出力する, これにより印字がなされることを期待されています. テキストフィルタについての更に詳しい情報については, 「 フィルタはどのように機能しているか」 をご覧ください. ここでの簡単なプリンタ設定では, プリンタにジョブを送るため, /bin/cat を実行するだけの簡単なシェルスクリプトで間に合います. FreeBSD に標準で付属している lpf というフィルタでは, バックスペース文字を使った 下線引きの動作をおこなう文字ストリームをうまく扱うことができない プリンタのための代替処理をおこなってくれます. もちろん, 他のどんなフィルタプログラムを使っても構いません. フィルタ lpf については, 「テキストフィルタ lpf」で詳しく説明します. 最初に, 簡単なテキストフィルタであるシェルスクリプト /usr/local/libexec/if-simple を作ってみましょう. 次のテキストをお好みのテキストエディタでファイルに 書き込んでください. #!/bin/sh # # if-simple - Simple text input filter for lpd # Installed in /usr/local/libexec/if-simple # # Simply copies stdin to stdout. Ignores all filter arguments. /bin/cat && exit 0 exit 2 そして, このファイルを実行可能にします. &prompt.root; chmod 555 /usr/local/libexec/if-simple LPD にこのテキストフィルタを使うことを設定するためには, /etc/printcap に if 項目を使って指定します. これまでの /etc/printcap の例のプリンタ 2 台に, このフィルタを加えてみましょう. # # /etc/printcap for host rose - added text filter # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:\ :if=/usr/local/libexec/if-simple: LPD を起動します &man.lpd.8; は lpd_enable 変数に従って /etc/rc から実行されます. この変数の デフォルト値は NO です. まだ そうしていなかったならば lpd_enable="YES" の行を /etc/rc.conf に追加して 計算機を再起動するか, そのまま &man.lpd.8; を 起動してください. &prompt.root; lpd 印字してみよう 簡単な LPD 設定も終わりにたどり着きました. 残念ながら, 設定はこれでおしまいというわけではありません. なぜなら, さらに, 設定をテストし, すべての問題点を解決しなくてはならないからです. 設定をテストするために, 何かを印字してみましょう. LPD システムで印字をするためには, &man.lpr.1; コマンドを使います. このコマンドは, 印字するためのジョブを投入する働きをします. &man.lpr.1; コマンドを 「 プリンタとの通信状況を調べる」で紹介した, あるテスト用のテキストを生成してくれる &man.lptest.1; プログラムと一緒に使うこともできます. 簡単な LPD 設定をテストするために: 次のように入力してください. &prompt.root; lptest 20 5 | lpr -Pprinter-name ここで, printer-name は /etc/printcap で指定したプリンタ名 (もしくはその別名) です. デフォルト のプリンタを使用する場合は, 引数を付けないで &man.lpr.1; を打ち込んでください. もう一度述べますが, ポストスクリプトを期待しているプリンタをテストするならば, &man.lptest.1; を使う代わりに PostScript で書かれた プログラムをプリンタに送ってください. プログラムを送るためには, プログラムをファイルに格納して, lpr file と打ち込みます. PostScript プリンタの場合, 送信したプログラムによる結果が得られるでしょう. &man.lptest.1; を使った場合は, 以下のような結果が見られるでしょう. !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 #$%&'()*+,-./0123456 $%&'()*+,-./01234567 %&'()*+,-./012345678 更にプリンタをテストしたい場合は, (言語ベースのプリンタのための) もっと大きなプログラムを送信するか, 引数を変えて &man.lptest.1; を実行します. 例えば, lptest 80 60 で, それぞれ 80 文字の行を 60 行生成します. プリンタがうまく動かなかった場合は, 次の節, 「 トラブルシューティング」をご覧ください. プリンタ設定上級編 この節では, 特殊な形式のファイルを印字するためのフィルタ, ヘッダページ, ネットワーク越しのプリンタへの印字, そして, プリンタ使用の制限や課金について説明しています. フィルタ プリントフィルタ LPD では, ネットワークプロトコル, キュー, アクセス制御, そして, 印字のためのその他の側面について扱いますが, 実際の作業のほとんどは フィルタ よっておこなわれています. フィルタは, プリンタと通信し, プリンタのデバイス依存性や特殊な要求を扱うプログラムです. 簡単なプリンタ設定では, プレインテキストのためのフィルタをインストールしました. このプレインテキストフィルタは, ほとんどのプリンタで機能する極めて単純なものでした. (「 テキストフィルタのインストール」を参照) しかしながら, 形式変換やプリンタ課金, 特定のプリンタの癖, など をうまく利用するためには, フィルタがどのように機能するかという ことを理解しておくべきです. これらの側面を扱うためには, 最終的には, フィルタの責任であるからです. そして, これは悪い情報ですが, ほとんどの場合において, あなた自身が フィルタを供給する必要があるということです. また都合のよいことには, たくさんのフィルタが一般的に利用できるということです. もしフィルタがなかったとしても, 普通はフィルタを作るのは簡単です. FreeBSD にも, プレインテキストを印字させることができる /usr/libexec/lpr/lpf というフィルタが1つ付いています. (このフィルタはファイルに含まれるバックスペースやタブを扱います. また, 課金をすることもできますが, できることはこれだけしかありません.) いくつかのフィルタとフィルタの構成要素は FreeBSD Ports Collection にもあります. この節で述べることは次の通りです. 「 フィルタはどのように機能しているか」では, 印字の過程におけ るフィルタの役割を概説します. この節を読むことで, LPD がフィルタを使うときに, 見えないところで何が 起こっているかが理解できるでしょう. このことを知っておくと, プリンタそれぞれに様々なフィルタをインストールしたときに 遭遇するかもしれない問題を予期したり, デバッグするときに役立つでしょう. LPD では, すべてのプリンタからデフォルトで プレインテキストを印字できることを期待しています. このことは, プレインテキストを直接印字できない PostScript (また は他の言語用の) プリンタでは問題を引き起こします. 「 プレインテキストのジョブを PostScript プリンタで印字する」 で, この問題を克服する方法について述べます. PostScript プリンタをお持ちの方は, この節をお読みになることをおすすめします. PostScript は様々なプログラムのための有名な出 力形式です. ある人たちは (著者自身を含めて) PostScript のコードさえも直接書いてしまいます. しかし, PostScript プリンタは高価です. 「非 PostScript プリンタで PostScript をシミュレートする」では, PostScript データを非 PostScript プリンタに受けつけさせ, 印字させるために, どのようにしてプリンタ用のテキストフィルタをさらに変更すればよいのか, ということについて述べます. PostScript プリンタを持っていない方は, この節をお読みになることをおすすめします. 「 変換フィルタ」では, 図形や組版データといった特定のファイル形式を, プリンタが理解できる形式へ変換する作業を自動的におこなわせる方法について述べます. この節を読むと, troff のデータを印字するには lpr -t, または, TeX DVI を印字するには lpr -d, ラスタイメージデータを印字するには lpr -v, などといったようにユーザが入力することができるように プリンタの設定をおこなうことができます. この節もお読みになることをお薦めします. 「出力フィルタ」 では, あまり使われない LPD の機能のすべて, すなわち, 出力フィルタに関することが記述されています. ヘッダページ (「 ヘッダページ」参照) を印字させていない場合は, 多分, この節は飛ばしても構わないでしょう. 「テキストフィルタ lpf」では, lpf についての説明が, ほぼ完全におこなわれています. これは FreeBSD に付属するラ インプリンタ (または, ラインプリンタのように動作するレーザプリンタ) のための, 単純なテキストフィルタです. プレインテキストを印字したことに対して課金をおこなう方法が 至急必要な場合, もしくは, バックスペース文字を印字しようと すると煙を発するプリンタを持っている場合は, 絶対に lpf を検討するべきです. フィルタはどのように機能しているか 既に言及したように, フィルタとは, プリンタにデータを送る際に, デバイスに依存した部分を取り扱うために LPD によって起動される実行プログラムです. LPD がジョブ中のファイルを印字しようとするとき, LPD はフィルタプログラムを起動します. このとき, フィルタの標準入力を印字するファイルに, 標準出力をプリンタに, そして, 標準エラー出力を エラーログファイル (/etc/printcap 内の lf 項目で指定されたファイル, または, 指定されていない場合は, デフォルトとして /dev/console) にセットします. troff LPD が起動するフィルタと, その引数が何であるかは, /etc/printcap ファイルの内容と, ジョブの起動時にユーザが指定した &man.lpr.1; コマンドの引数に依存しています. 例えば, ユーザが lpr -t と入力した場合は, LPD は出力先のプリンタ用の tf 項目で指定されている troff 用のフィルタを起動させるでしょう. ユーザがプレインテキストの印字を指示したときは, if で指定されたフィルタが起動されるでしょう (このことはほとんどの場合にあてはまります. 詳細については, 「 出力フィルタ」をご覧ください). /etc/printcap で指定可能なフィルタは次の3種類があります. テキストフィルタ (LPD のドキュメントでは紛らわしいことに 入力フィルタと呼んでいますが) は一般のテキストの印字を扱います. これはデフォルトのフィルタと 考えてください. LPD では, すべてのプリンタに対して, デフォルトでプレインテキストが印字できることを期待しています. さらに, バックスペースやタブを正しく扱い, また, 他の特殊な文字が入力されてもプリンタに混乱を来さないように するのはテキストフィルタの仕事であると考えています. プリンタの使用に対して課金をしなくてはならない環境にあ るときは, テキストフィルタが印字したページ数を数える作 業もしなくてはなりません. この作業は, 通常, 印字した行 数を数え, これをプリンタが1ページ当たりに印字できる行 数と比較することでおこなわれます. テキストフィルタは, 次のような引数を付けて起動されます. filter-name -c -wwidth -llength -iindent -n login -h host acct-file ここで, lpr -l によってジョブが入力されたときに与えられます. width /etc/printcap で指定された pw (page width) 項目の値が与えられます. デフォルトは, 132です. length pl (page length) 項目で指定された値が与えられます. デフォルトは66です. indent lpr -i によって与えられた字下げの量で, デフォルトは 0 です. login ファイルを印字したユーザのアカウント名が 与えられます. host ジョブが入力されたホスト名が 与えられます. acct-file af 項目で指定されている課金データファイル の名前が与えられます. プリンタ フィルタ 変換フィルタは, 特定のファイル形式をプリンタ が紙に印字できるようなものに変換します. 例えば, プリンタで ditroff 組版データを直接印字することはできません. しかし, ditroff データをプリンタが消化し, 印字することができる形式へ変換するために, ditroff ファイル用フィルタをインストールすることができます. 「 変換フィルタ」 で, これらに関するすべてについて説明します. プリンタの課金をする必要がある場合は, 変換フィルタでも印字ページを数える作業が必要となります. 変換フィルタは次の引数をとって起動されます. filter-name -xpixel-width -ypixel-height -n login -h host acct-file ここで, pixel-width は, px 項目で指定された値 (デフォルトは0), pixel-height は, py 項目で指定された値 (デフォルトは0) です. 出力フィルタは, テキストフィルタが指定されて おらず, かつ, ヘッダページの出力が許可されている場合にのみ使われます. 「 出力フィルタ」で, これらのことについて説明します. アウトプットフィルタに対する引数は次の2つだけです. filter-name -wwidth -llength ここで, と は, テキストフィルタの場合と同じです. フィルタは, 次に示すの終了状態をもってプログラムを exit するべきです. exit 0 フィルタがファイルを正常に印字した場合. exit 1 フィルタはファイルの印字に失敗したが, LPD に再度ファイルの印字を試みて欲しい場合. この終了状態で終了した場合, LPD はフィルタを再スタートします. exit 2 フィルタはファイルの印字に失敗し, かつ, LPD に再出力を試みて欲しくない場合. この場合, LPD はそのファイルを放棄します. FreeBSD に付属するテキストフィルタ /usr/libexec/lpr/lpf は, FORM FEED 文字が送られたときやプリンタ使用に対する課金をどのようにするかを決定するために, ページ幅やページ長の引数を利用します. また, 課金用のエントリを作成するため, ログイン名, ホスト名, 課金ファイル名の引数を利用します. もし, フィルタの購入を検討しているならば, LPD と互換性があるかどうかを確認してください. もしそうならば, 上述の引数リストをサポートしていなければなりません. 一般向けの使用のためにフィルタを作成する計画をしている場合は, 同じ引数リストと終了コードをサポートしてください. プレインテキストのジョブを PostScript プリンタで印字する プリントジョブ コンピュータと PostScript (または, 他の言語に対応した) プリンタをあなたしか使用しない場合は, プリンタにプレ インテキストを絶対に送らない, そして, プリンタにプレインテキストを送りたがっている 様々なプログラムの機能を決して使わないことにしてください. そうすれば, この節に書かれたことに心を煩わせる必要はまったくなくなります. しかし, PostScript とプレインテキストの両方のジョブをプリンタへ送りたいと思っている場合は, プリンタ設定についての要求が増えるでしょう. 両者をプリンタへ送信するためには, 到着したジョブがプレインテキストであるか PostScript であるかを検出するテキストフィルタが必要です. PostScript のジョブはすべて %! で始まらなければならないことになっています (他のプリンタ言語に関しては, プリンタのドキュメントをご覧ください). ジョブの最初の2文字がこれならば, PostScript であることが分かります. したがって, ジョブのそれ以降の部分をプリンタに直接送ることができます (訳注: PostScript では, % 以降はコメントとして扱われるので, 最初の %! の行を読み捨てても問題はない). 最初の2文字が %! でない場合は, フィルタはテキストを PostScript に変換し, その結果を使って印字をおこないます. この作業をどうやってやればよいのでしょうか. プリンタ シリアル シリアルポートにプリンタを接続した場合は, lprps をインストールすることをお勧めします. lprps は PostScript 用のフィルタで, プリンタとの双方向通信をおこないます. このフィルタでは, プリンタからの冗長な情報を得ることで, プリンタの状況を示すファイルが更新されていきます. したがって, ユーザや管理者は (トナー残量少や 紙詰まりといった) プリンタの状況を正確に知ることができます. しかし, もっと重要なことは, psif と呼ばれるプログラムが含まれているということです. このプログラムは, 入力されたジョブがプレインテキストかどうかを検出し, これを PostScript に変換するために, textps (lprps に付属する別のプログラム) を呼び出します. そして, このジョブをプリンタに送るために, lprps が使われます. lprps は FreeBSD Ports Collection に含まれています (Ports Collection を参照してください). もちろん,自分自身でプログラムを取ってきて, コンパイルし, インストールすることもできます. lprps をインストールした後は, lprps の一部である psif プログラムのパス名を指定するだけです. Ports Collection から lprps をインストールしたときは, /etc/printcap の中のシリアル接続した PostScript プリンタのエントリに対して, 次を使ってください. :if=/usr/local/libexec/psif: LPD にプリンタをリード・ライトモードでオープンさせるために, rw 項目も指定すべきです. パラレルポートに接続したプリンタの場合 (すなわち, lprps が 必要としているプリンタとの双方向通信ができない), テキストフィルタとして次のシェルスクリプトを使うことができます. #!/bin/sh # # psif - Print PostScript or plain text on a PostScript printer # Script version; NOT the version that comes with lprps # Installed in /usr/local/libexec/psif # read first_line first_two_chars=`expr "$first_line" : '\(..\)'` if [ "$first_two_chars" = "%!" ]; then # # PostScript job, print it. # echo "$first_line" && cat && printf "\004" && exit 0 exit 2 else # # Plain text, convert it, then print it. # ( echo "$first_line"; cat ) | /usr/local/bin/textps && printf "\004" && exit 0 exit 2 fi 上記のスクリプトにおいて, textps はプレインテキストから PostScript へ変換するために別にインストールしたプログラムです. テキストから PostScript へ変換するのには, お好みのどんなプロ グラムでも使うことができます. FreeBSD Ports Collection (Ports Collection を参照してください) には, a2ps と呼ばれるテキストから PostScript に変換するプログラムが入っています. 訳注 上記スクリプトでは, 先頭の行を読み込むために read を使っていますが, 困ったことに, read は読み込んだ文字列の先頭の空白文字を取り除いてしまいます. 従って, これらの空白文字は印字されないことになり, 印字結果がファイルのイメージと異なる場合が出てきます. この事情は csh を利用した場合でも変わりません. 仮に, 先頭の空白文字を除去しない read コマンドを作ったとしても, 「echo $first_line」の $first_line 変数の内容をシェルが展開する際に $first_line の先頭の空白文字が失われるため, 問題の解決にはなりません. 残念ながら, 訳者はこの問題をシェルプログラムだけで解決する方法をしりません. perl か C 言語の力を借りないと解決できないと思います. 非 PostScript プリンタで PostScript をシミュレートする PostScript エミュレーション Ghostscript PostScript は質の高い組版と印字をおこなうための事実 上の標準です. しかしながら, PostScript は, 高価な標準です. ありがたいことに, Alladin Enterprises から Ghostscript と呼ばれる, PostScript 互換の動作をするフリーのプログラムが出されていて, FreeBSD で動きます. Ghostscript はほとんどの PostScript ファイルを読むことができ, これらの各ページをたくさんのブランドの非 PostScript プリンタを含む 様々なデバイス用に変換することができます. Ghostscript をインストールし, プリンタ用の特別なテキストフィルタを使うことによって, 非 PostScript プリンタをあたかも本物の PostScript プリンタであるかのように動作させることができます. Ghostscript は FreeBSD Ports Collection に入っていますので, そこからインストールすることができます. また, 自分でソースプログラムを持ってきて, コンパイルし, インストー ルすることもできます. この作業はとても簡単にできます. PostScript プリンタをシミュレートさせる場合は, テキストフィルタに PostScript ファイルを印字しようとしているかどうかを検出させます. PostScript ファイルでない場合は, フィルタはそのファイルを直接プリンタに送ります (訳注: テキストファイルを直接印字できない場合は, もちろん, 変換フィルタを通す必要があります). PostScript の場合は, まず, Ghostscript を使い, ファイルをそのプリンタが理解できる形式へ変換します. 次の例のスクリプトは, Hewlett Packard DeskJet 500 プリンタ用 のテキストフィルタです. 他のプリンタで用いるときは, 引数を gs (Ghostscript) コマンドに変えてください. (gs -h と入力すると, 現在インストールされている Ghostscript でサポートされているデバイスのリストが得られます). #!/bin/sh # # ifhp - Print Ghostscript-simulated PostScript on a DeskJet 500 # Installed in /usr/local/libexec/hpif # # Treat LF as CR+LF: # printf "\033&k2G" || exit 2 # # Read first two characters of the file # read first_line first_two_chars=`expr "$first_line" : '\(..\)'` if [ "$first_two_chars" = "%!" ]; then # # It is PostScript; use Ghostscript to scan-convert and print it. # # Note that PostScript files are actually interpreted programs, # and those programs are allowed to write to stdout, which will # mess up the printed output. So, we redirect stdout to stderr # and then make descriptor 3 go to stdout, and have Ghostscript # write its output there. Exercise for the clever reader: # capture the stderr output from Ghostscript and mail it back to # the user originating the print job. # exec 3>&1 1>&2 /usr/local/bin/gs -dSAFER -dNOPAUSE -q -sDEVICE=djet500 \ -sOutputFile=/dev/fd/3 - && exit 0 # /usr/local/bin/gs -dSAFER -dNOPAUSE -q -sDEVICE=djet500 -sOutputFile=- - \ && exit 0 else # # Plain text or HP/PCL, so just print it directly; print a form # at the end to eject the last page. # echo $first_line && cat && printf "\033&l0H" && exit 0 fi exit 2 最後に, if 項目を通して, LPD にこのフィルタを教えてやる必要があります. :if=/usr/local/libexec/hpif: これでおしまいです. lpr plain.text とか lpr whatever.ps と入力してみましょう. どちらも正常に印字されるはずです. 訳注 日本語を印字する場合は, 日本語対応の Ghostscript が必要です. 日本語対応版の Ghostscript も Ports Collection に入っています. 変換フィルタ 「プリンタ設定導入編」 に書かれた簡単な設定が完了したら, 最初に, やってみたいと思うことは, 多分(プレイン ASCII テキストに加えて) 好みのファイル形式のための変換フィルタをインストールすることでしょう. なぜ, 変換フィルタをインストールするのか? TeX dvi ファイルの印刷 変換フィルタによって, 様々な種類のファイルを印字することが簡単になります. 例えば, TeX 組版システムでたくさんの仕事をしたと仮定しましょう. そして, PostScript プリンタが接続 されているとします. すると, TeX で DVI ファイルを作成する度に, DVI ファイルを印字するために, これを PostScript ファイルに変換する必要があります. このコマンドは次のようになるでしょう. &prompt.user; dvips seaweed-analysis.dvi &prompt.user; lpr seaweed-analysis.ps DVI ファイル用の変換フィルタがインストールしてあると, LPD に 変換を肩代わりさせることで毎回毎回 おこなわなければならなかった面倒な変換作業を省くことができます. つまり, DVI を生成したら, 次のような1回のコマンド入力だけで, これが印字されます. &prompt.user; lpr -d seaweed-analysis.dvi LPD に DVI ファイルの変換をさせるためには, オプション を指定します. 変換オプションのリストは「 整形と変換に関するオプション」 に載せてあります. 変化のオプションのそれぞれをプリンタに サポートさせるためには, 変換フィルタをインストールし, そのパス名を /etc/printcap の中で指定しなくてはなりません. 変換フィルタは, プレインテキストを印字する代わりに, フィルタはファイルを プリンタが理解できる形式に変換するところを除けば, 「プリンタの簡単な設定」で説明したテキストファイル (「 テキストフィルタのインストール」 を見て下さい) に似ています. どの変換フィルタをインストールすべきか? 使いたいと思う変換フィルタをインストールすべきです. DVI のデータを頻繁に印字するならば, DVI 変換フィルタ をインストールするのが適切でしょう. 印字しなくてはなら ない troff を大量に抱えている場合は, 多分, troff フィルタが欲しくなるはずです. 次の表は, LPD で動作するフィルタと, /etc/printcap ファイルでのエントリする項目, そして, lpr コマンドで呼び出す方法をまとめたものです. ファイル形式 /etc/printcap項目 lpr オプション cifplot cf DVI df plot gf ditroff nf FORTRAN text rf troff tf raster vf プレインテキスト if なし, , または 先の例のように, lpr -d を使うためには, 出力先のプリンタの /etc/printcap 内のエントリで, df 項目が必要であることが分かります. fortran 反論はあるかも知れませんが, FORTRAN テキストや plot のような形式は, 多分, 廃れてていくでしょう. あなたのサイトで, 自前のフィルタをインストールするだけで, プリントオプションのいくつか, あるいは, 全部に新しい意味を与えることができます. 例えば, Prinerleaf ファイル (Interleaf デスクトップパブリッシングプログラムによるファイル) を直接印字したいとします. そして, Printerleaf 用の変換フィルタを gf 項目で 指定したパスにインストールすれば, lpr -g の意味はPrinterleaf ファイルを印字する意味だとユーザに教えることができます. 変換フィルタのインストール 変換フィルタは FreeBSD の基本システムのインストールとは別にインストールするプログラムなので, 変換フィルタは, 多分, /usr/local ディレクトリの下に置くべきです. フィルタは LPD だけが実行する特別なプログラム, すなわち, 一般ユーザが実行する必要すらないプログラムなので, /usr/local/libexec ディレクトリに置くのが普通です. 変換フィルタを使用可能にするためには, /etc/printcap の目的のプリンタの適切な項目に フィルタがあるパス名を指定します. DVI 変換フィルタをプリンタ bamboo のエントリに加えてみましょう. プリンタ bamboo の df 項目を新たに加えた /etc/printcap ファイルの例を以下に再掲します. # # /etc/printcap for host rose - added df filter for bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: DVI フィルタは /usr/local/libexec/psdf という 名前のシェルスクリプトです. このスクリプトは次のようになっています. #!bin/sh # # psdf - DVI to PostScript printer filter # Installed in /usr/local/libexec/psdf # # Invoked by lpd when user runs lpr -d # exec /usr/local/bin/dvips -f | /usr/local/libexec/lprps "$@" このスクリプトでは, dvips をフィルタモード (引数 ) で, 標準入力上で起動しています. 標準入力は印字するジョブです. それから, PostScript プリンタ用フィルタ lprps (これについては「 プレインテキストのジョブを PostScript プリンタで印字する」 を参照してください) を LPD に与えられた引数を付けて起動します. lprps はこれらの引数を印字されたページ分の課金をおこなうために使われます. 変換フィルタのその他の例 変換フィルタのインストールには決まったステップがないので, その代わりに, 例をもっと挙げることにします. これを自分でフィルタを作る際のガイドにしてください. 適当な例があったら, それをそのまま使ってください. 次のスクリプト例は, Hewlett Packard LaserJet III-Si のための, raster (ええと・・実は, GIF ファイル) 用の変換フィルタです. #!/bin/sh # # hpvf - Convert GIF files into HP/PCL, then print # Installed in /usr/local/libexec/hpvf PATH=/usr/X11R6/bin:$PATH; export PATH giftopnm | ppmtopgm | pgmtopbm | pbmtolj -resolution 300 \ && exit 0 \ || exit 2 ここでは, GIF ファイルから PNM (portable anymap) 形式に変換し, 次に PGM (portable graymap) 形式に変換してから, LaserJet/PCL-互換データに変換しています. 上記のフィルタを使うプリンタのためのエントリを付け加えた /etc/printcap ファイルは次のようになります. # # /etc/printcap for host orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif:\ :vf=/usr/local/libexec/hpvf: 次のスクリプトは, PostScript プリンタ bamboo のための groff 組版システムの troff データのための変換フィルタです. #!/bin/sh # # pstf - Convert groff's troff data into PS, then print. # Installed in /usr/local/libexec/pstf # exec grops | /usr/local/libexec/lprps "$@" 上記のスクリプトではプリンタとの通信をおこなうため, lprps をまた利用しています. プリンタがパラレルポートに接続されている場合は, 代わりに, 次のスクリプトを使うかもしれません. #!/bin/sh # # pstf - Convert groff's troff data into PS, then print. # Installed in /usr/local/libexec/pstf # exec grops これで完成しました. 次に, フィルタを使用可能にするため に /etc/printcap に加える必要があるエントリを示します. :tf=/usr/local/libexec/pstf: 次の例をみたら, FORTRAN のベテランは赤面するかもしれません. この FORTRAN テキストフィルタは, プレインテキストを直接印字できるすべてのプリンタで利用できます. このフィルタをプリンタ teak にインストールすることにしましょう. #!/bin/sh # # hprf - FORTRAN text filter for LaserJet 3si: # Installed in /usr/local/libexec/hprf # printf "\033&k2G" && fpr && printf "\033&l0H" && exit 0 exit 2 そして, このフィルタを使用可能にするため, 以下の行を /etc/printcap のプリンタ teak のエントリに加えます. :rf=/usr/local/libexec/hprf: これが最後の, そして, 若干複雑な例です. 前に紹介した LaserJet プリンタ teak に, DVI フィルタを加える ことにしましょう. 最初に, 簡単な部分をおこないます. すなわち, DVI フィルタの位置を /etc/printcap に書き加えます. :df=/usr/local/libexec/hpdf: さて, 難しい部分であるフィルタの作成をおこないます. このために, DVI から LaserJet/PCL への変換プログラムが必要です. FreeBSD の Ports Collection (Ports Collection を参照してください) には, それがあります. dvi2xx というのがそのパッケージの名前です. これをインストールすると, 必要なプログラム dvilj2p が使えます. このプログラムは DVI を LaserJet IIp, LaserJet III, そして LaserJet 2000 の互換コードへ変換してくれます. dvilj2p はフィルタ hpdf を極めて複雑にしています. なぜなら, dvilj2p は標準入力からデータを読み込むことができないからです. このプログラムを働かせるためには, ファイル名が必要です. もっと悪いことに, ファイル名は .dvi で終わっている必要があり, 標準入力の代わりに, /dev/fd/0 を使うのは問題があります. この問題は, (.dvi で終わる) 一時的なファイル名から/dev/fd/0 に (シンボリックな) リンクを張る ことで回避することができます. これで, dvilj2p に強制的に標準入力からデータを読み込ませることができます. もう1つの問題は, 一時的なリンクを張るために /tmp ディレクトリを使うことができないという事実です. シンボリックリンクはユーザ, グループが bin であるユーザに所有されています. フィルタはユーザ daemon として起動します. そして, /tmp ディレクトリはスティッキービットが立っています. フィルタはリンクを作ることができます. しかし, リンクは別のユーザに所有されているため, 作業が終了したとき, このリンクを削除することができません. その代わりに, シンボリックリンクは現在の作業ディレクトリ, すなわち, スプーリングディレクトリ (/etc/printcap の sd 項目で指定する) に作ることにします. フィルタが作業するにはここの場所は完璧な場所で, なぜなら, 特に, スプーリングディレクトリのディ スクの空き容量は (ときどき) /tmp ディレクトリよりもたくさんあるからです. 以下に示すのが最後のフィルタです. #!/bin/sh # # hpdf - Print DVI data on HP/PCL printer # Installed in /usr/local/libexec/hpdf PATH=/usr/local/bin:$PATH; export PATH # # Define a function to clean up our temporary files. These exist # in the current directory, which will be the spooling directory # for the printer. # cleanup() { rm -f hpdf$$.dvi } # # Define a function to handle fatal errors: print the given message # and exit 2. Exiting with 2 tells LPD to do not try to reprint the # job. # fatal() { echo "$@" 1>&2 cleanup exit 2 } # # If user removes the job, LPD will send SIGINT, so trap SIGINT # (and a few other signals) to clean up after ourselves. # trap cleanup 1 2 15 # # Make sure we are not colliding with any existing files. # cleanup # # Link the DVI input file to standard input (the file to print). # ln -s /dev/fd/0 hpdf$$.dvi || fatal "Cannot symlink /dev/fd/0" # # Make LF = CR+LF # printf "\033&k2G" || fatal "Cannot initialize printer" # # Convert and print. Return value from dvilj2p does not seem to be # reliable, so we ignore it. # dvilj2p -M1 -q -e- dfhp$$.dvi # # Clean up and exit # cleanup exit 0 自動変換: その他の変換フィルタ ここまでに述べてきたフィルタによって, 印字環境の能率が上がったことと思います. しかし, これはどのフィルタを使うかを ( &man.lpr.1; のコマンドライン上で) ユーザが指定しなくてはならないという代価を支払って実現されています. コンピュータの事情にあまり詳しくないユーザにとって, フィルタのオプションを指定させられるということは いらいらさせられるものになるでしょう. 更に悪いことに, 間違ったフィルタオプションを指定されると, 間違った形式のファイルがそのフィルタに適用されることになり, その結果, 何百枚もの紙を掃き出すことになるかもしれません. そのような結果になるならば, 変換フィルタをインストールするよりもむしろ, テキストフィルタ (これがデフォルトフィルタなので) に印字するよう要求されたファイルの形式を検出させ, 自動的に, 適切な変換フィルタを起動するようにしたいと思うかもしれません. ここでは file コマンドのようなツールを役立たせることができます. もちろん, いくつかの ファイル形式の違いを見分けることは難しいことでしょう. そして, もちろん, それらのファイルに対しては, 変換フィルタを提供するだけで済ますこともできるのです. apsfilter プリンタ フィルタ apsfilter FreeBSD Ports Collection には, apsfilter と呼ばれる自 動変換をおこなうテキストフィルタがあります. このフィルタは プレインテキスト, PostScript, DVI ファイルを検出し, 適当な変換をおこなった後, データを印字することができます. 出力フィルタ LPD スプーリングシステムでは, ここまでにまだ取り上げていないフィルタ形式, 出力フィルタをサポートしています. 出力フィルタは, テキストフィルタのように, プレインテキストのみを印字するために意図されたものですが, 非常に簡単化されています. テキストフィルタを用いずに, 出力フィルタを使っている場合は, 次のようになります. LPD はジョブ中の各ファイルに一度ではなく, ジョブ全体に対して一度だけ出力フィルタを起動します. LPD は出力フィルタに対し, ジョブ中のファイルの先頭や末尾を特定するための対策を 一切おこなっていません. LPD はユーザのログイン名やホスト名をフィルタに渡しません. したがって, 課金の処理をおこなうことは考えていません. 実際, 出力フィルタには, 以下2つの引数しか与えられません. filter-name -wwidth -llength ここで, width は対象となるプリンタの pw 項目, length は pl 項目に指定された数です. 出力フィルタの簡便さに誘惑されてはいけません. もし, ジョブ中のそれぞれのファイルに別のページ番号を付加しようとしても, 出力フィルタはうまく動作しないでしょう. そのような動作を期待しているならば, (入力フィルタとしても知られている) テキストフィルタを使ってください. 詳しくは, 「 テキストフィルタのインストール」をご覧ください. さらに, 出力フィルタは, 実のところ, もっと複雑になっています. まず, 特殊なフラグ文字を検出するために, フィルタに送られてくるバイトストリームを検査する必要があります. また, LPDに代わって, 自分自身にシグナルを送らなければなりません. しかしながら, ヘッダページの印字をおこないたい場合, また, エスケープシーケンスやヘッダページを印字できるようにする その他の初期化文字列を送信する必要がある場合, 出力ファイルが必要です. 1台のプリンタに対し, LPD では出力フィルタとテキスト, または, 他のフィルタを両方使うことができます. このような場合, LPD はヘッダページ (「 ヘッダページ」 を参照してください) だけを印字させるために, 出力フィルタを起動させます. それから LPD では, アウトプットフィルタに 2 バイトの文字 (ASCII 031 の次に ASCII 001) を送ることで, 出力フィルタが自力で停止することを期待しています. 2 バイト (031, 001) が出力フィルタに送られたとき, 出力フィルタは自分自身にシグナル SIGSTOP を送ることによって停止するべきです. LPD がその他のフィルタの起動を完了したとき, LPD は出力フィルタにシグナル SIGCONT を送ることで, 出力フィルタを再起動させます. 出力フィルタがあり, テキストフィルタがない場合, LPD はプレインテキストのジョブをおこなう際に, 出力フィルタを使います. 前述したように, 出力フィルタでは, ジョブ中の各ファイルの並びの間に FROM FEED 文字や紙を排出する他の文字を入れることはしません. この動作は多分, あなたが求めているものとは異なっているでしょう. ほとんどすべての場合において, テキストフィルタが必要とされるはずです. プログラム lpf は, テキストフィルタの項で既に紹介しましたが, 出力フィルタとしても動作させることができます. もし, 簡便で極悪な出力フィルタが必要で, かつ, バイトストリームを検査したりシグナルを送るコードを書きたくないときには, lpf をお試しください. あるいは, プリントが要求する初期化コードを送るために, lpf をシェルスクリプトに包んで使うこともできます. テキストフィルタ <command>lpf</command> プログラム /usr/libexec/lpr/lpf は, FreeBSD の バイナリ配布に付属しているテキストフィルタ (入力フィルタ) で, 出力を字下げしたり (lpr -i でジョブが入力さ れたとき), 文字を未処理のままプリンタに送ったり (lpr -l でジョブが入力されたとき), ジョブ中のバックスペースやタブの印字位置を調節したり, 印字したページに対して課金したりすることができます. また, このフィルタは出力フィルタとしても動作させることができます. lpf は多くの印字環境において使用することに適しています. このフィルタには, プリンタに初期化文字列を送る機能はありませんが, 必要とされる初期化をおこない, それから lpf を実行させるためのシェルスクリプトを作成するのはたやすいことです. ページ課金 課金 プリンタ lpf に対して, 印字ページへの課金を正確におこなわせるためには, /etc/printcap ファイルの中の pw と pl の項目に正確な値を入れておく必要があります. これらの値は, どのくらいの量のテキストがページにフィットするか, また, ユーザのジョブが何ページあるのかを調べるために使われます. プリンタの課金についての詳しい情報については, 「 プリンタの利用に対する課金」をご覧ください. ヘッダページ あなたが管理するシステムのユーザが たくさんおり, ユーザ全員が様々なプリンタを使用する場合, 多分, 必要悪であるヘッダページを 印字させることを検討したいと思うかもしれません. バナーページ ヘッダページ ヘッダページ ヘッダページは, バナー とか バーストページ としても知られていますが, 出力されたジョブが誰によるものなのかを特定させる働きがあります. 印字結果の山の中において, ユーザのジョブによって印字された本物のドキュメント部分よりも際立たせるために, ヘッダページは, 通常, 多分, 縁が装飾されている大きな太文字で印字されます. ヘッダページにより, ユーザは自分が出したジョブがどこにあるのかをすばやく見つけることができます. ヘッダページの欠点は, 明らかに, すべてのジョブに対して, 紙が1枚余分に印字されるということです. この紙の有効期間は短く, 2〜3 分も続きません. 最終的に, これらの紙は再利用紙入れの中かくずの山に入れられることでしょう. (ヘッダページはジョブ中の各ファイル毎に印字されるのではなく, ジョブ毎に印字されるということに注意してください. したがって, 紙の消費はそれほどひどくはないかもしれません). もし, プリンタがプレインテキストを直接印字できるならば, LPD システムは印字物に対して自動的にヘッダページを付けることができます. PostScript プリンタを使っている場合は, ヘッダページを生成する外部プログラムが必要になります. これについては, 「PostScript プリンタでのヘッダページ」をご覧ください. ヘッダページの印字を許可する 「プリンタ設定導入編 」 では, /etc/printcap ファイルの sh (``suppress header'' : ヘッダを供給しないという意味) を指定して, ヘッダページの印字を止めていました. プリンタでのヘッダページの印字を許可するには, sh 項目を取り除くだけよい訳です. とても簡単そうに見えるけど, 本当かな? それは本当です. プリンタに初期化文字列を送るための 出力フィルタを用意しなくてはならないかもしれません. 次に, Hewlett Packard PCL 互換プリンタの例を挙げます. #!/bin/sh # # hpof - Output filter for Hewlett Packard PCL-compatible printers # Installed in /usr/local/libexec/hpof printf "\033&k2G" || exit 2 exec /usr/libexec/lpr/lpf of 項目に出力フィルタのパス名を指定してください. 詳細については, 「出力フィルタ」 をご覧ください. 次に, 以前紹介したプリンタ teak のための /etc/printcap ファイルの例を示します. ここでは, ヘッダページの印字を許可し, 上記の出力フィルタを追加しました. # # /etc/printcap for host orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif:\ :vf=/usr/local/libexec/hpvf:\ :of=/usr/local/libexec/hpof: さて, ユーザが teak からジョブを印字させたとき, それぞれのジョブ毎にヘッダページが印字されます. もし, ユーザが印字物を探すのに時間を費やしたいと思うなら, lpr -h によってジョブを入力することで, ヘッダページの印字を止めることができます. これ以外の &man.lpr.1; のオプションについては, 「 ヘッダページ用オプション」 をご覧ください. LPD では, ヘッダページの最後に, FORM FEED 文字が印 字されます. プリンタに紙排出をさせるために, 別な文字, もしくは, 別な文字列が利用されている場合は, /etc/printcap 中の ff 項目で指定することができます. ヘッダページを制御する ヘッダページの印字が許可されていると, LPD は 長いヘッ ダを作ります. これには, 紙全面に大きな文字でユーザ名, ホスト名, ジョブ名が書かれています. 次に, このヘッダページの例を示 します (kelly が ジョブ名 outline を rose というホストから印字 された場合). k ll ll k l l k l l k k eeee l l y y k k e e l l y y k k eeeeee l l y y kk k e l l y y k k e e l l y yy k k eeee lll lll yyy y y y y yyyy ll t l i t l oooo u u ttttt l ii n nnn eeee o o u u t l i nn n e e o o u u t l i n n eeeeee o o u u t l i n n e o o u uu t t l i n n e e oooo uuu u tt lll iii n n eeee r rrr oooo ssss eeee rr r o o s s e e r o o ss eeeeee r o o ss e r o o s s e e r oooo ssss eeee Job: outline Date: Sun Sep 17 11:04:58 1995 LPD はこのテキストの終わりに FROM FEED 文字を加えます ので, ジョブは新しいページから開始されます (ただし, /etc/printcap で出力先のプリンタのエントリに sf (suppress form feeds) が指定されているときはこ の限りではありません). お望みならば, LPD に短いヘッダページを出力させることもできます. この場合は, /etc/printcap ファイルの中で sb (short banner) を指定してください. ヘッダページは次のようになります. rose:kelly Job: outline Date: Sun Sep 17 11:07:51 1995 デフォルトでは, LPD はヘッダページを最初に印字し, 次にジョブの印字をおこないます. この順番を逆にするときは, /etc/printcap で hl (header last) を指定してください. ヘッダページに対する課金 LPD に備わっているヘッダページ出力機能を使うと, 入力されたジョブに対して課金をおこなうことができても, ヘッダページは無料で提供しなくてはならない, という特有のやり方を強要されます. なぜでしょうか. 出力フィルタは単なる外部プログラムなので, 課金をするための制御をおこなうとすれば, それはヘッダページを印字するときですが, 出力フィルタには, ユーザ名とホスト名 の情報や課金情報を格納するファイルがどれな のかということが知らされません. それゆえ, 出力ファイルには, 誰にプリンタ利用の課金をおこなえばよいのかが分からないのです. テキストフィルタやその他の変換フィルタ (これらのフィルタはユーザやホストの情報が知らされます) が出力ページの枚数に1ページ分水増しするだけでは十分ではありません. なぜなら, ユーザは lpr -h に よってヘッダページの出力を止めることができるからです. やみくもに 1 ページを水増しすると, 印字されてもいないヘッダページに対する 料金をとることになります. 基本的に, lpr -h は環境に優しい心を持つユーザに好まれるオプションですが, これを使うように奨励することもできません. 各々のフィルタに独自のヘッダページを生成させる (その結果, ヘッダページに課金することができる) という方法でも十分であるとはいえません. この場合, LPD はフィルタに の情報を送りませんので, lpr -h によってヘッダページを印字しないオプションを選択したとしても, 依然としてヘッダページは印字され, その分の課金がおこなわれてしまいます. では, どのような選択肢があるのでしょうか. ヘッダページへの課金に関しては, 次のことができます. LPD のやり方を受け入れ, ヘッダページは無料とする. LPRng などの LPD の代替品をインストールする. LPD と入れ替えが可能な他のスプーリングソフトウェアに関しては, 標準スプーラの代替品をご覧ください. スマートな 出力フィルタを作成する. 通常, 出力フィルタはプリンタを初期化するか, 単純な文字列変換をする程度の働きしかしません. (テキスト (入力) フィルタがない場合) 出力フィルタはヘッダページとプレインテキストの印字をおこなうのに適しています. プレインテキストを印字するためのテキストフィルタがない場合, LPD はヘッダページを印字するためだけの目的で出力フィルタを起動します. そして, LPD が生成するヘッダページのテキストを解析することにより, 出力フィルタはヘッダページに課金するために必要なユーザ名と ホスト名を取得することができます. この方式の唯一の問題点は, 出力フィルタは課金情報を格納するデータファイルの名前を知ることが できないということです (af 項目で指定されたファイル名は 出力ファイルに渡されません). しかし, 既知の 名前の課金データファイルを使うのならば, その名前を出力フィルタのプログラム中に埋め込むことができます. 解析の手順を簡単にするためには, /etc/printcap で sh 項目 (短いヘッダを指定) を使うとよいでしょう. そしてまた, ここまでの方法は少なからぬトラブルを生じさせるかもしれません. そうなれば, もちろんユーザはヘッダページを無料で 提供してくれる気前のよいシステム管理者に感謝することでしょう. PostScript プリンタでのヘッダページ これまでに述べたように, LPD ではプレインテキストのヘッダページを たくさんのプリンタに合うように生成することができます. 残念ながら, PostScript プリンタは, プレインテキストを直接印字することができません. ですから, LPD のヘッダページ機能はまったく役に立たない, あるいはほとんどの場合で役に立ちません. ヘッダページを出力するための自明な方法の1つに, すべての変換フィルタとテキストフィルタにヘッダページを生成させる方法があります. フィルタは, 適切なヘッダページを生成するために, ユーザ名とホスト名の引数を使うべきです. この方法の欠点は, いつでも, lpr -h によってジョブが入力された場合でさえも, ヘッダページが印字されるということです. この方法で試してみましょう. 次のスクリプトは, 3つの引数 (ユーザ のログイン名, ホスト名, ジョブ名) をとり, 簡単な PostScript 用 のヘッダページを生成します. #!/bin/sh # # make-ps-header - make a PostScript header page on stdout # Installed in /usr/local/libexec/make-ps-header # # # These are PostScript units (72 to the inch). Modify for A4 or # whatever size paper you are using: # page_width=612 page_height=792 border=72 # # Check arguments # if [ $# -ne 3 ]; then echo "Usage: `basename $0` <user> <host> <job>" 1>&2 exit 1 fi # # Save these, mostly for readability in the PostScript, below. # user=$1 host=$2 job=$3 date=`date` # # Send the PostScript code to stdout. # exec cat <<EOF %!PS % % Make sure we do not interfere with user's job that will follow % save % % Make a thick, unpleasant border around the edge of the paper. % $border $border moveto $page_width $border 2 mul sub 0 rlineto 0 $page_height $border 2 mul sub rlineto currentscreen 3 -1 roll pop 100 3 1 roll setscreen $border 2 mul $page_width sub 0 rlineto closepath 0.8 setgray 10 setlinewidth stroke 0 setgray % % Display user's login name, nice and large and prominent % /Helvetica-Bold findfont 64 scalefont setfont $page_width ($user) stringwidth pop sub 2 div $page_height 200 sub moveto ($user) show % % Now show the boring particulars % /Helvetica findfont 14 scalefont setfont /y 200 def [ (Job:) (Host:) (Date:) ] { 200 y moveto show /y y 18 sub def } forall /Helvetica-Bold findfont 14 scalefont setfont /y 200 def [ ($job) ($host) ($date) ] { 270 y moveto show /y y 18 sub def } forall % % That is it % restore showpage EOF そして, 変換フィルタやテキストフィルタがそれぞれ, 最初にこのスクリプトを起動することで, ヘッダページが出力され, それから, ユーザのジョブの印字をおこないます. 次に, このドキュメントの始めのほうで紹介した DVI 変換フィルタを, ヘッダページを印字するように変更したものを示します. #!/bin/sh # # psdf - DVI to PostScript printer filter # Installed in /usr/local/libexec/psdf # # Invoked by lpd when user runs lpr -d # orig_args="$@" fail() { echo "$@" 1>&2 exit 2 } while getopts "x:y:n:h:" option; do case $option in x|y) ;; # Ignore n) login=$OPTARG ;; h) host=$OPTARG ;; *) echo "LPD started `basename $0` wrong." 1>&2 exit 2 ;; esac done [ "$login" ] || fail "No login name" [ "$host" ] || fail "No host name" ( /usr/local/libexec/make-ps-header $login $host "DVI File" /usr/local/bin/dvips -f ) | eval /usr/local/libexec/lprps $orig_args このフィルタがユーザ名やホスト名を決定するために 引数リストをどのように解析しなくてはならないかという点に注意してください. この解析方法は他の変換フィルタに対しても同様です. しかしながら, テキストフィルタについては, 引数の設定が少し異なっています (これについては, 「 フィルタはどのように機能しているか」 をご覧ください). 前述の通り, 上記の手法は, 極めて単純なのにも関らず, lpr でヘッダページを印字しないオプション ( オプション) が使えなくなっています. ユーザが森林資源を (あるいは, ヘッダページが課金されているならば, その僅かな金額を), 節約したいと望んでいる場合でも, すべてのフィルタがすべてのジョブ毎にヘッダページを印字 することになっているので, 節約することはできません. ジョブ毎に印字されるヘッダページを ユーザが抑制できるようにするためには, 「 ヘッダページに対する課金」で紹介したトリックを 使う必要があります. すなわち, LPD が生成するヘッダページの解析をおこない, PostScript 版のヘッダページを出力させる出力フィルタを作るのです. この場合, ユーザが lpr -h でジョブを入力すると, LPD はヘッダページを生成しなくなり, また, 出力フィルタも起動されません. そうでないならば, 作成した出力フィルタが LPD からのテキストを読み込み, ヘッダページを印字する適当な PostScript のコードがプリンタに送られるでしょう. PostScript プリンタがシリアルポートに接続されている場合, 出力フィルタとして lprps を, 上記の動作をおこなうものとして psof を使うことができます. ただし, psof はヘッダページに対して課金をおこないませんので注意してください. リモートプリンタからの出力 プリンタ ネットワーク ネットワークプリンタ FreeBSD では, ネットワーク越しの印字, すなわち, ジョブをリモートプリンタに送ることをサポートしています. リモートプリンタからの出力をするには, 一般に, 次の2つを参照してください. リモートホストに接続されたプリンタにアクセスする方法. プリンタがあるホストのシリアル, または, パラレルインタフェースに接続されている場合, ネットワーク上の他のホストからこのプリンタにアクセスできるように LPD を設定します. 「リモートホストに 接続されたプリンタ」 でどのようにするかを説明します. ネットワークに直接接続されているプリンタにアクセスする方法. プリンタに, 旧来のシリアル, または, パラレルインタフェースに加えて (もしくは, これらに代わって) ネットワーク用のインタフェースがある場合. そのようなプリンタは次のように動作するでしょう. そのプリンタが LPD のプロトコルを理解でき, リモートホストからのジョブを キューに入れることさえできる場合. この場合, プリンタは, LPD が起動している一般のホストのように振る舞います. そのようなプリンタを設定するために, 「 リモートホストに接続されたプリンタ」 と同様の手順をおこなってください. そのプリンタが, データストリームによるネットワーク接続をサポートしている場合. この場合, ネットワーク上の1つのホストとしてプリンタを 接続します. このホストは, ジョブをスプーリングする責任を負い, スプーリングされたジョブはプリンタに送られます. そのようなプリンタをインストールするためのいくつかの提案が 「 ネットワークにおけるデータストリームの インタフェースを持つプリンタ」にあります. リモートホストに接続されたプリンタ LPD スプーリングシステムでは LPD (または LPD 互換のシステム) が起動している他のホストへジョブを送る機能が 始めからサポートされています. この機能により, あるホストに接続されたプリンタへ, 他のホストからアクセスできるようになります. また, LPD プロトコルを理解するネットワークインタフェースを持ったプリンタに対しても, この機能は働きます. リモートプリンタへの出力を許可するためには, 最初に, あるホスト (これを, プリンタホストと呼びます) にプリンタを接続します. そして, 「 プリンタ設定導入編」 に書かれた簡単なプリンタの設定をおこなってください. 必要ならば, 「プリンタ設定上級編」 にある, 更に進んだ設定をおこなってください. そして, そのプリンタをテストしてうまく動作することを確認し, LPD に許可した機能がうまく働くかどうかを見てください. さらに ローカルホストが プリンタホストの LPD サービスの使用を 許可されているか確認して下さい (「 リモートホストからのプリンタの利用を制限する 」参照). プリンタ ネットワーク ネットワークプリンタ LPD 互換のネットワークインタフェースを持つプリンタを使用している場合は, そのプリンタ自身が以下で説明する プリンタホストになります. そして, プリンタ名とは, そのプリンタに設定した名前のことを指します. これについては, プリンタ, および (または), プリンタのネットワークインタフェースに付属するドキュメントを参照してください. ヒューレット・パッカード社の Laserjet シリーズを使用している場合には, プリンタ名を text とすると, 自動的に LF から CRLF への変換が行なわれます. そのため, hpif スクリプトは必要ありません. 次に, そのプリンタにアクセスしたいと思っている他ホストにおいて, そのホストの /etc/printcap ファイルに次にあげるエントリを作ります. 名前のエントリ. どんな名前でもよいのですが, 簡単のため, 多分, プリンタホストで設定されたプリンタ名や別名と同じものを使いたいと思うでしょう. lp 項目で指定されるデバイスは明示的に空にする (:lp=: とする). スプーリングディレクトリを作成し, sd 項目でその位置を指定する. LPD では, プリンタホストにジョブを送信するまでの間, このディレクトリにジョブを格納します. rm 項目でプリンタホストの名前を指定します. rp 項目で プリンタホストに接続したプリンタ名を指定します. これで終わりです. 変換フィルタやページの大きさやその他の事項を /etc/printcap に加える必要はありません. 次に, リモートホストに接続されたプリンタで印字するための設定例 を示します. ホスト rose には2台のプリンタ bamboo と rattan が接続されています. これらのプリンタをホスト orchid のユーザが使えるようにしましょう. 最初に orchid の /etc/printcap を示します (このファイルは, 「 ヘッダページの出力を許可する」 で参照することができます). このファイルには, 既に, プリンタ teak 用のエントリがありました. 以下では, これに, ホスト rose にある2台のプリンタ用のエントリが加えられています. # # /etc/printcap for host orchid - added (remote) printers on rose # # # teak is local; it is connected directly to orchid: # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: # # rattan is connected to rose; send jobs for rattan to rose: # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: # # bamboo is connected to rose as well: # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo: orchid で必要となる作業はスプーリングディレクトリを作ることだけです. &prompt.root; mkdir -p /var/spool/lpd/rattan /var/spool/lpd/bamboo &prompt.root; chmod 770 /var/spool/lpd/rattan /var/spool/lpd/bamboo &prompt.root; chown daemon:daemon /var/spool/lpd/rattan /var/spool/lpd/bamboo これで, orchid のユーザが rattan と bamboo で印字す ることができるようになりました. 例えば, orchid のユーザが次のように入力したとします. &prompt.user; lpr -P bamboo -d sushi-review.dvi すると, orchid の LPD システムは, ジョブをスプーリングディレクトリ /var/spool/lpd/bamboo にコピーし, これが DVI ファイルを印字するジョブであることを記録します. ホスト rose の bamboo 用のスプーリングディレクトリに十分な容量が確保でき次第, 両者の LPD は, ジョブのファイルを rose に転送します. このファイルは, そのすべてが印字されるまで, rose のキューに留まります. (bamboo は PostScript プリンタなので) DVI から PostScript への変換は rose でおこなわれます. ネットワークにおけるデータストリームの インタフェースを持つプリンタ プリンタのネットワークインタフェースカードは, 2種類に分類することができます. 1つはスプーラをエミュレートするもの (高価) で, もう 1 つはシリアルやパラレルポートを使うように プリンタにデータを送ることができるだけのもの (安価) です. この節では, 後者の使い方を説明します. 前者のプリンタは, 前節「 リモートホストに接続されたプリンタ」 の方法が適用できます. /etc/printcap ファイルでは, シリアルかパラレルのインタフェースのどちらを使うのか, そして, (シリアルインタフェースを使う場合) そのボーレートはいくらであるか, フロー制御は使うのか, タブのための遅延を加えるのか, 改行文字を変換するかなどの指定をおこなうことができます. しかし, TCP/IP や他のネットワークポートからデータを受け取るプリンタを 接続するための指定をおこなうことはでき ません. ネットワーク接続されたプリンタにデータを送るためには, テキストフィルタと変換フィルタから呼び出すことができる 通信プログラムを開発する必要があります. 以下に, そのようなプログラムの例を示します.スクリプト netprint では, 標準入力から印字データをすべて受け取り, ネットワーク接続されたプリンタにこれを送ります. netprint の最初の引数でプリンタのホスト名を, 2番目の引数で接続するポート番号を指定します. このプログラムでは単方向通信 (FreeBSD からプリンタ) のみをサポートしていることに注意してください. ネットワークプリンタの多くは双方向通信をサポートしていますので, その恩恵 (プリンタの状態を得たり, 課金をおこなうなど) にあずかりたいと思われるかもしれません. #!/usr/bin/perl # # netprint - Text filter for printer attached to network # Installed in /usr/local/libexec/netprint # $#ARGV eq 1 || die "Usage: $0 <printer-hostname> <port-number>"; $printer_host = $ARGV[0]; $printer_port = $ARGV[1]; require 'sys/socket.ph'; ($ignore, $ignore, $protocol) = getprotobyname('tcp'); ($ignore, $ignore, $ignore, $ignore, $address) = gethostbyname($printer_host); $sockaddr = pack('S n a4 x8', &AF_INET, $printer_port, $address); socket(PRINTER, &PF_INET, &SOCK_STREAM, $protocol) || die "Can't create TCP/IP stream socket: $!"; connect(PRINTER, $sockaddr) || die "Can't contact $printer_host: $!"; while (<STDIN>) { print PRINTER; } exit 0; このスクリプトは, 様々なフィルタが利用することができます. 仮に, Diablo 750-N ラインプリンタを持っており, これがネットワークに接続されているとしましょう. プリンタはポート番号 5100 にて印字するデータを受け取ります. プリンタのホスト名は scrivener とします. このとき, このプリンタのテキストフィルタは次のようになります. #!/bin/sh # # diablo-if-net - Text filter for Diablo printer `scrivener' listening # on port 5100. Installed in /usr/local/libexec/diablo-if-net # exec /usr/libexec/lpr/lpf "$@" | /usr/local/libexec/netprint scrivener 5100 プリンタの利用に制約を与える プリンタ 利用制限 本節では, プリンタの利用に制約を与えるための情報を記しています. LPD システムでは, プリンタ (ローカル, リモートのいずれに接続されていても) にアクセスできる人を制限する機能, 複数部のコピーの印字の可否を制御する機能, ジョブのサイズの最大値やプリンタキューに入る ジョブの最大個数を制御する機能を提供しています. 複数部のコピーの印字を制限する LPD システムではユーザが複数部のコピーの印字を簡単におこなう 機能を提供しています. ユーザが, (例えば) lpr -#5 コマンドを使ってジョブを印字すると, ジョブのそれぞれのファイルのコピーを5部得ることができます. これがよい機能であると思うかどうかは人それぞれでしょう. 複数部のコピーの印字によってプリンタが 必要以上に消耗してしまうと感じるならば, /etc/printcap ファイルに sc 項目を加えてください. これにより, &man.lpr.1; の オプションの使用が禁止されます. このオプションが指定されているにも関らず, オプションを使うと, 次のようなメッセージが表示され, このオプションの利用できない旨を伝えます. lpr: multiple copies are not allowed リモートホストからプリンタをアクセスできる 設定にしている場合 (この 設定については, 「 リモートホストに接続されたプリンタ」 をご覧ください), そのリモートホストの /etc/printcap にも同じように sc 項目を追加する必要があることに注意してください. そうしないと, ユーザは別なホストから複数部のコピーの 印字することができてしまいます. 例を使って説明しましょう. 次に示す /etc/printcap ファイルは, ホスト rose のものです. プリンタ rattan は極めて頑丈なので, 複数部のコピーの印字は許可されています. しかし, レーザプリンタの bamboo はもう少しデリケートで, このプリンタから複数部のコピーを印字することを sc 項目を追加することで禁止しています. # # /etc/printcap for host rose - restrict multiple copies on bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: さらに, orchid の /etc/printcap にも sc 項目を追加する必要があります (orchid でこの編集をおこなっているときに, ついでに, プリンタ teak でも複数部のコピーの印字を禁止することにしましょう). # # /etc/printcap for host orchid - no multiple copies for local # printer teak or remote printer bamboo teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:sc:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: rattan|line|diablo|lp|Diablo 630 Line Printer:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo:sc: sc 項目を指定することにより, lpr -# の使用を防ぐことができます. しかし, この状態では &man.lpr.1; を複数回起動したり, 1回のジョブで次のように同じファイルを複数個指定することを防ぐまでには至っていません. &prompt.user; lpr forsale.sign forsale.sign forsale.sign forsale.sign forsale.sign このような悪用を防ぐ方法は (その指示を無視することも含めて) たくさんあります. 各自で調べてみてください. プリンタを使用できる人を限定する それぞれのプリンタを使用できる人を限定するには, Unix の グループ権限のメカニズムを利用し, さらに, /etc/printcap で rg 項目を指定することでおこないます. あるプリンタにアクセスさせてもよいと思うユーザすべてを Unix のあるグループに入れてください. そして, そのグループ名を rg で指定します. このとき, そのグループに含まれないユーザ (root も含む) には, 次のようなメッセージが表示され, プリンタの使用はできません. lpr: Not a member of the restricted group sc (suppress multiple copies : 複数部のコピーの印字を禁止する) を指定するときと同様に, rg が指定されたプリンタがリモートホストからもアクセスでき (この設定については, 「 リモートホストに接続されたプリンタ」 をご覧ください), かつ, そのホストでもプリンタを使用できる人を限定するのが 妥当であると思う場合は, そのホストの /etc/printcap にも rg 指定をおこなう必要があります. 例えば, プリンタ rattan は誰でも利用できるが, bamboo はグループ artists に属している人のみが利用できるようにしてみましょう. 以下に, もうお馴染みとなったホスト rose の /etc/printcap を示します. # # /etc/printcap for host rose - restricted group for bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: これ以外の /etc/printcap ファイル (ホスト orchid のもの) はそのままにしておくことにします. もちろん, orchid のユーザは全員 bamboo を利用することができます. これは, orchid には特定のユーザのみにしかアクセスさせておらず, そのユーザにはプリンタを利用させたいと思っているからなのかもしれませんし, そうでないかもしれません. 1台のプリンタを複数グループのユーザに利用させることはできません. 入力可能なジョブのサイズを制限する プリントジョブ たくさんのユーザからプリンタが利用される場合には, 多分, ユーザが印字要求を出すことができるファイルのサイズに 上限値を置く必要が生じるでしょう. 結局のところ, スプーリングディレクトリ が置かれているファイルシステムの空き容量がその 上限値になる訳ですが, あるユーザがこれを独占的に使用すること避けるために, 他ユーザからのジョブ用の空き容量を確保する必要もあります. プリントジョブ 制御 LPD では, mx 項目を指定することにより, ジョブ中の個々のファイルのサイズの上限値を制限する機能を提供しています. 指定される ファイルサイズの単位は BUFSIZ ブロックで, 1 BUFSIZ ブロックは 1024バイトを表わします. この mx 項目の値として 0 が指定されると, ファイルサイズの制限はなくなります. mx が指定されない場合は, デフォルトの制限として 1000 ブロックが使われます. この制限はジョブ中の各 ファイルに対して適用されるものであり, ジョブ全体のサイズ を制限するものではありません. ところで, プリンタに設定された上限値を超えるファイルサイズの ファイルが入力された場合でも, LPD はこれを拒否しません. その代わりに, このファイルは, その先頭から上限値のファイルサイズまでしかキューに入れられません. そして, その部分までが印字され, 残りの部分は捨てられます. これが正しい動作といえるのかどうかは議論の余地があるところです. それでは, 設定例に登場しているプリンタ rattan と bamboo の印字可能なファイルサイズに制限を加えてみましょう. artists グループの人達が作る PostScript ファイルのサイズは 巨大になる傾向があるので, 上限値を5Mバイトとします. それから, プレインテキスト用のラインプリンタは無制限とします. # # /etc/printcap for host rose # # # No limit on job size: # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:mx#0:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: # # Limit of five megabytes: # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: この場合もそうですが, この制限はローカル (ホスト rose) のユーザのみに適用されます. リモートホストからプリンタを利用できるように設定している場合は, そのリモートホストのユーザはこの制限を受けません. これらのユーザにも制限を加える場合は, リモートホストの /etc/printcap の mx を指定する必要があります. リモートホストから印字するための詳しい情報については, 「 リモートホストに接続されたプリンタ」 を参照してください. リモートホストに接続されたプリンタへのジョブの サイズを制限する特別な方法は他にもあります. これについては, 「 リモートホストからのプリンタの利用を制限する」 を参照してください. リモートホストからのプリンタの利用を制限する LPD スプーリングシステムでは, リモートホストから要求された ジョブの印字を制限するための方法がいくつか提供されています. ホストの制限 ローカルの LPD が印字要求を受け付けるリモートホストは, ファイル /etc/hosts.equiv と /etc/hosts.lpd によって制御することができます. LPD では, あるホストから印字の要求がきたとき, このホストの名前がこれら2つのファイルのどちらかに含まれている かどうかを調べます. これが含まれていない場合は, LPD はこの要求を拒否します. これらのファイルの形式は単純です. 各行にホストの名前を 1つずつ書いていきます. ファイル /etc/hosts.equiv の方は &man.ruserok.3; プロトコルでも利用され, &man.rsh.1; や &man.rcp.1; といったプログラムの動作に影響するので注意が必要です. /etc/hosts.equiv の記述は慎重におこないましょう. 例として, 以下にホスト rose の /etc/hosts.lpd を示します. orchid violet madrigal.fishbaum.de この例では, rose はホスト orchid, violet, そして madrigal.fishbaum.de からの要求を受け付けることになります. その他のホストが rose の LPD にアクセスしようと しても, LPD はそのジョブを拒否します (訳注: 拒否されるのは, そのホストが /etc/hosts.equiv にも含まれていない場合です). サイズの制限 スプーリングディレクトリがある ファイルシステムに残しておく必要がある 空き容量の大きさを制御することができます. ローカルプリンタ用のスプーリングディレクトリに minfree という名前のファイルを作成します. そして, そのファイルの中にリモートホストからのジョブの 要求を受け付けるために必要な空き容量のディスクブロックサイズ (1 ディスクブロック =512 バイト) を記します. これで, リモートホストのユーザにファイルシステムを満杯にされないことが保証されます. この機能を使うと, ローカルホストのユーザに対してある種の優先権を与えることもできます. ローカルホストのユーザは, minfree ファイルで指定された値よりもディスクの空き容量が下回った後でもずっと, ジョブをキューに入れることができるのです. 例えば, プリンタ bamboo 用の minfree を作ってみましょう. このプリンタのスプーリングディレクトリを調べるために, /etc/printcap を調べてみましょう. 以下に, bamboo のエントリ部分を示します. bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:mx#5000:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: スプーリングディレクトリは sd で指定されます. LPD がリモートホストからのジョブを受け付けるために必要な ファイルシステムの空き容量を 3M バイト (=6144 ディスクブロック) にすることにしましょう. &prompt.root; echo 6144 > /var/spool/lpd/bamboo/minfree 利用ユーザの制限 /etc/printcap の rs 項目を指定することで, ローカルプリンタを利用できるリモートホストのユーザを 制限することができます. ローカルホストに接続されたプリンタ用のエントリに rs 項目が指定されている場合, LPD は印字を要求したユーザのアカウントと同じログイン名が ローカルホストに登録されている場合に限り, そのジョブが受け付けられます. そうでないユーザからのジョブは LPD は拒否します. この機能は, (例えば) 複数の部署がネットワークを共有しており, この内のあるユーザが部署の境界を越えて活動している場合には特に有用です. そのようなユーザに対して, システムのアカウントを与えるだけで, これらのユーザは自分が所属する部署のシステムから そのシステムに接続されているプリンタを使用することができます. これらのユーザにはむしろ, プリンタの使用だけを認め, その他のコンピュータ資源を利用させたくないときは, それらのユーザにはホームディレクトリを与えず, ログインシェルはシェルとしては何の役にも立たない /usr/bin/false などを指定して, これらのユーザのアカウントはプリンタ用の形式的なものとします. プリンタの利用に対する課金 課金 プリンタ という訳で, 印字するためには料金をとることが必要です. 取らない理由などありましょうか. 紙やインクにはお金がかかります. そして, プリンタの維持費もかかります. プリンタには可動部分が搭載されており, これらの部分は壊れやすいという傾向があります. プリンタや, その利用形態, 維持費について調査をし, 1 ページ (1 フィート, 1 メートルなど) 当たりにかかるコストを調べておいてください. これに基づき, プリンタの利用に対する課金を, 実際に, どのように始めればよいのでしょうか. さて, 残念ながら, この部分に関しては LPD スプーリングシステムはほとんど役に立ちません. 課金は使用しているプリンタの種類, 印字するもののファイルの形式, プリンタの利用に対する課金での あなた自身の要求に大きく左右されます. 課金システムを実現するためには, プリンタのテキストフィルタ (プレインテキストのジョブに対して課金するため) と変換フィルタ (その他のファイル形式に対して課金するため) を変更して, 印字したページを数えたり, プリンタに印字したページ数を取得するための要求を送る必要があります. ただし, 出力フィルタのみを利用している場合は, 課金をおこなうことができません. フィルタに関しては, 「 フィルタ」をご覧ください. 一般に, 課金方式には次の2つがあります. 定期的に課金する方法 はよく利用される方法です. この理由は, 恐らく比較的簡単に実現できるからです. 誰かがジョブを印字する度に, フィルタはそのユーザ名, ホスト名, 印字したページ数を課金データファイルに記録します. 毎月, 毎学期, 毎年, その他お好みの時期に, 各プリンタの課金用ファイルを集め, それぞれのユーザが印字したページ数を合計して その分の課金をおこないます. 次回の課金期間をデータを 0 にして課金を再開するために, すべてのログファイルを削除します. 利用毎に課金する方法 はあまり利用されていません. これは, 実現するのが比較的難しいからです. この方式では, プリンタを使用したらすぐに, フィルタがユーザにその利用に対する課金をおこないます. ディスククオータのように, 課金作業は瞬時におこなわれます. この方式では, ユーザのアカウントが赤字になる場合に, ユーザが印字をおこなうことを拒否することができます. また, ユーザにプリンタ版 quotaを調べたり, 調整したりする方法を提供したいと思うかもしれ ません. これを実現するためには, ユーザとその quota を追跡するために, あるデータベース用のコードが必要となります. LPD スプーリングシステムでは, 両方式を簡単にですがサポートしています. これは, (ほとんどの場合で) 印字作業をフィルタがおこなっていたように, 課金作業もこのためのコードも用意することで実現されています. しかし, 明るい面もあります. それは, 課金方式に関して, 非常に大きな柔軟性が与えられたということです. 例えば, 「定期的に課金する方法」か, 「利用毎に課金する方法」のどちらかを選びまず, そして, どんな情報 (ユーザ名, ホスト名, ジョブのタイプ, 印字された頁数, 使用した紙の大きさ, 印字をするために要した時間など) をログに記録するかを決めます. 以上のことをおこなうには, 上記の情報を保持するために, フィルタを変更しなくてはなりません. 手軽なプリンタ課金方法 FreeBSD には, 「定期的に課金する方法」による課金を すぐに設定できるように, 2個のプログラムを添付しています. その内の1つはテキストフィルタ lpf で, これについては, 「 テキストフィルタ lpf」をご覧ください. もう1つは, &man.pac.8; で, これはプリンタの課金データファイルからのエントリを集め, これを合計するプログラムです. 「 フィルタはどのように機能しているか」で述べたように, LPD ではテキストフィルタや変換フィルタを起動しますが, そのコマンドラインで使用している課金データファイルの名前が指定されます. 両フィルタはこの引数を使って, どの課金データファイルのエントリに書き込めばよいのかを知ることができます. このファイルの名前は /etc/printcap 中の af 項目によって指定されます. このファイルが絶対パ スで指定されない場合は, スプーリングディレクトリからの相対パスとして扱われます. LPD は, 紙のページの幅と行数 (pw と pl 項目で 指定される) を引数として lpf を起動します. lpf では, 何ページ印字したかを決定するためにこれらの引数を使用します. ファイルをプリンタに送った後, 課金情報を課金データファイルに書き込みます. このファイルは次のようになります. 2.00 rose:andy 3.00 rose:kelly 3.00 orchid:mary 5.00 orchid:mary 2.00 orchid:zhang 課金データファイルはプリンタ毎に分けて作るべきです. これは, lpf にはデータファイルをロックする機構が組み込まれていないためです. したがって, lpf が2つ起動されたとき, 同じファイルに同時に書き込みをおこなった場合, お互いのエントリが破壊されてしまうかもしれません. 課金用ファイルを各プリンタ毎に確実に分けるには, /etc/printcap 中の af=acct 項目を使います. プリンタの利用に対してユーザに課金する準備ができたら, スプーリングディレクトリに移動した後, &man.pac.8; と入力してください. 次のような, ドル中心主義の課金リストが表示されます (訳注: ドル中心主義という表現は, 表示がドルで出ることへの著者の皮肉でしょう. セントがあるので小数点以下が表示されますが, この機能も日本では邪魔ですね). Login pages/feet runs price orchid:kelly 5.00 1 $ 0.10 orchid:mary 31.00 3 $ 0.62 orchid:zhang 9.00 1 $ 0.18 rose:andy 2.00 1 $ 0.04 rose:kelly 177.00 104 $ 3.54 rose:mary 87.00 32 $ 1.74 rose:root 26.00 12 $ 0.52 total 337.00 154 $ 6.74 &man.pac.8; が受け付ける引数には次のようなものがあります. プリンタ printer の利用に対する課金リストを作成します. このオプションは, /etc/printcap の af が絶対パスで指定されていた場合に限り, 動作します. ユーザ名のアルファベット順ではなく, 課金額の低い順にリストを並べます. 課金データファイルにあるホスト名を無視します. このオプションを使用すると, ホスト alpha のユーザ smith とホスト gamma のユーザ smith は同一人物として扱われます. このオプションが指定されない場合は, 両者は別なユーザとして扱います. /etc/printcap の pc 項目で指定された値, または, デフォルトの値 (2セント) に代わり, 紙1ページ, または, 1フィート当たりの価格を指定します. price として, 浮動小数点数を指定することができます. リストの並べる順番を逆順にします. 課金リストを作成し, 課金データファイルを削除します. name … ユーザ names に対する課金情報のみを表示します. &man.pac.8; が生成するデフォルトのリストには, 各ホストのユーザ別に印字ページ数が表示されます. (ユーザがサイト内のすべてのホストを使用できるため) ホスト名の情報が意味を持たない場合, pac -m を実行してください. 次のようなリストが得られます. Login pages/feet runs price andy 2.00 1 $ 0.04 kelly 182.00 105 $ 3.64 mary 118.00 35 $ 2.36 root 26.00 12 $ 0.52 zhang 9.00 1 $ 0.18 total 337.00 154 $ 6.74 課金額を決めるために, &man.pac.8; は /etc/printcap ファイルの pc 項目で指定された値 (デフォルト値は 200, すなわち1 ページ当たり2セント) を使います. この項目で,印字物に課金したい ファと思う 1 ページ当たり, または, 1 フィート当たりの価格を100分の1セント単位で指定します. &man.pac.8; を オプション付きで起動すると, この値を置き換えることができます. この オプションで指定する額の単位は, 100 分の 1 セント単位ではなく, ドル単位です. 例えば, 次の指定では, 1 ページ当たりの単価が 1 ドル 50 セントになります. &prompt.root; pac -p1.50 このオプションを使うと, 実際の課金額を集計することができます. 最後に, pac -s を起動すると, 課金情報は課金データ累計ファイルに保存されます. このファイルの名前は, プリンタの課金データファイルの後ろに _sum を付けたものとなります. そして, 課金データファイルは削除されます. 次に &man.pac.8; が起動されると, その時点までの累計金額を得るために, 課金データ累計ファイルが読み込まれ, 通常の課金データファイルからの情報に加算されます. 印字されたページ数をどのように数えるか? 課金を, リモートホストからの印字でさえも, 正確におこなうためには, ジョブで使用された紙が何ページであるかを特定できる必要があります. このことは, プリンタ利用に対する課金をおこなう上の根本的な問題です. プレインテキストのジョブの場合, 問題を解決するのはさほど難しくはありません. ジョブが何行であったかを数え, プリンタがサポートしている紙 1 ページに印字できる最大の行数と比較すればよいのです. 重ね打ちするために利用されるファイル中のバックスペース文字や, 物理的に複数の行に渡る長い論理行に対する取り扱いを忘れずにおこなってください. (「テキストフィルタ lpf」で紹介した) テキストフィルタ lpf では, 課金をおこなうときに, これらの取り扱いをおこなってくれます. 課金をおこなうために必要なテキストフィルタを作成している方は, lpf のソースコードが参考になるでしょう. これに対して, 他のファイル形式の処理はどのようにすれば よいのでしょうか. まず, DVI から LaserJet, または, DVI から PostScript への変換の場合, フィルタが dvilj や dvips の 出力メッセージを解析することで, 何ページ分の変換がおこなわれたかを知ることができます. 他のファイル形式とその変換プログラムに関しても, 同様のことができるかもしれません. しかし, この方式には問題点があります. それは, 変換されたページがすべて印字されるとは限らないということです. 例えば, プリンタが紙詰まりを起こしたり, トナー切れになったり, はたまた, 爆発したりするかもしれません. そのような状況により印字が途中で中止されたとしても, この方式では, ユーザは全ページ分の料金を課されてしまうのです. それでは, どのような対策をたてることができるのでしょうか. 正確な 課金をおこなうための唯一の確実な方法は, 何ページ印字したのかを知らせることができるプリンタを入手し, これをシリアルポートかネットワークに接続することです. ほとんどすべての PostScript プリンタではこの概念がサポートされています. 他のプリンタも同様です (Imagen レーザプリンタをネットワーク接続するなど). それぞれのプリンタのフィルタを, ジョブを印字した後で印字ページ数を得るように変更してください. そして, 課金情報はここで得られた値のみに 基づいて記録してください. 行数を数えたり, エラーが生じやすいファイルの調査は必要とされません. もちろん, 気前よく印字料金をすべて無料にすることもできます. プリンタを使う プリンタ 使い方 この節では, FreeBSD で設定したプリンタを使う方法について説明します. ここでは, ユーザレベルでのコマンドを概説します. &man.lpr.1; 印字をおこないます. &man.lpq.1; プリンタキューを調べます. &man.lprm.1; プリンタキューにあるジョブを削除します. 管理者用コマンド &man.lpc.8; もありますが, これは「プリンタを管理する」 に記します. このコマンドは, プリンタやそのキューの制御のために用いられます. &man.lpr.1;, &man.lprm.1;, そして &man.lpq.1; の 3 コマンドは, オプションをとり, これによって, /etc/printcap のように操作の対象となる プリンタやキューを指定します. これによって, 様々なプリンタに対してジョブを送る, 取り消す, 調査することができます. が使われなかった場合は, これらのコマンドは PRINTER 環境変数で指定されたプリンタを使用します. そして, PRINTER 環境変数がなかった場合は, これらのコマンドはデフォルトのプリンタ lp を使います. 以下では, デフォルトプリンタ という用語が意味するプリンタは, PRINTER 環境変数で指定されたプリンタ, もしくは, PRINTER 環境変数がない場合は, lp という名前のプリンタです. 印字する ファイルを印字するためには, 次のように入力してください. &prompt.user; lpr filename ... 印刷 これにより, 入力されたファイルのそれぞれをデフォルトのプリンタ から印字します. ファイル名が与えられなかった場合, &man.lpr.1; は標準入力から印字するデータを読み込みます. 例えば, 次のコマンドにより, ある重要なシステムファイルが印字されます. &prompt.user; lpr /etc/host.conf /etc/hosts.equiv 印字させるプリンタを選択するためには, 次のように入力します. &prompt.user; lpr -P printer-name filename ... 次の例では, プリンタ rattan に, カレントディレクトリにあるファイルの詳細なリストを印字しています. &prompt.user; ls -l | lpr -P rattan 上記の &man.lpr.1; コマンドではファイル名の指定がないので, lpr は標準入力から印字するデータ, この場合, ls -l コマンドの出力, を読み込みます. &man.lpr.1; コマンドでは, 出力の整形を制御したり, ファイル変換を適用したり, 複数部数のコピーを作成したり, などといた様々な幅広いオプションを受け付けることもできます. 詳細については, 「 その他の印字オプション」をご覧ください. ジョブの処理状況を調べる プリントジョブ &man.lpr.1; コマンドを使って印字をする場合, プリントしようと するデータはプリントジョブと呼ばれる箱に一緒に置かれ, これが LPD スプーリングシステムに送られます. プリンタにはそれぞれジョブ用のキューがあり, 送られてきたジョブはあなたや他のユーザからの別のジョブと一緒にそのキューで並んで, 処理される順番を待ちます. プリンタは到着順にこれらのジョブの印字をおこないます. デフォルトプリンタのキューの状態を表示するには, &man.lpq.1; と入力します. プリンタを指定するときは, オプションを使います. 例えば, 次のコマンド &prompt.user; lpq -P bamboo は, プリンタ bamboo のキューの状態を表示します. この lpq コマンドの出力結果の例を次に示します. bamboo is ready and printing Rank Owner Job Files Total Size active kelly 9 /etc/host.conf, /etc/hosts.equiv 88 bytes 2nd kelly 10 (standard input) 1635 bytes 3rd mary 11 ... 78519 bytes この例では, bamboo のキューに3つのジョブがあることが分かります. 最初のジョブはユーザ kelly からのものであり, ジョブ番号 9 が割り当てられています. プリンタのすべてのジョブには一意なジョブ番号が付けられています. ほとんどの場合, このジョブ番号は無視することができますが, ジョブをキャンセルするときにはこの番号が必要になります. このことの詳細については, 「ジョブの削除 」をご覧ください. ジョブ番号9のジョブは2つのファイルを処理します. すなわち, &man.lpr.1; のコマンドラインに複数のファイル名が与えられたときは, 1つのジョブとして扱われるのです. このジョブは, 現在, アクティブジョブ (Rank の欄の active という後に注目) になっています. これは, プリンタからそのジョブが現在印字されているはずであることを意味しています. 2 番目のジョブでは, &man.lpr.1; コマンドに標準入力からデータが与えられています. 3番目のジョブはユーザ mary から与えられました. このジョブのサイズはとても大きくなっています. 彼女がプリントしようとしたファイルのパス名はここで表示させるには長すぎるため, &man.lpq.1; コマンドはドットを3つだけ表示しています. &man.lpq.1; からの出力で一番最初の行もまた有益な情報を与えています. この行から, プリンタが現在何をしているか (あるいは, 少なくとも LPD がプリンタがしていると思っていること) が分かります. &man.lpq.1; コマンドは オプションもサポートしています. これにより, 詳しい情報が表示されます. lpq -l の実行例を次に示します. waiting for bamboo to become ready (offline ?) kelly: 1st [job 009rose] /etc/host.conf 73 bytes /etc/hosts.equiv 15 bytes kelly: 2nd [job 010rose] (standard input) 1635 bytes mary: 3rd [job 011rose] /home/orchid/mary/research/venus/alpha-regio/mapping 78519 bytes ジョブの削除 印字するようジョブを 送った後で印字を中断したくなったときは, &man.lprm.1; コマンドで, キューの中からそのジョブを削除することができます. 大抵の場合, アクティブジョブでさえも &man.lprm.1; を使って削除することができますが, そのジョブの一部またはすべてが印字されてしまうかもしれません. デフォルトプリンタへのジョブを削除するためには, 最初に, &man.lpq.1; を使ってそのジョブ番号を調べます. すなわち, それから, 次のように入力して, ジョブを削除します. &prompt.user; lprm job-number 特定のプリンタへのジョブを削除するときは, オプションを使ってそのプリンタを指定します. 例えば, プリンタ bamboo のキューからジョブ番号 10 のジョブを削除するには次のようにします. &prompt.user; lprm -P bamboo 10 &man.lprm.1; コマンドには略記法がいくつかあります. lprm - あなたが (デフォルトプリンタへ) 送ったジョブをすべて削除します. lprm user ユーザ user が (デフォルトプリンタへ) 送ったジョブをすべて削除します. 他のユーザのジョブを削除できるのはスーパユーザだけです. あなたは, あなた自身のジョブしか削除することはできません. lprm ジョブ番号もユーザ名もシンボル も指定されないときは, &man.lprm.1; は現在のアクティブジョブを, そのジョブを送ったのがあなた自身であるときに限り, デフォルトプリンタから削除します. ただし, スーパユーザは任意のアクティブジョブを削除することができます. 上記の略記法をデフォルトプリンタではなく 特定のプリンタに対しておこなうときは, オプションでそのプリンタを指定するだけよ いのです. 例えば, プリンタ rattan のキューへあなたが送ったジョブを すべて削除するためには次のようにします. &prompt.user; lprm -P rattan - ネットワーク環境で作業をしている場合, あるホストから送られたプリンタジョブは, これを送ったホストで &man.lprm.1; を使った場合に限って, これを削除することができます. 他のホストで同じプリンタを使えたとしても, このジョブを削除することはできません. 次の例では, 他ホストからジョブを削除することを試みています. &prompt.user; lpr -P rattan myfile &prompt.user; rlogin orchid &prompt.user; lpq -P rattan Rank Owner Job Files Total Size active seeyan 12 ... 49123 bytes 2nd kelly 13 myfile 12 bytes &prompt.user; lprm -P rattan 13 rose: Permission denied &prompt.user; logout &prompt.user; lprm -P rattan 13 dfA013rose dequeued cfA013rose dequeued その他の印字オプション &man.lpr.1; コマンドには, テキストの整形や, 図や他のファイル形式の変換, 複数部コピーの生成, ジョブの扱いなどをを制御することができます. この節では, これに関するオプションについて記しています. 整形と変換に関するオプション 以下の &man.lpr.1; 用のオプションはジョブにおける ファイルの整形の制御に関するものです. このオプションは, ジョブにプレインテキストが含まれない場合や &man.pr.1; ユーティリティを使ってプレインテキストを整形する場合に用いてください. TeX 次の例では, プリンタ bamboo に (TeX 組版システムによる) DVI ファイル fish-report.dvi を印字しています. &prompt.user; lpr -P bamboo -d fish-report.dvi このオプションは, ジョブに含まれるすべてのファイルに対して適用されます. したがって, 1つのジョブに (例えば) DVI ファイルと ditroff ファイルを混在させることはできません. その代わりに, ファイルを形式毎に別々のジョブに分け, それぞれのジョブでその形式用の変換オプションを使って印字してください. と を除くすべてのオプションを使用 するためには, 出力先プリンタ用の変換フィルタが必要です. 例えば, オプションを使用するには, DVI 用の変換フィルタが必要 です. 詳細については, 「 変換フィルタ」で説明しています. cifplot ファイルを印字します. DVI ファイルを印字します. FORTRAN プログラムを印字します. plot のデータを印字します. 出力に対して, number カラム分の字下げをおこないます. number が省略されると, 8カラム分字下げされます. このオプションはある変換フィルタと一緒の指定されたときのみに機能します. と数字の間に空白を入れてはいけません. 制御文字を含む文字通りのテキストデータを印字します. ditroff (device independent troff) データを印字します. -p 印字する前に &man.pr.1; によってプレインテキストを整形します. 詳細については &man.pr.1; をご覧ください. &man.pr.1; コマンドにより生成されるヘッダを, ファイル名の代わりに title とする. このオプションは, と一緒に使ったときのみ機能する. troff データを印字します. ラスタのデータを印字します. 次の例では, &man.ls.1; のマニュアルを美しく整形したものをデフォルトプリンタで印字しています. &prompt.user; zcat /usr/share/man/man1/ls.1.gz | troff -t -man | lpr -t &man.zcat.1; コマンドで &man.ls.1; のマニュアルのソースファイルの圧縮を復元し, これを &man.troff.1; コマンドに渡しています. これによりソースファイルが整形され GNU troff の形式となります. その結果は &man.lpr.1; に渡され, LPD スプーラへジョブの要求が発せられます. &man.lpr.1; には オプションが使われているため, スプーラでジョブを印字したときに GNU troff の形式から, デフォルトプリンタ解釈できる形式へと変換されます. ジョブに関するオプション 以下のオプションは, &man.lpr.1; によって, そのジョブを特殊な扱いにするよう LPD に指示するためのものである. -# copies ジョブに含まれるファイルのそれぞれを 1部だけ印字するのではなく, copies 部のコピーを生成させるものです. 管理者によっては, プリンタの消耗を避け, コピー機による複製を奨励するために このオプションの使用が禁止されているかもしれません. これに関しては, 「 複数部のコピーの印字を制限する 」をご覧ください. 次の例では, デフォルトプリンタで parser.c を3 部コピーし, 次に, parser.h を3部コピーしています. &prompt.user; lpr -#3 parser.c parser.h -m 印字ジョブが完了した後で, メールを送ります. このオプショ ンを付けると, LPD システムはジョブの扱いが終了したときに, あなたのアカウントにメールを送ります. メールのメッセージには, ジョブが正常終了したのか, あるいは, 何か異常があり, (しばしば) その異常が何であったのかが書かれています. -s 印字ファイルをスプールディレクトリにコピーせず, 代わりに, シンボリックリンクを作成するよう指示します. 印字させるジョブのサイズが大きいとき, このオプションを使うと便利かもしれません. このオプションにより, スプー ルディレクトリの容量が節約されます (それに, 巨大なジョブのお陰でスプールディレクトリのあるファイルシステムの空き容量がなくなってしまうかもしれません). さらに, LPD がいちいちすべてのデータをコピーする必要がなくなりますので, 時間の節約にもなります. ただし, 欠点もあります. LPD はオリジナルのファイルを直接参照するので, 印字が終了するまでそのファイルを変更したり削除することができません. リモートのプリンタで印字している場合, LPD は, 結局のところ, ローカルホストからリモートホストにファイルをコピーする必要があります. したがって, オプションはローカルのスプーリングディレクトリの空き容量を節約するだけで, リモート側では節約されません. それにも関わらず, このオプションはそれでも有用です. -r ジョブに含まれるファイルを, スプーリングディレクトリに ファイルをコピーした後に削除します. もしくは, オプションと一緒に使われた場合は, 印字終了後に削除されます. このオプションの使用には十分注意して下さい. ヘッダページ用オプション 以下のオプションにより, ジョブのヘッダページに通常印字さ れるテキストを &man.lpr.1; に調整させることができます. 対象のプリンタからヘッダページが出力されない場合は, これらのオプションは何の効力も持ちません. ヘッダページの設定に関する情報については, 「 ヘッダページ」を参照してください. -C text ヘッダページに印字されるホスト名を text に置き換えます. なお, ホスト名の場所には, 通常, ジョブの要求があったホストの名前が印字されます. -J text ヘッダページに印字されるジョブ名を text に置き換えます. ジョブ名の場所には, 通常, ジョブの最初のファイル名, または, 標準入力からデータが印字されたときは stdin が印字されます. -h ヘッダページを出力を禁止します. サイトによっては, そのヘッダページの生成方法により, このオプションの効果が現れないかもしれません. 詳細は, 「 ヘッダページ」をご覧ください. プリンタを管理する プリンタの管理者として, プリンタの設置, 設定, そして, それらのテストをおこなう必要がありました. &man.lpc.8; コマンドにより, これまでとは別な管理方法がプリンタと対話的におこなわれます. &man.lpc.8; により, 次のことが可能となります. プリンタの起動, 停止をおこなう. キューへの入力の許可, 禁止をおこなう. それぞれのキューにあるジョブの順番を変更する. 最初に用語に関する注意をしておきます. プリンタが停止しているとは, キューの中にあるどのジョブも印字されることがない状態 を言います. この状態においても, ユーザはまだジョブの要求をおこなうことができますが, これらのジョブはキューの中で, プリンタがスタートする状態になるまで, あるいは, キューの内容が削除されるまで待たされることになります. キューが禁止状態にあるとは, (root 以外の) すべてのユーザが プリンタにジョブを要求することができない状態のことを言います. キューが許可状態にある場合は, ジョブの入力が許可されます. キューが禁止状態にある場合でも, プリンタをスタートす る状態にすることは可能です. この場合は, キューが空になるまで, キュー内のジョブの印字が続けられます. 一般的に, &man.lpc.8; コマンドを使用するには root の権限を持っている必要があります. 一般のユーザも &man.lpc.8; コマンドを使うことはできますが, プリンタの状態を取得することとハングしたプリンタ を再スタートすることだけに使用が制限されています. 以下に, &man.lpc.8; コマンドに関する説明の要約を述べます. ほとんどのコマンドでは, 操作対象となるプリンタを指定するため printer-name 引数を与えます. printer-name の代わりに all が与えられると, 操作は /etc/printcap 内にある全プリンタに対しておこなわれることになります. abort printer-name 現在のジョブをキャンセルし, プリンタを停止させます. キューが許可状態にある場合は, ユーザはまだジョブを入力することができます. clean printer-name プリンタのスプーリングディレクトリから, ジョブの古いファイルを削除します. 状況によって, とりわけ, 印字途中でエラーが発生していたり, 管理操作が頻発していた場合には, ジョブで作られたファイルを LPD が完全に削除しないことが あります. このコマンドでは, スプーリングディレクトリに入っていないファイルを見つけ出し, それを削除しています. disable printer-name キューに新しいジョブを入れることを禁止します. プリンタ がスタート状態にあるときは, キューに残っているジョブの印字は続けられます. ただし, キューが禁止状態にあったとしても, スーパーユーザ (root) は常にジョブを入力することができます. このコマンドは, 新しいプリンタやフィルタを設置している間に使用すると有用です. すなわち, キューを禁止状態にしておくと, root によるジョブのみが入力されます. そして, その他のユーザは, テストが完了し, enable コマンドでキューが再度許可状態になるまで, ジョブの入力はできなくなります. down printer-name message プリンタをダウンさせます. これは, disable をおこなった後で, stop をおこなった場合と等価になります. message は, ユーザが &man.lpq.1; コマンドでプリンタのキューの状態を調べたり, lpc status でプリンタの状態を調べたときに, プリンタの状況として表示されるメッセージです. enable printer-name プリンタのキューを許可状態にします. ユーザはジョブの入 力ができるようになりますが, プリンタがスタートの状態に なるまでは, プリンタからは何も印字されません. help command-name command-name コマンドのヘルプメッセージを表示します. command-name が指定されなかった場合は, 利用できるコマンドの要約が表示されます. restart printer-name プリンタをスタートさせます. 通常のユーザは, LPD がある異常な状況でハングしたときに限り, このコマンドを使用することができます. しかし, stop または down コマンドにより, 停止状態にあるプリンタをスター トさせることはできません. restart コマンドは, abort の後に start をおこなったことと同じになります. start printer-name プリンタをスタートさせます. プリンタのキューにあるジョブを印字することでしょう. stop printer-name プリンタを停止します. プリンタは, 現在のジョブを終了させ, そして, キューにあるその他のジョブは印字しません. プリンタが停止状態にあったとしても, まだ, 許可状態にあるキューに対して, ジョブを送ることができます. topq printer-name job-or-username printer-name のキューに対して, ジョブ番号 job のジョブ, または, ユーザ username から送られたジョブを置き換えて, キューの先頭に持ってきます. このコマンドに関しては, printer-name の代わりに all を使用することはできません. up printer-name プリンタをアップ状態にします. これの反対のコマンドが down です. start の次に enable をおこなったことと等しくなります. コマンドラインから上記のコマンドを入力すると, &man.lpc.8; はこれを受け付けます. コマンドが入力されなかった場合は, &man.lpc.8; は対話モードに入り, exit, quit, または, ファイル終端文字が入力されるまでコマンドの入力ができます. 標準スプーラの代替品 このマニュアルを最初から通読されている方ならば, ここまでで, FreeBSD 付属の LPD スプーリングシステムに関して知っておくべき ことすべてを学ばれたことと思います. 多分, このシステムにあるたくさんの欠点について認識できたことでしょう. すると, (FreeBSD 上で動作する) スプーリングシステムには他にどのようなものがあるのか という疑問が自然と湧いてきます. LPRng LPRng LPRng は, その称するところの意味は次世代の LPR です. これは PLP を完全に書き換えたものになっています. Patrick Powell と Justin Mason (PLP の主要な管理者) の共同で LPRng が作成されました. LPRng の主要サイトは ftp://dickory.sdsu.edu/pub/LPRng/ です. トラブルシューティング &man.lptest.1; を使った簡単なテストをおこなった結果, 正しい出 力を得られずに, 以下に示すような出力が得られるかもしれません. しばらくしたら出力される, または, 紙の全体が出てこない プリンタは上で示されたような印字を おこなったのですが, しばらくして止まってしまい, 動かなくなってしまいました. 印字された結果をプリンタから取り出すためには, プリンタにある PRINT REMAINING ボタン, または, FORM FEED ボタンを押す必要があるようです. この場合は, おそらくジョブはプリントをする前に 更にデータが送られてこないか待ち続けているのでしょう. この問題を解決するためには, プリンタに FORM FEED 文字 (あるいは特定の必要な文字コード) を 送るテキストフィルタを使ってください. プリンタ内部に残ったデータをプリンタにすぐに印字させるには, 普通はこれで十分です. 次のジョブが前のジョブの最終ページの中央の どこかから印字を開始させないためにも, 紙の途中で印字のジョブが終了したかどうかを確認するのは有益です. シェルスクリプト /usr/local/libexec/if-simple を次のように変更して, プリンタへジョブを送信した後に FORM FEED 文字を印字させるようにします. #!/bin/sh # # if-simple - Simple text input filter for lpd # Installed in /usr/local/libexec/if-simple # # Simply copies stdin to stdout. Ignores all filter arguments. # Writes a form feed character (\f) after printing job. /bin/cat && printf "\f" && exit 0 exit 2 階段効果が現れた 次のような印字結果が得られた. !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 #$%&'()*+,-./0123456 MS-DOS OS/2 ASCII あなたは「階段効果」 の新たなる犠牲者になってしまいました. この原因は, 改行を表わすべき文字がなんであるか の解釈が混乱していることにあります. Unix スタイルのオペレーティングシステムでは, 改行文字は ASCII コード10 の line feed (LF) の1文字が使われています. MS-DOS や OS/2などは ASCII コード10の LF と, ASCII コード 13の文字 (carriage return または CR) をペアで使います. (訳注:Machintosh では CR のみで表現されています). 大抵のプリンタでは, 改行を表わすために MS-DOS の慣習にしたがいます. FreeBSD で印字する場合, 印字したテキストは LF 文字だけ が使われていました. プリンタでは LF 文字を見つけると, 紙を1行分送り出しました. しかし, 次の文字を印字するた めの紙の水平方向の位置は維持されました. すなわち, CR 文字が意味することは, 次の文字を印字する位置を紙の左端に動かすことです. FreeBSD がプリンタに動作をして欲しいと思っている動作を以下に示します. プリンタが CR を受け取ったとき CR 動作 (復帰) をおこなう プリンタが LF を受け取ったとき CR + LF 動作 (復帰, 改行) をおこなう このように動作させるための方法がいくつかあります. これらの文字の解釈を変えるために, プリンタの設定スイッチかコントロールパネルを操作する方法. どのようにして設定をするかはプリンタのマニュアルを参照してください. FreeBSD 以外のオペレーティングシステムを切り替えて使う場合, CR と LF 文字の解釈をそのオペレーティングシステムで使われているようにプリンタを 再設定する必要があるかもしれません. 以下に示す解決方法のいずれかを 選ぶのがよいかもしれませんね. 自動的に LF を CR+LF に変換してくれる FreeBSD 用のシリアルドライバを入手する方法. もちろん, このドライバはプリンタ専用に接続される シリアルポート のみで動作します. この機能を許可するためには, /etc/printcap ファイルで対象プリンタの fs 項目で CRMOD ビットをセットします. LF 文字の扱いを一時的に変更するための エスケープコード をプリンタに送る方法. プリンタがサポートしているかもしれないエスケープコード については, プリンタのマニュアルを参照してください. 適切なエスケープコードが見つかったら, 最初にそのコードを送り, 次にプリントジョブを送信 するようにテキストフィルタを変更してください. PCL 次に, Hewlett Packard 社の PCL エスケープコードに対応しているプリンタのための テキストフィルタの例を示します. このフィルタでは, プリンタ に LF 文字を LF と CR の2文字として扱わせます. その後に, プリンタにジョブを送ります. 最後に, ジョブの最終ページの紙を排出するため, FROM FEED 文字を送ります. このフィルタは Hewlett Packard 社のほとんどすべてのプリンタで機能するはずです. #!/bin/sh # # hpif - Simple text input filter for lpd for HP-PCL based printers # Installed in /usr/local/libexec/hpif # # Simply copies stdin to stdout. Ignores all filter arguments. # Tells printer to treat LF as CR+LF. Ejects the page when done. printf "\033&k2G" && cat && printf "\f" && exit 0 exit 2 ホスト orchid にある /etc/printcap の例を以下に示します. ここには, 一番目のパラレルポートにプリンタ (Hewlett Packard LaserJet 3Si) が一台接続されており, そのプリンタ名は teak です. # # /etc/printcap for host orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif: 訳注 LF を CR+LF に置き換える cat コマンドを作る方法も当然考えられます. そして, このコマンドと, if-simple の cat の部分を置き換えればよいわけです. 具体的にどのようにするかは, 読者への練習問題としましょう. 各行が重ね書きされてしまった プリンタは紙送りをまったくしませんでした. テキストすべての行がある行の上で重ねて印字されてしまいました. この問題は, 階段現象とは正反対な問題で, ほとんどまれにしか起こりません. FreeBSDでは行末として扱われる LF 文字が, 紙の左端に印字位置を復帰しますが, 紙送りはしない CR 文字として扱われています. プリンタの設定スイッチかコントロールパネルを使って, LF と CR の文字を次のような解釈をするようにしてください. プリンタが受け取ったとき プリンタがおこなう CR CR 動作 (復帰) LF CR + LF (復帰, 改行) 訳注 LF を CR+LF に置き換える cat コマンドを作る方法も当然考えられます. そして, このコマンドと, if-simple の cat の部分を置き換えればよいわけです. 具体的にどのようにするかは, 読者への練習問題としましょう. プリンタが文字を紛失してしまう 印字しているのですが, 各行の2〜3文字が印字されません. プリンタを動かせば動かすほど, もっとたくさんの文字が紛失されていき, この問題は更に悪くなっていくかもしれませんでした. この問題は, シリアルポートを通してコンピュータから送られてくるデータの速度に, プリンタがついていけないことに起因します (この問題は, パラレルポートに接続された プリンタでは発生することはありません). この問題を克服する方法が2つあります. プリンタが XON/XOFF のフロー制御をサポート している場合は, 項目 fs で TANDEM ビット をセットして, FreeBSD にこの機能を使用させてください. プリンタがキャリアフロー制御をサポートして いる場合は, 項目 fs で MDMBUF ビットをセットして下さい. それから, プリンタとコンピュータを接続しているシリアルケーブルが キャリアフロー制御用に正しく配線されたものかどうかを確認してください. プリンタがフロー制御をまったく サポートしていない場合は, 項目 fs の NLDELAY と TBDELAY, CRDELAY, VTDELAY, BSDELA のいくつかのビットを組み合わせて使い, プリンタへ送るデータの流れに適当な遅延を加えてください. プリンタは意味不明な文字列を印字した プリンタはランダムなゴミのように 見えるものを印字しましたが, 意図したテキストは印字してくれませんでした. この問題は, 通常, シリアルポートに接続したプリンタでの 通信パラメータの誤りからくる前項とは別の症状です. br 項目の通信速度と fs と fc 項目のパリティビットの設定を共に調べてみてください. また, プリンタでの設定が /etc/printcap ファイルで設定した 内容と一致しているかどうかも確認してください. 訳注 simple-if のような単純なフィルタだけの状態で, 日本語を含むテキストを印字しようとした場合にも, シリアルポート, パラレルポートの使用に関係なく, このような症状は見られます. 日本語プリンタの場合, 漢字コードそのもの を送信しただけでその漢字を印字してくれるものは, 少なくとも訳者は見たことがありません. 漢字を印字するための制御 コードを別途送信するフィルタが必要となります. また, そのようなフィルタを使用していても, そのフィルタが想定してる漢字コードと異なった文書を プリントしようとしたとき もこのような症状は出ます. もちろん, これはプリンタ用の 言語を持たないプリンタの話で, PostScript プリンタ などにプレインテキストを送信しても, 日本語対応, 非対応に関らず, 意味不明な文字列が印字される (もしくは, 何も印字されない) ことでしょう. 何も起きない もしプリンタが何の動作もしないのであれば, ハード的な問題ではなく, 多分 FreeBSD の中に問題があります. /etc/printcap ファイルで, デバッグしているプリンタのエントリに (lf 項目で) ログファイルを取るように 設定を追加してください. 例えば, プリンタ rattan 用のエントリの項目 lf は次のようになります. rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple:\ :lf=/var/log/rattan.log 次に, もう一度印字をおこなってみます. そして, 発生したと思われるエラーメッセージを見るためにログファイル (上記の例では, /var/log/rattan.log) を調べます. そこで見られたメッセージを元に, 問題を解決してみてください. 項目 lf が指定されていない場合, LPD はデフォルト のログファイルとして /dev/console を使います. diff --git a/ja_JP.eucJP/books/handbook/security/chapter.sgml b/ja_JP.eucJP/books/handbook/security/chapter.sgml index f558530068..1ff22b80b7 100644 --- a/ja_JP.eucJP/books/handbook/security/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/security/chapter.sgml @@ -1,3203 +1,3204 @@ セキュリティ この章の多くの部分は&a.dillon;によって書かれた &man.security.7; マニュアルページからの引用です. 訳: &a.jp.hino;, (jpman プロジェクトの成果を利用させ ていただきました). この章では この章では, 基本的なシステムセキュリティの考え方, 覚えておくべき一般的なルールを紹介し, そして S/Key, OpenSSL, Kerberos などの高度な話題について簡単に説明します. はじめに セキュリティとは, システム管理者をいつも悩ませる仕事の一つです. すべての BSD UNIX マルチユーザシステムは, 従来からいくつかのセキュリティ機構を備えていますが, ユーザを疑心暗鬼に陥らせないように追加のセキュリティ機構を構築し 保守する仕事はおそらく, システム管理者としてもっとも大きな責務の一つでしょう. マシンの安全性に反映されるのは, 管理者が作業したことだけです. またセキュリティ問題は, 快適な環境に必要なものと競合します. 一般に UNIX システムは膨大な数のプロセスを同時に動作させることができ, そのプロセスの大部分は, サーバ – 外部から接続し, 通信するものとして動作します. かつてのミニコンとメインフレームがデスクトップにとってかわり, さらにコンピュータが相互に接続されたネットワークを形成するようになった今日, セキュリティは非常に大きな関心事になってきています. セキュリティを実装するには, タマネギのように階層化する手法 (a layered onion approach) が最適です. どうすれば良いのか簡単に説明すると, 便利な機能と同じ数だけセキュリティの階層を作り, システムへの侵入を注意深く監視するのです. あなたはセキュリティを過度に厳重にしたり, 侵入の監視に時間をとられたいとは思わないでしょう. この侵入の発見という部分は, あらゆるセキュリティ機構において最も重要な部分の一つなのです. たとえば, システムの各バイナリに schg フラグ を設定するのは, 大して意味がありません. フラグを設定すると一時的にバイナリが保護され, 侵入してきたクラッカーによってシステムに加えられる変更のうち, 容易に検出可能な変更は行なえなくなります. しかしその結果として, セキュリティ機構がその侵入者を検出することも まったくできなくなってしまうでしょう. また, システムセキュリティには, さまざまな形での攻撃に対処することとも関係しています. この攻撃には root 権限を奪おうとするものだけでなく, クラッシュやシステムの不安定状態を引き起こそうとするものを含まれます. このセキュリティ問題は, いくつかに分類することが可能です. サービス妨害攻撃 (denial of service attack) ユーザアカウントの不正利用 (user account compromise) アクセス可能なサーバを使った root 権限の不正利用 ユーザアカウントを経由した root 権限の不正使用 バックドアの設置 サービス妨害攻撃 (DoS 攻撃) とは, マシンから必要な資源を奪う行為です. 通常, サービス妨害攻撃はそのマシンで実行されるサーバや ネットワークスタックを過負荷状態にしてマシンをクラッシュさせたり, マシンを使えなくしたりするような力任せの方法です. サービス妨害攻撃の中には, ネットワークスタックのバグを利用して, パケット一つでマシンをクラッシュさせようとするものもあります. 後者には, カーネルにバグ修正を施すことによってのみ対応することができます. サーバプロセスに対する攻撃は, オプションを適切に指定することによって, 攻撃されている状況でサーバプロセスの負荷上昇に限界を設定することで 対応できる場合が多いです. これらに比べると, ネットワークへの力任せの攻撃への対応はずっと難しくなります. たとえば, 偽造パケットによる攻撃 (spoof-packet attack) は, インターネットからシステムを切り離す以外の方法で 防ぐことはほとんど不可能です. この攻撃によって, マシンを落としてしまうことはできないかもしれませんが, 接続しているインターネット回線を混雑させていっぱいにしてしまうことはできます. ユーザアカウントの不正利用は, サービス妨害攻撃 よりもずっとよくある問題です. このご時勢でも, 自分たちのマシンで 標準の telnetd, rlogind, rshd, ftpd サーバを実行させているシステ ム管理者は多いのです. これらのサーバは, デフォルトでは, 暗号化さ れたコネクション上で動作していません. その結果, 抱えているユーザ 数が標準くらいであれば, リモートログイン (そのシステムにログイン するには最も普通で便利な方法です) しているユーザのうち一人以上は, パスワードを覗き見られてしまうでしょう. システム管理者が注意深い 人ならば, たとえログインが成功していたとしても, リモートアクセス ログを解析して, 疑わしい送信元アドレスを探すものです. ひとたび攻撃者がユーザアカウントへのアクセス権を入手すると, 攻撃者が root の権限を破る可能性があることを仮定するべきです. し かし, セキュリティを十分維持し, 手入れの行き届いたシステムにおい ては, あるユーザアカウントへのアクセスが可能となっても, 攻撃者に 必ずしも root へのアクセス権を与えるとは限りません. こ の違いは重要です. というのは, 一般的に root へのアクセス権がなければ, 攻撃者は自分の侵入の痕跡を隠蔽することができませんし, そ のユーザのファイルを引っかき回したり, マシンをクラッシュさせたり できるのがせいぜいです. ユーザアカウントの不正利用は めずらしいことではありません. それは一般ユーザに, システム管 理者ほど注意を払わない傾向があるからです. システム管理者は「あるマシン上で root の権限を破る方法は, 潜 在的に何通りもあるのだ」ということを心しておかねばなりません. 攻撃 者が root のパスワードを知ってしまうかもしれませんし, 攻撃者が root の権限で実行されるサーバのバグを見つけ, ネットワークからそ のサーバへ接続して root の権限を破ることができるかもしれません. ひとたびユーザアカウントを破ると, ユーザアカウントから root の権 限を破ることを可能にするような suid-root プログラムに存在するバグを 攻撃者は知っているかもしれません. あるマシン上で攻撃者 が root の権限を破る方法を知ったとすると, 攻撃者は, 裏口を作る必 要はありません. これまでに発見され, ふさがれた root の 穴の多くには, クラッカーが侵入した跡を消そうとしてたくさん仕事し た結果が含まれています. そのためにこそ, 多くのクラッカーは裏口を 作るのです. 攻撃者は裏口を使ってシステムへの root アクセスを再び 簡単に得ることができます. しかしこの裏口は, クラッカーの検出をす るのに便利なものでもあります. クラッカーに裏口を作らせないように するということは, セキュリティにとっては実際には良くないことかも しれません. なぜなら, そうすることで, クラッカーが最初に侵入して くるために発見したセキュリティホールがふさがるわけではないからで す. セキュリティを改善する方法は, 常に, タマネギの皮 のように階層化する手法 (a multi-layered onion peel approach) で実装されるべきです. これら は次のように分類できます. root とスタッフのアカウントの安全性を高める. root の安全性を高める – root 権限で動作するサーバ と suid/sgid バイナリ. ユーザアカウントの安全性を高める. パスワードファイルの安全性を高める. カーネルのコア, raw デバイス, ファイルシステムの安全性を 高める. システムに対して行なわれた, 不適切な変更をすばやく検出す る. 必要と思われる以上の対応をとる (paranoia). 本章の次の節では, 上記の各項目についてより深く掘り下げていき ます. FreeBSDの安全性を高める 以下の節では, 本章の前節 でとりあげた FreeBSD システムの安全性を高める方法について 述べます. root アカウントとスタッフアカウントの安全性を高める root のアカウントの安全性を確保しないうちからスタッフのア カウントの安全性をうんぬんしてもしかたがありません. ほとんどの システムでは, root アカウントに割り当てたパスワードが 1 つあり ます. まず最初にすべきことは, このパスワードはいつで も不正利用の危険に晒されていると仮定することです. これは root のパスワードを消すべきだと言っているのではありません. root のパスワードは, マシンにコンソールからアクセスするのには, ほとんどいつでも必要なものです. ここで言いたいのは, コンソール 以外からは, そして可能なら &man.su.1; コマンドを実行する場合も root のパスワードを使えないようにするべきである, ということで す. たとえば, あなたが使っている pty が, /etc/ttys ファイルで unsecure と指定 されているか確認してください. そうすると, telnet や rlogin 経由では root で直接ログインできないようになります. sshd のような, 別のログインサービス を使っている場合でも同様に, 直接 root へログインすることを許し ていないかどうか確認してください. すべてのアクセス手段 – たとえば ftp のようなサービスが, 良くクラックの対象となることを 考えましょう. root への直接ログインは, シス テムコンソール経由でのみ可能であるべきなのです. また当然, システム管理者として自分が root になれるようにしておく必要が ありますから, そのための穴をいくつか開けておきます. し かし, それらの穴を動作させるには, さらに追加のパスワード認証が 必要であるようにしておくことが重要です. root でアクセス可能と する方法の一つとして, 適切なスタッフアカウントを (/etc/group 中の) wheel グループに加えることがありま す. wheel グループに入っているスタッフメン バは su を使って root になることが許されま す. パスワードエントリにおいて, スタッフメンバを wheel グループに置くことによって直接 wheel 権限を与えてはいけません. スタッフメンバのアカウントは staff グループに所属させるべきで, そして /etc/group ファイルを通して wheel グループに加えるべきです. 実際に root アクセスの必要なスタッフメンバのみ wheel グ ループに置くようにすべきです. 他の認証方法の場合, たとえば kerberos を使用する場合には, root アカウントの .k5login ファイルを使って, 誰も wheel グループに置く必要なく &man.ksu.1; を 使って root になることを許すようにすることもできます. このやり 方はよりよい解決策なのかもしれません. なぜなら, wheel のメカニズムでは, 侵入者がパスワード ファイルを手に入れ, スタッフアカウントのいずれか 1 つを破るこ とができると, root を破ることがまだできてしまうからです. wheel のメカニズムを用いる方が, 何もしない よりは良いのですが, 必ずしも最も安全な選択肢とは限りません. root アカウントの安全性を高める間接的な方法として, 別のロ グインアクセスの方法を用いてスタッフのアカウントの安全性を高め, その上でそのスタッフのアカウントの暗号化パスワードを * にしておく方法があります. この方法だと, 侵入者がパスワードファイルを盗むことができた場合でも, スタッフ アカウントを破ることはできなくなります (また, たとえ root が暗 号化パスワードをパスワードファイルに付けていたとしても, 間接的 に root アカウントを破ることはできません). スタッフメン バがスタッフアカウントでログインする際には, &man.kerberos.1; や &man.ssh.1; のような, 公開鍵 / 秘密鍵の鍵の組を使う安全性の 高いログイン機構を使います. kerberos のようなログイン機構を使う 場合は一般に, kerberos サーバを実行するマシンと自分のデスクトッ プワークステーションとの安全性を確保しなければなりません. また ssh で公開鍵 / 秘密鍵の組を使う場合, 一般に, ログイン元マシン (通常は自分のワー クステーション) の安全性を確保しなければなりません. ここで, <&man.ssh-keygen.1; で公開鍵 / 秘密鍵の組を生成する際, 鍵の組 をパスワードで防御することにより, 鍵の組への防御層を追加するこ ともできます. スタッフアカウントのパスワードを * でつぶすことができると, 管理者自身が設定 した安全性の高い方法でしかスタッフメンバがログインできないこと も保証できます. こうして, 多くの侵入者が使う重大なセキュリティ の穴, すなわち, 安全性の低い無関係なマシンからネットワークを覗 き見る方法, を塞ぐようなセッションを提供する, 安全性の高い暗号 化されたコネクションを使うことを, スタッフメンバ全員に強制する ことができるのです. より間接的なセキュリティの仕組みでは, 制限の強いサーバから 制限の弱いサーバへログインすることを前提としています. たとえば, メインマシンで, 様々な種類のサーバを実行させている場合, ワーク ステーションではそれらのサーバを実行させてはなりません. ワーク ステーションを十分に安全にしておくためには, 実行するサーバの数 を, 一つもサーバが実行されていないというくらいにまでできる限り 減らすべきです. また, パスワードで保護されたスクリーンセーバを 走らせておくべきです. ワークステーションへの物理的アクセスが与 えられたとすると, もちろん言うまでもなく, 攻撃者は管理者が設定 したいかなる種類のセキュリティをもうち破ることができるのです. このことは, 管理者として必ず考えておかねばならない問題ですが, システム破りの大多数は, ネットワーク経由でリモートから, ワーク ステーションやサーバへの物理的アクセス手段を持たない人々によっ て行われるという事実もまた, 念頭に置いておく必要があります. kerberos のような方法を使うことで, スタッフアカウントのパ スワードの変更もしくは停止を一箇所で行なうことと, スタッフメン バがアカウントを持つすべてのマシンに即時にその効果を及ぼすこと が可能となります. スタッフメンバのアカウントが危険に晒されたと きに, すべてのマシンでスタッフメンバのパスワードを即座に変更す る能力を過小評価してはいけません. パスワードが分散されている状 況では, N 台のマシンでパスワードを変更すると, てんやわんやの事 態を招く可能性があります. kerberos を使用すると, パスワードの 再発行に制限 (re-passwording restriction) を課することもできま す. この機能を使うことにより, ある kerberos チケットをしばらく 経つとタイムアウトにすることができるだけでなく, 一定期間 ( 例 えば, 1 ヶ月に 1 回) 経つと, ユーザに新しいパスワードを選ぶよ うに要求することもできます. root 権限で実行されているサーバと SUID/SGID バイナリの安全性を高める 用心深いシステム管理者は, 自分に必要なサーバプロセスだけを 過不足なく実行させるものです. サードパーティ製のサーバは, よくバグを持っ ていがちだということに注意して下さい. たとえば, 古いバージョンの imapd や popper を実行させておくのは, 全世界に万能の root の切 符を与えているようなものです. 自分で注意深くチェックしていない サーバは, 決して実行してはいけません. root で実行させる必要の あるサーバはほとんどありません. たとえば, ntalk, comsat, finger デーモンを, 専用ユーザの 砂場 (sandbox) で実行させることができます. 管理者が膨大な数の問題に直面していないのなら, この「砂場」は完 璧ではありませんが, セキュリティに関するタマネギ的アプローチは ここでも成り立ちます. 砂場で実行されているサーバプロセスを経由 して侵入を果たすことができたとしても, 攻撃者はさらに砂場から外 に脱出しなければなりません. 攻撃者が通過せねばならない層の数が 増えれば増えるほど, それだけ攻撃者が侵入に成功する確率が減りま す. root の抜け穴は歴史的に, 基本システムサーバも含め, root 権 限で実行されるほとんどすべてのサーバプロセスで発見されています. ユーザが sshd 経由でのみログインし, telnetd, rshd, rlogind 経由でログインすることが決 してないマシンを稼働させているのであれば, それらのサービスを停 止させて下さい! FreeBSD では, 今では ntalkd, comsat, finger は砂場で実行させることがデフォ ルトになっています. 次に砂場で実行させるべきプログラムの候補と して, &man.named.8; があります. /etc/defaults/rc.conf ファイルには, named を砂場で実行するために必要な 引数がコメントアウトされた形式で含まれています. 新しいシステム をインストールしているか, それとも既存のシステムをアップグレー ドして使っているかに依存しますが, 砂場として使用する特別のユー ザアカウントがインストールされていないかもしれません. 用心深い システム管理者であれば, できるだけいつでも研究を怠らず, サーバ に砂場を仕込むものでしょう. 通常, 砂場で実行しないサーバが他にいくつかあります. sendmail, popper, imapd, ftpd などです. これらのうちいくつか のサーバには代わりとなるものがありますが, 代わりのものをインス トールするには, あなたが思うより多くの仕事が必要になるかもしれ ません (便利さという要素がまたも勝利を収めるわけです). これら のサーバは, root 権限で実行せねばならいかもしれません. また, これらのサーバ経由で生じる侵入を検出するためには, 他の仕組みに 頼らなくてはならないかもしれません. システムの root 権限の潜在的な穴で他に大きなものとして, シ ステムにインストールされた suid-root/sgid バイナリがあります. これらのバイナリは, rlogin のように, /bin, /sbin, /usr/bin, /usr/sbin に存在するものがほとんどです. 100% 安全なものは存在しないとは いえ, システムデフォルトの siud/sgid バイナリは比較的安全とい えます. それでもなお, root の穴がこれらのバイナリにときおり発 見されています. 1998 年に Xlib で見つかった root の穴は, xterm (普通, suid 設定 されています)を脆弱にしてしまいました. 安全である方がよいので, 用心深いシステム管理者は残念に思いながらも, スタッフのみが実行 する必要がある suid バイナリは, スタッフのみがアクセス可能な特 別なグループに含めるように制限を加え, 誰も使わない suid バイナ リは (chmod 000 を実行して) 片付けてしまう でしょう. ディスプレイを持たないサーバは, 一般的に xterm のバイナリを必要としません. sgid バイナリもほとんど同様の危険な存在になり得ます. 侵入者が kmem に sgid されたバイナリを破ることができた場合, その侵入者 は /dev/kmem を読み出すことができるように なるでしょう. つまり, 暗号化されたパスワードファイルを読み出す ことができるようになるので, パスワードを持つどのアカウントをも, 潜在的な危険に晒すことになります. 他にも, kmem グループを破った侵入者が pty を通して 送られたキーストロークを監視できるという危険があります. キース トロークには, 安全な方法でログインするユーザが使っている pty も含まれます. tty グループを破った侵入者は, ほぼ任意のユーザの tty へ書き込みができます. ユーザが端末プログラムやキーボードを シミュレーションする機能を持ったエミュレータを使っている場合, 侵入者は潜在的に, 結局そのユーザとして実行されるコマンドをユー ザの端末にエコーさせるデータストリームを生成できる可能性があり ます. ユーザアカウントの安全性を高める ユーザアカウントは, 普通, 安全性を高めることが最も困難です. スタッフに対しては, とても厳格なアクセス制限を強制しパスワード を * で外すことができるでしょうが, 管理者が 持ちうる一般ユーザすべてのアカウントに対して同じことはできない かもしれません. 管理者が十分に統率をとることができるなら, 管理 者は勝利し, ユーザのアカウントの安全を適切に確保できるかもしれ ません. それができないならば, よりいっそう気を配って一般ユーザ のアカウントを監視するよりほかありません. 一般ユーザアカウント に対し ssh や kerberos を利用するこ とには, システム管理がさらに増えたりテクニカルサポートが必要に なるなどの問題があります. それでも, 暗号化パスワードファイルと 比較するとはるかに良い解です. パスワードファイルの安全性を高める できるだけ多くのパスワードを * で外し, それらのアカウントのアクセスには ssh や kerberos を使うようにするこ とが, 唯一の確実な方法です. 暗号化パスワードファイル (/etc/spwd.db) は root でのみ読み出し可能 だといっても, 侵入者が root の書き込み権限は得られなくとも, 読 み出しアクセス権限を得ることは可能かもしれません. セキュリティスクリプトで常にパスワードファイルの変更をチェッ クし, 報告するようにすべきです (ファイルの完全性のチェック 参照). カーネルのコア, raw デバイス, ファイルシステムの安全性を 高める root の権限を破ると, 攻撃者は何でもできますが, 特に重宝さ れる特定の事柄もいくつかあります. たとえば, 最近のカーネルは, 組 み込みのパケット覗き見デバイス (packet sniffing device) ドライ バを備えているものがほとんどです. FreeBSD では bpf デバイスと呼ばれています. 侵入者 は普通, 侵入済みのマシンでパケット覗き見プログラムを実行させよ うと試みます. 侵入者にわざわざそういう機能を提供する必要はない ので, ほとんどのシステムで bpf デバイスを組み込むべきではあり ません. bpf デバイスを外しても, /dev/mem と /dev/kmem という悩みの種がまだ残っていま す. この問題に関しては, 侵入者は raw ディスクデバイスに書き込 むこともできます. また, モジュールローダ, &man.kldload.8; とい う, 別のカーネル機能があります. やる気まんまんの侵入者は, KLD モジュールを使って自分独自の bpf もしくはその他覗き見デバイス を動作中のカーネルにインストールすることができます. この問題を 避けるため, システム管理者はカーネルをより高い安全レベル ( securelevel) , 少なくとも安全レベル 1 で実行させる必要がありま す. sysctl を使って kern.securelevel 変数に安全レベルを設定する ことができます. ひとたび安全レベルに 1 を設定すると, raw デバ イスに対する書き込みアクセスは拒否され, たとえば schg のような特別な chflags フラグの機能が 強制されます. システム起動に関わる重要なバイナリやディレクトリ, スクリプトファイルなど, 安全レベルが設定されるまでの間に実行さ れるすべてのものに対しても schg フラグを on にしておくことも確実に実行してください. この設定をやり過ぎても 構いませんが, より高い安全レベルで動作している場合, システムの アップグレードがはるかに困難になります. システムをより高い安全 レベルで実行させるようにするが, すべてのシステムファイルとディ レクトリに schg フラグを設定しないという妥 協をする方法もあります. もう一つの可能性としては, 単純に / および /usr を読み 込み専用でマウントすることです. ここで特筆すべきことは, システ ムを守ろうとして厳しくしすぎると, 侵入を検出するという非常に重 要なことができなくなってしまうということです. ファイルの完全性のチェック: バイナリ, 設定ファイルなど ことこの問題に至ると, システム管理者にできることは, 便利さ という要素がその醜い頭を上げない程度に, コアシステムの設定と制 御ファイルを防御することだけです. たとえば, / および /usr にある 大部分のファイルに schg ビットを設定するた めに chflags を使用するのは, おそらく逆効果 でしょう. なぜなら, そうすることでファイルは保護できますが, 侵 入を検出する窓を閉ざしてしまうことにもなるからです. セキュリティ のタマネギの最後の層はおそらく最も重要なもの – 検出で す. セキュリティの残りのものは, 突然の侵入を検出できなければ, まったく有用ではありません (あるいは, もっと悪ければ, 安全性に 対する間違った感覚を植え付けてしまいます). タマネギの仕事の半 分は, もう半分の検出側が攻撃者を攻撃の最中に捕えるようにするた めに, 攻撃者を食い止めるのではなく侵入を遅らせることなのです. 侵入を検出する最も良い方法は, 変更されていたり, 消えていた り, 入れた覚えがないのに入っているファイルを探すことです. 変更 されたファイルを探すのに最も良い方法は, もう一つの (しばしば中 央に集められた), アクセスが制限されたシステムから行なうもので す. さらに安全でアクセス制限されたシステム上でセキュリティ用ス クリプトを書けば, スクリプトは潜在的なクラッカー達からはほぼ見 えなくなります. これは重要なことです. この有効性を最大限に活用 するためには, 一般的に, アクセスの制限されたマシンから実際に使っ ている他のマシンへのかなりのアクセスを許す必要があります. 普 通は, 他のマシンからアクセス制限されたマシンへ読み込み専用の NFS エクスポートをしたり, アクセス制限されたマシンから他のマシ ンへ ssh を行なうために, ssh 鍵のペアを作ったりすることで行 います. ネットワークのトラフィックを別にして, NFS は最も可視性 のない方法です – 各クライアント上のファイルシステムを, 事実上検出されずに監視できるようになります. アクセス制限された サーバがスイッチを通してクライアントに接続されている場合, たい てい NFS がより良い選択肢です. アクセス制限されたサーバがハブ を通したり, いくつかのルーティング層を通したりしてクライアント に接続する場合, NFS はあまりにも危険な方法かもしれず (ネットワー クの面で) , ssh の方が認証の道筋は 跡となって残りますが, それでもより良い方法かもしれません. アクセス制限されたマシンに, 監視しようとするクライアントシ ステムへの少なくとも読み込みのアクセス権を与えたら, 次に実際に 監視するためのスクリプトを書かなくてはいけません. NFS マウント をすれば, &man.find.1; や &man.md5.1; などの単純なシステムユー ティリティでスクリプトを書くことができます. 少なくとも 1 日 1 回, クライアントのファイルを直接 md5 にかけ, さらにもっと頻繁 に /etc および /usr/local/etc にあるようなコントロール用 ファイルを試験するのが一番です. アクセス制限されたマシンが正し いと知っている, 基となる md5 情報と比べて違いが見つかった場合, システム管理者に調べて欲しいと悲鳴を上げるようにすべきです. 優 れたセキュリティ用スクリプトは, / および /usr などのシステムパーティション上で不適 当に suid されたバイナリや, 新たに作成されたファイルや削除され たファイルもチェックするでしょう. NFS ではなく, ssh を使用する場 合は, セキュリティ用スクリプトを書くのはずっと難しいことで す. スクリプトを動かすためには, クライアントに対してスクリプト を scp しなくてはいけませんし, それは目に見 えてしまいます. そして, 安全のためには, スクリプトが使うバイナ リ (find など) を scp する必要もあります. クライアントの ssh デーモンはすでに 攻撃されてしまっているかもしれません. 結局のところ, 安全でない リンク上の場合は ssh は必要かもしれ ませんが, ssh を扱うのはとても大変 なことです. 優れたセキュリティ用スクリプトは, ユーザやスタッフメンバの アクセス設定ファイルの変更もチェックするものです. .rhosts, .shosts, .ssh/authorized_keys など … MD5 チェックの範囲外になってしまうであろう ファイル群です. ユーザ用のディスク容量が非常に大きい場合は, パーティション 上の各ファイルを見て回るのに大変な時間がかかるかもしれません. この場合は, マウントフラグを設定して, このパーティションに suid されたバイナリやデバイスを置けないようにするのが良い考え です.nodev および nosuid オプション (&man.mount.8; 参照) が知るべきものでしょう. とにかく少なくとも週に 1 度はファイルシステムをスキャンするべきです. なぜなら, この層の目的は, 侵入が成功したかどうかに関わらず, 侵 入があったことの検出をすることだからです. プロセスアカウンティング (&man.accton.8; 参照) は, マシンへの侵入を検出するためのメカニズムとして推奨できる, 比較的オーバヘッドの少ないオペレーティングシステムの機能です. 侵入を受けた後でも当該ファイルが無傷である場合に, 侵入者が 実際にどのようにしてシステムに侵入したかを追跡するのに特に役立ちます. 最後に, セキュリティスクリプトはログファイルを処理するよう にし, ログファイル自体もできるだけ安全性の高い方法で生成するよ うにすべきです – リモート syslog は極めて有益になり得ま す. 侵入者は自分の侵入の痕跡を覆い隠そうとしますし, また, ログ ファイルはシステム管理者が最初の侵入の時刻と方法を追跡してゆく ために極めて重要です. ログファイルを永久に残しておくための 1 つの方法は, システムコンソールをシリアルポートにつないで走らせ, コンソールを監視している安全なマシンを通して絶えず情報を集める ことです. 偏執狂的方法 多少偏執狂的になっても決して悪いことにはなりません. 原則的 に, システム管理者は, 便利さに影響を与えない範囲でいくつでもセ キュリティ機能を追加することができます. また, いくらか考慮した 結果, 便利さに影響を与えるセキュリティ機能を追加することもでき ます. もっと重要なことには, セキュリティ管理者とは少し喧嘩にな るはずなのですが – もしあなたが, 本文書に書かれている勧 告をそのまま使用した場合は, 予想されるクラッカーはやはり本文書 を読んでいるわけですから, あなたの防御策を教えてしまうことにな ります. サービス妨害攻撃 このセクションではサービス妨害攻撃 (DOS 攻撃) を扱います. サービス妨害攻撃は, 普通は, パケット攻撃です. ネットワークを飽 和させる最先端の偽造パケット (spoofed packet) 攻撃に対してシス テム管理者が打てる手はそれほど多くありませんが, 一般的に, その 種の攻撃によってサーバがダウンしないことを確実にすることで, 被 害をある限度に食い止めることはできます. サーバの fork の制限. 踏み台攻撃の制限 (ICMP 応答攻撃, ping broadcast など). カーネルの経路情報のキャッシュ. よくあるサービス妨害攻撃は, fork するサーバプロセスに対す るものです. これは, サーバにプロセス, ファイル記述子, メモリを マシンが死ぬまで食い尽くさせようとするものです. inetd (&man.inetd.8; 参照) には, この種の攻撃を制限するオプションが いくつかあります. マシンがダウンすることを防止することは可能で すが, この種の攻撃によりサービスが中断することを防止することは 一般的に言ってできないことに注意する必要があります. inetd のマ ニュアルページを注意深く読んで下さい. 特に, , , オプションに注意して下さい. IP 偽造攻撃 (spoofed-IP attack) は inetd の オプションの裏をかけるので, 一般 にオプションを組み合わせて使用するべきであることに注意して下さ い. スタンドアロンサーバの中には, 自分自身で fork を制限するパ ラメータを持っているものがあります. Sendmail には, オプションがあります. シ ステム負荷の値変化には遅れがあるので, sendmail の負荷限界指定 オプションを使うよりも, このオプションを使う方がまともに動作す る可能性ははるかに高いです. sendmail の実行を開始する際に, MaxDaemonChildren パラメータを設定するべき です. その値は, 通常見込まれる負荷を扱える程度に十分高いが, そ れだけの数の sendmail を操作しよう とするとマシンが卒倒してしまうほどには高くないような値に設定す るべきです. sendmail をキュー処理モード () で実行することや, sendmail デーモン (sendmail -bd) をキュー処 理用プロセス (sendmail -q15m) と別に実行す ることも, 用心深いことと言えます. それでもなおリアルタイムでの 配送を望むのであれば, のようにすることで, キュー処理をはるかに短い時間間隔で行うことができます. いずれに しても, MaxDaemonChildren オプションに合理 的な値を確実に指定して, sendmail がなだれをうって失敗すること がないようにして下さい. syslogd は直接攻撃される可能性 があるので, 可能ならばいつでも オプション を用いることを強く推奨します. これができないなら, オプションを使って下さい. tcpwrapper の逆 identd などの接 続返し (connect-back) を行うサービスについては十分注意を払うよ うにするべきです. これらは直接攻撃を受ける可能性があります. こ ういう事情があるので, tcpwrapper の 逆 ident 機能を使おうとは思わないのが一般的です. 境界ルータのところでファイアウォールを設けて, 外部からのア クセスに対して内部サービスを防御するという考えは実によいもので す. この考えは, LAN の外部からの飽和攻撃を防ぐことにあり, 内部 サービスをネットワークベースの root 権限への攻撃から防御するこ とにはあまり考慮を払っていません. ファイアウォールは常に排他的 に設定して下さい. つまり, ポート A, B, C, D と M から Z まで以外 のすべてに防火壁を設ける というふうにです. このようにすることで, named (ゾーンのプライマリである場合), ntalkd, sendmail などのインターネットからア クセスできるサービスとして特に指定するもの以外の, 小さい番号の ポートすべてをファイアウォールで防御することができます. ファイ アウォールをこの他のやり方 – つまり包含的もしくは受容的 なファイアウォールとして設定しようとする場合, close することを忘れてしまうサービスがいくつか 出てきたり, 新しい内部サービスを追加したのにファイアウォールの 更新を忘れたりする可能性がよく出てきます. ファイアウォール上の 大きい番号のポートを開けておくことにより, 小さい番号のポートを 危険に晒すことなく受容的な動作を許すことができます. FreeBSD で は, net.inet.ip.portrange への sysctl (sysctl -a | fgrep portrange) をいろいろ使用することで, 動的バインドに使用される ポート番号の範囲を制御できることを記憶にとどめておいてください. これによりファイアウォールの設定を簡略化することもできます. たとえば, 通常の first/last 範囲として 4000 から 5000 を, 高位ポートの範囲として, 49152 から 65535 を指定し, (いくつかのインターネットアクセス可能 なポートをブロックから除外するのはもちろんですが) 4000 より下 のすべてをブロックするという設定が考えられるでしょう. また別のよくあるサービス妨害攻撃として, 踏み台攻撃 (springboard attack) と呼ばれるものがあります – これは, あるサーバを攻撃し, そこ結果として生成される応答が自分自身, ロー カルネットワーク, そして他のマシンを過負荷に追い込むようにする 攻撃です. この種の攻撃の中で最もありふれたものに, ICMP ping broadcast 攻撃があります. 攻撃 者は, 実際に攻撃したいマシンのアドレスを送信元アドレスに設定し た ping パケットを偽造して, 対象の LAN のブロードキャストアド レスに向けてパケットを送信します. 境界にあるルータがブロードキャ ストアドレスに対する ping パケットを握り潰すように設定されてい ない場合, LAN は, 詐称された送信元アドレスに向けて応答パケット を生成するはめになり, 犠牲となるマシンが飽和するところまで行っ てしまいます. 攻撃者が同じトリックを異なるネットワーク上のいく つものブロードキャストアドレスに対して同時に使用した場合, とく にひどいことになります. これまでに, 120 メガビット以上のブロー ドキャスト攻撃が観測されています. 2 番目の踏み台攻撃は, ICMP エラー報告の仕掛けを狙うものです. 攻撃者は ICMP エラー応答を生 成するパケットを生成し, サーバの受信ネットワークを飽和させ, そ の結果としてサーバが送信ネットワークを ICMP 応答で飽和させてし まうようにすることができます. mbuf を消費し尽くさせることによ り, この種の攻撃でサーバをクラッシュさせることも可能です. サー バが生成した ICMP 応答を十分速く送信できない場合, とくにひどい ことになります. FreeBSD カーネルには, この種の攻撃の効果を抑制 する ICMP_BANDLIM と呼ばれる新しいカーネルコンパイルオプション があります. 踏み台攻撃の 3 つめの主要なクラスに属する攻撃は, udp echo サービスのような, 特定の inetd 内部サービスに関連する ものです. 攻撃者は, 単に送信元アドレスがサーバ A の echo ポー トであり, 送信先アドレスがサーバ B の echo ポートであるように UDP パケットを偽造します. ここでサーバ A, B はともにあなたの LAN に接続されています. この 2 つのサーバは, この一つのパケッ トを両者の間で互いに相手に対して打ち返しあいます. このようにし てパケットをほんのいくつか注入するだけで, 攻撃者は両方のサーバ と LAN を過負荷状態にすることができます. 同様の問題が内部 chargen ポートにも存在します. 有能なシステム管理者はこの手の inetd 内部テストサービスのすべてを無効にしておくものです. 偽造パケット攻撃は, カーネルの経路情報キャッシュに過負荷を 生じさせるために用いられることもあります. net.inet.ip.rtexpire, rtminexpire, rtmaxcache の sysctl パラメータを参照して下さい. でた らめな送信元 IP アドレスを用いた偽造パケット攻撃により, カーネ ルは, 一時的なキャッシュ経路を経路情報テーブルに生成します. こ れは netstat -rna | fgrep W3 で見ることがで きます. これらの経路は, 普通は 1600 秒程度でタイムアウトになり ます. カーネルがキャッシュ経路テーブルが大きくなり過ぎたことを 検知すると, カーネルは動的に rtexpire を減らしますが, rtminexpire より小さくなるようには決して減らしません. ここに問 題が 2 つあります: 負荷の軽いサーバが突然攻撃された場合, カーネルが十分素 早く反応できないこと. カーネルが持続的攻撃に耐えられるほど十分 rtminexpire が低く設定されていないこと. 自分のサーバが T3 もしくはそれより高速の回線でインターネッ トに接続されている場合, &man.sysctl.8; を用いて rtexpire と rtminexpire とを手動で上書きしておくことが思慮深いことといえます. どちらか 一方でも 0 には決してしないで下さい (自分のマシンをクラッシュ させたくないのであれば :-). 両パラメータを 2 秒 に設定すれば, 攻撃から経路情報テーブルを守るには十分でしょう. Kerberos および SSH を用いたアクセスの問題 もしあなたが, kerberos および ssh を使用したいのだとしたら, 両者 に関して言っておく必要のある問題がいくつかあります. kerberos V は大変優れた認証プロトコルですが, kerberos 化された telnet や rlogin は, バイナリストリームを扱う のに不向きになってしまうようなバグがあります. さらに, デフォル トでは, kerberos は オプションを使わない限 りセッションを暗号化してくれません. ssh では, デフォルトですべてを暗号 化してくれます. ssh はあらゆる場面でとても良く 働いてくれます. ただし, デフォルトで暗号鍵を転送してしまうこと を除けばです. これはつまり, 暗号鍵を持った安全なワークステーショ ンがあって, この暗号鍵で残りのシステムとアクセスできるようになっ ている場合に, 安全でないマシンへ ssh を行なう時に暗号鍵が見えてしま うということです. 実際の鍵そのものが見えてしまうわけではありま せんが, ssh は, あなたが login して いる間, 転送用ポートを作ります. クラッカーが安全でないマシンの root を破ると, クラッカーは, このポートを使って暗号鍵を取得し, この暗号鍵でロックの外れる他のマシンへのアクセスを得ます. スタッフのログインには, kerberos を組み合せた ssh を使用することを勧めます. ssh は, kerberos サポート機能と一緒 にコンパイルできます. こうすると, 見えてしまうかもしれない ssh 鍵をあまりあてにしないで良いよ うになります. また, それと同時に, kerberos 経由でパスワードを 保護することもできます. ssh 鍵は, 安全なマシンからの自動化されたタスク (kerberos はこの用途には 不向きです) のみに使用するべきです. また, ssh の設定で鍵転送をしないようにす るか, あるいは, ssh が authorized_keys ファイル中に書くことを許 している from=IP/DOMAIN オプションを使用し て, 特定のマシンからログインしてきたときのみ鍵が有効であるよう にすることも勧めます. DES, MD5, と Crypt 改訂: &a.unfurl;, 21 March　 2000. 訳: &a.hanai;, 12 September 1996. 訳改訂: &a.jp.hino;, 12 March 2001. UNIX システムにおけるすべてのユーザは, そのアカウントに対応し た一つのパスワードを持っています. それらのパスワードはユーザ本人 と本当のオペレーティングシステムのみが知っているべきであるという ことは明らかでしょう. それらのパスワードを秘密に保っておくために, パスワードは一方向ハッシュとして知られる方式で暗 号化されます. 一方向ハッシュとは, 簡単に暗号化はできるが解読は難 しいという方法です. 言葉を換えると, 先ほど明らかであると書いたの は実は正しくないのです: オペレーティングシステム自身は 本当はパスワードを知らないのです. その代わりに 暗号化された形でのみパスワードを知っていま す.素のテキストとしてパスワードを得る唯一の方法は, 可能な限りのパスワード空間を検索するという力任せの方法です. 不幸なことに, UNIX が生まれようとしているときにパスワードを 安全な形で暗号化できる方式は DES(Data Encryption Standard) に基 づいたものだけでした. このことは米国に住んでいるユーザにとって は大して問題ではありませんでしたが, DES のソースコードを米国外に 輸出することはできないという問題がありました. そのために, FreeBSD は, 米国の法律を守ることと, 未だに DES を使っている他の UNIX 一族との互換性を保つこととを両立する方法を探し出す必要があ りました. その解決方法は, 米国のユーザは DES のライブラリをインストー ルして DES を使用できるが, 米国外のユーザは国外に輸出可能な他の ひとつの暗号化方式を使用することができる, というように暗号化ライ ブラリを分割することでした. これが FreeBSD がデフォルトの暗号化 方式として MD5 を使うようになったいきさつです. MD5 は DES よりも より安全であると考えられているため, DES をインストールする一番の 理由は互換性を保つためといえます. 暗号化機構を理解する FreeBSD がどの暗号化方式を使うようにセットアップされている かを判断するのは簡単です. /etc/master.passwd ファイルの中の暗号化さ れたパスワードを調べてみるのが一つの方法です. MD5 ハッシュで暗 号化されたパスワードは, DES ハッシュで暗号化されたパスワードよ りも長いですし, その上 $1$ と いう文字で始まるという特徴も持っています. DES のパスワードはこ れといって識別可能な特徴は持っていませんが, MD5 のパスワードよ りは短く, そして $ という文字を含ま ない 64 文字のアルファベットを使って表現されているので, 比較的 短い文字列でドル記号で始まっていないものはおそらく DES のパス ワードでしょう. 同様の方法で, ライブラリはパスワードを識別します. 結果とし て, DES のライブラリは MD5 パスワードを識別でき, そして MD5 を 使って MD5 で暗号化されたパスワードをチェックし, その他のパス ワードには DES を使ってチェックします. DES のライブラリは MD5 も含んでいるのでこのようなことが可能なのです. 残念なことに, 反 対は真ではありません. MD5 のライブラリは DES で暗号化されたパ スワードを認証することができません. あなたのシステムでプログラムがどちらのライブラリを使ってい るかを調べるのは非常に簡単です. crypt を使うプログラムは libcrypt をリンクしています. そしてそれぞれのライブラリに対す る適切な実装へのシンボリックリンクとなってい ます. たとえば, DES 版を使っているようなシステムにおいては次のようになっています: &prompt.user; ls -l /usr/lib/libcrypt* lrwxr-xr-x 1 root wheel 13 Mar 19 06:56 libcrypt.a -> libdescrypt.a lrwxr-xr-x 1 root wheel 18 Mar 19 06:56 libcrypt.so.2.0 -> libdescrypt.so.2.0 lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -> libdescrypt_p.a MD5 に基づいたライブラリを使っているシステムにおいては, 同 じようなリンクが 見られるでしょうが, そのターゲットは libdescrypt ではなく libscrypt になっているでしょう. もし DES 機能を持った crypt ライブラリ libdescrypt をインストールしたのなら (つ まり "crypt" ディストリビューションをインストールした場合), 新 規パスワードがどちらのパスワード形式になるかは, /etc/login.conf の中の passwd_format ログインケーパビリティによって制 御されます. その値としては, des または md5 を設定することができます. ログインケーパビ リティに関するより詳細な情報は, login.conf(5) マニュアルページ をご覧ください. S/Key S/Key は一方向ハッシュ関数を基にしたワンタイムパスワード方式 です. FreeBSD では, 互換性のために MD4 ハッシュを用いていますが 他のシステムでは MD5 や DES-MAC を用いてます. S/Key は, バージョ ン1.1.5 以降のすべての FreeBSD に含まれていますし, FreeBSD 以外 の数多くのシステムの上でも利用されています. S/Key ば Bell Communications Research, Inc. の登録商標です. 以下の説明では, 三種類の異なる「パスワード」が使われます. まず一つ目は, あなたが普段使っている普通の UNIX スタイルの, もし くは Kerberos でのパスワードです. ここではこれを UNIX パ スワードと呼ぶことにし ます. 二つ目は, S/Key の key プログラムによって生成され, keyinit プログラムとログインプロンプトが受け 付けるパスワードです. ここではこれをワンタイムパスワード と呼ぶことにします. 三つ目のパスワードは, key (と場合により keyinit) プログラムに対してユーザが入力する秘密のパスワードで, ワンタイム パスワードを生成するのに使われます. ここではこれを秘密の パスフレーズもしくは単に “パスフレーズ” と呼 ぶことにします. (訳注: ユーザが頭の中だけにしまっておくべきもの が, この秘密のパスフレーズです. なお, 原文ではこれをパスワードと 表記していますが, 混乱を避けるために訳文ではすべて 秘密の パスフレーズに統一しています.) 秘密のパスフレーズは, UNIX パスワードと何の関連性もありませ ん: 両者を同一に設定することは可能ですが, お奨めしません. UNIX パスワードは長さが 8 文字に制限されています (訳注: FreeBSD で DES を導入していない場合はもっと長いパスワードも認識されます). これに対し, S/Key では秘密のパスフレーズを好きなだけ長くすること ができます (訳注: 実装上, key コマンドなどの バッファ長で制限されてしまう可能性があります. 200 文字程度に押 えておいた方がよいでしょう :-). 6 語から 7 語からなるパスフレー ズがふつうです. ほとんどの部分で, S/Key システムは UNIX のパスワー ドシステムと完全に独立して動作するようになっています. パスフレーズに加え, S/Key システムにとって重要な二種類のデー タがあります. 一つはシード (seed: 種)または キー (key: 鍵)と呼ばれるもので, 二つの文字と五つ の数字で構成されます. もう一つはシーケンス番号 (iteration count) で, 1 から 100 までの整数です. S/Key はここまで に述べたデータを利用してワンタイムパスワードを生成します. その方 法は, まずシードと秘密のパスフレーズを連結し, それに対してシーケ ンス番号の回数だけ MD4 ハッシュを繰り返し計算します. そしてその 結果を 六つの短い英単語に変換します. login プ ログラムと su プログラムは, 前回最後に受け付 けられたワンタイムパスワードを記録しています. そして, その前回 のワンタイムパスワードと, ユーザが入力したワンタイムパスワードを 一回ハッシュ関数にかけた結果とが一致した場合に, このユーザは認証 されます. 一方向ハッシュ関数を使っているので, もし正しく認証され たワンタイムパスワードが一回盗聴されたとしても, 次回以降に使われ る複数のワンタイムパスワードを生成することは不可能です. シーケ ンス番号はログインが成功するたびに一つずつ減らされて, ユーザとロ グインプログラムの間で同期が取られます. シーケンス番号が 1 まで 減ったら, S/Key を再度初期化する必要があります. 次に, S/Key 関連の四つのプログラムについて説明します. key プログラムは, シーケンス番号一つと, シー ド一つと, 秘密のパスフレーズ一つとを受け付けて, ワンタイムパスワー ドを一つ生成します. keyinit プログラムは, S/Key を初期化するのに使用され, また秘密のパスフレーズやシーケン ス番号やシードを変更するためにも使用されます. このプログラムを実 行するには, 秘密のパスフレーズか, または, シーケンス番号とシード とワンタイムパスワードの一組かの, どちらかが必要になります. keyinfo プログラムは, /etc/skeykeys というファイルを調べて, この プログラムを起動したユーザの現在のシーケンス番号とシードを表示し ます. 最後に, login と su プログラムについてですが, これらは S/Key のワンタイムパスワード を, (訳注:システムが) ユーザを認証するものとして受理するのに必要 な処理をおこないます. login プログラムは, 指 定された特定のアドレスからの接続に対して, UNIX パスワードの使用 を認めなくする機能, 逆に言えば S/Key の利用を強制する機能も持っ ています. この文書では, 四種類の異なる操作について説明します. 一つ目は, keyinit プログラムを信頼できる通信 路上で利用する場合で, 一番始めに S/Key を設定する操作や, 使い始 めたあとで秘密のパスフレーズやシードを変更する操作です. 二つ目は, keyinit プログラムを信頼できない通信路上で利 用する場合で, 操作の目的は一つ目と同じです. この場合には key プログラムを併用する必要があります. 三つ 目は, key プログラムを使い, 信頼できない通信 路を通じてログインする操作です. 四番目は, key プログラムを使って, 複数のワンタイムパスワードを一気に生成する操 作です. ここで生成した複数のワンタイムパスワードは, メモしたり 印刷したりして携帯し, 信頼できる通信路が一切ないところで利用する ことができます. (訳注: ワンタイムパスワードを記録した紙をなくさ ないこと! 電話番号やIPアドレス, ユーザ名を一緒にメモしていたら 最悪です!!) 信頼できる通信路での初期化 信頼できる通信路 (たとえばあるマシンのコンソール画面や, ssh を使っている時など) を利用しているときに, S/Key を初めて初期化 すること, S/Key の秘密のパスフレーズを変更すること, またはシー ドを変更すること, をおこなうことができます. そのためには, まず あなた自身がログインし, keyinit コマンドを 以下のようにパラメタなしで実行します: &prompt.user; keyinit Adding unfurl: Reminder - Only use this method if you are directly connected. If you are using telnet or rlogin exit with no password and use keyinit -s. ) `keyinit' コマンドが出力する注意です. 訳すと, ) 注意 - この動作モードはマシンに直接入力しているときのみ利用 ) すること. もし今 telnet や rlogin を使っているなら, 秘密のパ ) スフレーズを入力せずにこのままコマンドを終了し, かわりに ) keyinit -s を実行すること. Enter secret password: Again secret password: ID unfurl s/key is 99 to17757 DEFY CLUB PRO NASH LACE SOFT Enter secret password: というプロンプトに 対してあなたが考えた秘密のパスフレーズを入力します. このパスフ レーズはログインするときに使うものではなく, ログインするときに 使うワンタイムパスワードを生成するために使うものであることを覚 えておいてください. ID から始まる行は, S/Key に おける一回分のパラメタであり, あなたのログイン名とシーケンス番 号とシードです. (訳注: `keyinit' コマンドは 次回にログインするときに使えるパラメタを参考のためにここで表示 します.) S/Key を使ってログインするときには, システム側が自動 的にこれらのパラメタを表示してくれますから, これらのパラメタを 覚えておく必要はありません. 最後の行が, 今述べたパラメタと入力 された秘密のパスフレーズから計算されたワンタイムパスワードです. この例を実行した後, 次にログインするときに打ち込むべきワンタイ ムパスワードがこれです. 信頼できない通信路での初期化 信頼できない通信路を使って S/Key を初期化, または秘密のパ スフレーズを変更するためには, 信頼できる通信路として, その信頼 できない通信路とは別のものを用意する必要があります. その信頼で きる通信路は key プログラムを実行するために 必要となるもので, たとえばそれは, あなたが信頼できる Macintosh のデスクアクセサリや信頼できるマシンのシェルプロンプトだったり するでしょう. (訳注: ここでの通信路とはマシンそのものになりま す. 信頼できるマシンとは, 信頼できる人がしっかり管理しているマ シンということです.) 他に準備しておくものとして, シーケンス番 号 (100 は適切な値といえるでしょう) と, 場合によっては自分で考 えた, またはランダムに生成されたシードがあります. (あなたが S/Key を初期化しようとしているマシンへの) 信頼できない通信路を 使うときには, keyinit -s コマンドを以下のよ うに使用します: &prompt.user; keyinit -s Updating unfurl: Old key: to17758 Reminder you need the 6 English words from the key command. ) `keyinit' コマンドが出力する注意です. 訳すと, ) 注意 - skey コマンドの出力する 6 英単語が必要になります. Enter sequence count from 1 to 9999: 100 Enter new key [default to17759]: s/key 100 to 17759 s/key access password: デフォルトのシード (keyinit プログラム は困ったことにこれを key と読んでいるのです が, 混乱しないよう注意してください) で構わなければ, リターンキー を押してください. 次に, アクセスパスワードを入れる前に, あらか じめ用意しておいた信頼できる通信路(信頼できるマシンや信頼でき る S/Key デスクアクセサリなど) へ移って, 先ほどと同じパラメタ を入力します: &prompt.user; key 100 to17759 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: <秘密のパスフレーズ> CURE MIKE BANE HIM RACY GORE ここで信頼できない通信路の方に戻って, key コマンドが出力したワンタイムパスワード をコピーして keyinit プログラムに入力します. s/key access password:CURE MIKE BANE HIM RACY GORE ID unfurl s/key is 100 to17759 CURE MIKE BANE HIM RACY GORE 後は, 前章で説明したことと同様です. ワンタイムパスワードを一つ生成する S/Key の初期化ができたら, ログインするときには以下のような プロンプトが出てくるでしょう: &prompt.user; telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: <ユーザ名> s/key 97 fw13894 Password: ここでは表示していませんが, 便利な機能がログインプログラム に備わっています: パスワードプロンプトに対して, 何も入力せずに リターンを押すとエコーモードに切り替わります. つまりタイプし た文字がそのまま見えるようになるのです. これはS/Key のワンタイ ムパスワードを紙に印刷していた場合など, ワンタイムパスワードを 手で入力しなければならない場合に特に役立つ機能です. また, この ログインしようとしてるマシンが, 接続元のマシンから UNIX パスワードを使ってログインすることができないように設定さ れている場合には, ログインプロンプトには S/Key のワンタイムパ スワードのみが受け付けられることを示す (s/key required) という注釈が表示されます. 次に, このログインプロンプトに対して入力するためのワンタイ ムパスワードを生成しましょう. そのために, key プログラムを使える信頼できるマシンを用 意します. (key プログラムには DOS や Windows の上で動くもの, MacOS の上で動くものなどもあります.) key プログラムを使うときには, シーケンス番 号とシードを指定します. ログインしようとしているマシンのログ インプロンプトの右側をカットアンドペーストすると楽でしょう. 信頼できるシステムで: &prompt.user; key 97 fw13894 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: WELD LIP ACTS ENDS ME HAAG ここでワンタイムパスワードが得られました. ログインを続けま しょう: login: <username> s/key 97 fw13894 Password: <return to enable echo> s/key 97 fw13894 Password [echo on]: WELD LIP ACTS ENDS ME HAAG Last login: Tue Mar 21 11:56:41 from 10.0.0.2 ... 以上の手順は, 信頼できるマシンが利用できる場合の みに使えるもっとも簡単な方法です. Java による S/Key の key applet もあり, The Java OTP Calculator からダウンロードして Java をサポートするブ ラウザ上でローカルに実行することができます. 複数のワンタイムパスワードを生成する 都合によっては, 信頼できるマシンや信頼できる通信路が一切確 保できないようなところで S/Key を使う必要があるでしょう. この ような場合には, key コマンドを使って複数の ワンタイムパスワードをあらかじめ一気に生成し, 紙に印刷して携帯 していくことができます. たとえば: &prompt.user; key -n 5 30 zz99999 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: <秘密のパスフレーズ> 26: SODA RUDE LEA LIND BUDD SILT 27: JILT SPY DUTY GLOW COWL ROT 28: THEM OW COLA RUNT BONG SCOT 29: COT MASH BARR BRIM NAN FLAG 30: CAN KNEE CAST NAME FOLK BILK という引数によって 5 個のワンタイム パスワードを順に生成します. ここで は, 最 後のシーケンス番号となるべき数字です. 出力は普通に使う順番とは 逆に出力されていることに注意してください (訳注: 一番最初に使うワンタイムパスワードは一番最後に出力され たものです). この結果をカットアンドペーストして lpr コマンドを使って印刷すると よいでしょう. もしあなたがセキュリティに偏執するなら, この結果を紙と鉛筆を使っ て手で書き移した方がよいかもしれません. ここで, 出力の各行はシー ケンス番号とそれに対応する一回分のワンタイムパスワードです. 消費済みの ワンタイムパスワードの行をペンで消していくと便利で しょう. UNIX パスワードの利用を制限する 設定ファイル /etc/skey.access を使っ て UNIX パスワードの利用を制限することができます. この場合の判 断基準として, ログインを受け付ける際のホスト名, ユーザ名, 端末 のポート, IP アドレスなどが利用できます. この設定ファイルの詳 細に関してはマニュアル &man.skey.access.5; をご覧ください. マ ニュアルにはこの機能に関わるセキュリティについて, いくつかの警 告が記述してあります. この機能を使ってセキュリティを高めようと するのならば絶対にこのマニュアルを読んでください. もし /etc/skey.access ファイルが存在 しないならば (FreeBSD のデフォルト状態ではそうです), すべての ユーザが UNIX パスワードを利用することができます. 逆に, もし ファイルが存在するならば, skey.access ファ イルに明示的に記述されていない限り, すべてのユーザは S/Key の 利用を要求されます. どちらの場合においても, そのマシンのコンソー ルからはいつでも UNIX パスワードを使ってログインすることが可能 です. 以下によく使われるであろう三種類の設定を含む設定ファイルの 例を示します: permit internet 192.168.0.0 255.255.0.0 permit user fnord permit port ttyd0 はじめの行 (permit internet) で, telnet などで接続するときの IP のソースアドレス (注意: これは偽造され るおそれがあります) が特定の値とマスクに一致している場合に, UNIX パスワードの利用を許可することを指定しています. この設定 自体はセキュリティを高めるための機能ではありません. そうでは なく, ログインの権利を持つ許可されたユーザに対して, 現在そのユー ザが使っているネットワークが信頼できないと考えられるので S/Key を使うべきである, ということを気づかせるための機能であると考え てください. 二行目 (permit user) によって, ある特定 のユーザ, この場合は fnord, に対して, いつ でも UNIX パスワードの利用を許可するように指定しています. 一般 的にはこの設定をおこなうべきではありません. key プログラムがどうしても使えない環境にい る人や, ダム端末しかない環境にいる人, または何度教えても聞く耳 を持たないような人をサポートする必要がある場合にのみ設定をおこ なってください. 三行目 (permit port) によって, ある特定 の端末ポートからログインしようとするすべてのユーザに対して UNIX パスワードの利用を許可するように指定しています. この設定 はダイヤルアップ回線に対する設定として利用できるでしょう. Kerberos 原作: &a.markm; - (&a.md; からの寄稿に基づいています). + (Mark Dapoz md@bsc.no + からの寄稿に基づいています). 訳: &a.jp.arimura;. Kerberosは, サーバのサービスによってユーザが安全に認証を受けられる ようにするための, ネットワークの付加システム及びプロトコルです. リモートログイン, リモートコピー, システム間での安全なファイルのコピ ーやその他のリスクの高い仕事がかなり安全に, そしてこれまでより制御 できるようになります. 以下の文章は, FreeBSD用として配布されているKerberosをセットアップ する際のガイドとして読むことができます. しかし, 完全な説明が必要な場合には, マニュアルページを読んだ方がよい でしょう. FreeBSDのKerberosは, オリジナルの4.4BSD-Liteの配布に含まれているものではなく, FreeBSD 1.1.5.1のときに移植されたeBonesです. これはアメリカ/カナダの外で作成されており, そのため, アメリカか らの暗号技術の輸出制限があった時代でも, これら以外の国の人々が手に入れられるものでした. 初期データベースの作成 この作業はKerberosサーバだけでおこないます. まず, 古いKerberosの データベースが存在しないことを確認してください. ディレクトリ/etc/kerberosIVに移って, 次のファイルだけが 存在することをチェックします: &prompt.root; cd /etc/kerberosIV &prompt.root; ls README krb.conf krb.realms もし他のファイル (principal.* や master_key) が 存在する場合には, kdb_destroyというコマンドで古い Kerberosデータベースを消してください. Kerberosが走っていなければ, 単に余計なファイルを消せばよいです. まず, krb.conf と krb.realmsを編集してKerberosの 管理領域 (realm) を定義してください. ここでは管理領域がGRONDAR.ZA で, サーバ名がgrunt.grondar.zaであるとします. krb.conf というファイルを次のように編集してください: &prompt.root; cat krb.conf GRONDAR.ZA GRONDAR.ZA grunt.grondar.za admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov この例にあるような他の管理領域は, 実際には必要ありません. この例は複数の管理領域を認識する方法を示したものですので, これらの行は含めなくても結構です. 1行目はこのシステムが動いている管理領域の名前です. 他の行は管理領域とホスト名のエントリです. 行の1つめの単語が管理領域で, 2つめがその管理領域の中で 鍵配布センター(Key Distribution Center) として働くホスト名です. ホスト名の次に admin server と書いてある場合には, そのホストが ``管理データベースサーバ''(Administrative Database Server) も提供 することを意味します. これらの単語について詳しく知りたい場合にはKerberosのマニュアル ページをご覧ください. ここで, GRONDAR.ZAという管理領域にgrunt.grondar.za およびその他の.grondar.za ドメインのすべてのホストを追加し なければなりません. krb.realmsは次のようになります: &prompt.root; cat krb.realms grunt.grondar.za GRONDAR.ZA .grondar.za GRONDAR.ZA .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU もう一度注意しますが, 他の管理領域を書く必要はありません. これらは複数の管理領域を認識できるようにマシンを設定する方法を 示した例ですので, これらの行は消して構いません. 1行目は名前をつけた管理領域に 特定の システムを含めるための ものです. 残りの行は名前をつけた管理領域にサブドメインのデフォルトの システムを含めるためのものです. これでデータベースを作成する準備ができました. この操作はKerberos サーバ (鍵配布センター) を起動するだけです. kdb_initコ マンドを次のように実行してください: &prompt.root; kdb_init Realm name [default ATHENA.MIT.EDU ]: GRONDAR.ZA You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter Kerberos master key: ここで鍵を保存して, ローカルのマシンにあるサーバが取り出せるように します. それにはkstashコマンドを使用します. &prompt.root; kstash Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! これで暗号化されたマスタパスワードが /etc/kerberosIV/master_key に保存されました. すべてが動くようにするための設定 Kerberosを導入する それぞれの システムのデータベースに, 2つ のprincipal (主体名) を追加する必要があります. その名前は kpasswdとrcmdです. これら2つのprincipalは, 個々 のシステムにおいて, システム名と同じ名前のインスタンスと組にして作成 されます. これらの kpasswd と rcmd というデーモンによって, 他の システムからKerberosのパスワードを変更したり, rcpや rlogin, rshといったコマンドを実行したりできるよ うになります. それでは実際にこれらのエントリを追加しましょう: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: passwd Instance: grunt <Not found>, Create [y] ? y Principal: passwd, Instance: grunt, kdc_key_ver: 1 New Password: <---- ここは「RANDOM」と入力してください Verifying password New Password: <---- ここは「RANDOM」と入力してください Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd Instance: grunt <Not found>, Create [y] ? Principal: rcmd, Instance: grunt, kdc_key_ver: 1 New Password: <---- ここは「RANDOM」と入力してください Verifying password New Password: <---- ここは「RANDOM」と入力してください Random password [y] ? Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- 何も入力しないと終了します サーバファイルの作成 次に, 各マシンにおけるサービスを定義している, すべてのインスタンス を展開します. これにはext_srvtabというコマンドを使用しま す. このコマンドで作成されるファイルは, Kerberosの各クライアン トの/etc/kerberosIVディレクトリに 安全な方法でコピーまたは 移動する必要があります. このファイルはそれぞれのサーバとクラ イアントに存在しなければならず, またKerberosの運用において重要なも のです. &prompt.root; ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'.... このコマンドは一時的なファイルを作成するだけです. ファイル名をすべ てのサーバが読めるような srvtab という名前に変更しな ければなりません. mvコマンドを用いてシステムの場所に移動 してください. &prompt.root; mv grunt-new-srvtab srvtab そのファイルがクライアントに配るためのもので, ネットワークが安全で はないと思われる場合には, client-new-srvtab を移動 可能なメディアにコピーして物理的に安全な方法で運んでください. クラ イアントの/etc/kerberosIVディレクトリで, 名前を srvtabに変更し, modeを600にするのを忘れないでください: &prompt.root; mv grumble-new-srvtab srvtab &prompt.root; chmod 600 srvtab データベースへのユーザの追加 ここで, ユーザのエントリをデータベースに追加する必要があります. 始めに, ユーザjaneのエントリを作成してみましょう. kdb_edit を用いて次のように作成してください: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: <Not found>, Create [y] ? y Principal: jane, Instance: , kdc_key_ver: 1 New Password: <---- 安全なパスワードを入れてください Verifying password New Password: <---- もう一度パスワードを入れてください Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- 何も入力しないと終了します すべてのテスト まず始めにKerberosデーモンを起動する必要があります. /etc/rc.conf ファイルを正しく編集してあれば, マシンを再 起動することでに自動的にデーモンが起動します. これはKerberosサー バでのみ必要です. Kerberosクライアントは/etc/kerberosIVか ら必要なものを自動的に入手します. &prompt.root; kerberos & Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 Local realm: GRONDAR.ZA &prompt.root; kadmind -n & KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead Current Kerberos master key version is 1. Master key entered. BEWARE! さあ, これで上で作成した jane というIDのチケットを kinitコマンドで得ることができます: &prompt.user; kinit jane MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane" Password: klist コマンドを用いてトークンを見て, きちんとチケットを持って いるかどうか確認してください: &prompt.user; klist Ticket file: /tmp/tkt245 Principal: jane@GRONDAR.ZA Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA passwd コマンドを用いてパスワードを変更して, kpasswdデーモ ンがKerberos データベースに対して認証されるかどうかチェックして ください: &prompt.user; passwd realm GRONDAR.ZA Old password for jane: New Password for jane: Verifying password New Password for jane: Password changed. <command>su</command>特権の追加 root権限が必要なユーザは誰でも, suコマンドのパス ワードをユーザ毎に別のもの として持つことができます. rootにsu できる権利を与えられたidを追加します. これは, principalに付いているroot というインスタンスに よって制御されています. kdb_editを用いて jane.rootというエントリを Kerberosデータベースに作成します: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: root <Not found>, Create [y] ? y Principal: jane, Instance: root, kdc_key_ver: 1 New Password: <---- 安全なパスワードを入れます Verifying password New Password: <---- もう一回パスワードを入れます Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- ここは短くしてください Attributes [ 0 ] ? Edit O.K. Principal name: <---- 何も入力しないと終了します 実際にトークンをもらって, ちゃんと働いているかどうか確認しましょう: &prompt.root; kinit jane.root MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane.root" Password: ここでrootユーザの .klogin ファイルにユーザを追加する必要が あります. &prompt.root; cat /root/.klogin jane.root@GRONDAR.ZA suしてみましょう: &prompt.user; su Password: どのトークンを持っているか見てみましょう: &prompt.root; klist Ticket file: /tmp/tkt_root_245 Principal: jane.root@GRONDAR.ZA Issued Expires Principal May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA 他のコマンドの使用 ここまでの例では, jane という principal を root とい うインスタンス付きで作成しました. これはユーザと同じ名前をprincipalと しており, Kerberosのデフォルトの値です; <username>.root という形式の <principal>.<instance>で, 必要なエント リがrootのホームディレクトリの .kloginファイルに あれば, <username>がrootに suすることができま す. &prompt.root; cat /root/.klogin jane.root@GRONDAR.ZA 同様に, ユーザのホームディレクトリの .kloginファイルに次の ような行がある場合には: &prompt.user; cat ~/.klogin jane@GRONDAR.ZA jack@GRONDAR.ZA jane または jack という名前で (前述のkinit によって) 認証されている GRONDAR.ZA という管理領域のユーザ なら誰でもrlogin や rsh, rcp等によってこ のシステム (grunt) のjaneのアカウントまたはファ イルにアクセスできます. たとえば, Janeが他のシステムにKerberos を用いてloginします: &prompt.user; kinit MIT Project Athena (grunt.grondar.za) Password: &prompt.user; rlogin grunt Last login: Mon May 1 21:14:47 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 次の例では, Jackが同じマシンの Jane のアカウントにloginします. Janeは .klogin ファイルを前述のように設定しており, Kerberosではjackというprincipal をインスタンスなしで設定してあ ります. &prompt.user; kinit &prompt.user; rlogin grunt -l jane MIT Project Athena (grunt.grondar.za) Password: Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 ファイアウォール 原作: &a.gpalmer;, Alex Nash;. 訳: &a.jp.saeki;. 11 November 1996. ファイアウォールは, インターネットに参加している人はもちろんのこと, プライベートネットワークのセキュリティ向上のための アプリケーションを 探している人にとっても, ますます興味深くなりつつある分野です. このセクションではファイアウォールとは何か, ファイアウォールの使用法, そしてファイアウォールを構築するために FreeBSD のカーネルで 提供されているファシリティ (機能) の使用法について説明したいと思います. 社内のネットワークと 巨大かつ信頼のおけない インターネットとの間にファイアウォールを構築することで セキュリティ上のすべての問題が解決できると考える人がいます. ファイアウォールはセキュリティ上の問題を 解決する助けになる場合もありますが, 充分な設定がなされていないファイアウォールは, まったくファイアウォールを 持たない場合よりもセキュリティ上の危険を増大させてしまいます. ファイアウォールにできることは, あなたのシステムにもう一つのセキュリティ層を 追加することだけで, 本気でアタックをしかけてくるクラッカーが内部ネットワークに 侵入するのを妨げることはできません. ファイアウォールを侵入不可能と過信して 内部のセキュリティをおろそかにすることは, 単にクラッカーの仕事を少し簡単にするだけでしか ありません. ファイアウォールとは何か ? 現在インターネットで普通に使用されている ファイアウォールには 二つの異なるタイプがあります. 一つは, 厳密には パケットフィルタリングルータ と 呼ばれるタイプのものです. これはマルチホームのホストマシン (複数の ネットワークに接続されているマシン) のカーネルが, ある規則にしたがって パケットを転送したりブロックしたりするものです. もう一つは, proxy (代理) サーバ として知られているタイプのものです. これは, おそらくはマルチホームのホストマシン上で, カーネルによるパケット転送を 禁止して, デーモンにより認証の提供とパケットの転送とを おこなうものです. 二つのタイプのファイアウォールを組み合わせて使用して, 特定のマシン ( 要塞ホスト と呼ばれる) だけが パケットフィルタリングルータを通して内部ネットワークへ パケットを送ることができるよう設定している サイトがしばしば存在します. proxy (代理) サービスは通常の認証機構よりもセキュリティを 強化してある 要塞ホストで動作させます. FreeBSD は (IPFW として知られる) カーネルパケットフィルタ込みで 提供されています. このセクションの後の方では, このフィルタについての 説明を集中しておこないます. サードパーティから提供されるソフトウェアを使用することにより, Proxy サーバを FreeBSD 上に構築することができます. しかし, 現在入手可能な proxy サーバは たいへんバラエティに富んでいるので, このドキュメントでそれらすべてを カバーすることは不可能です. パケットフィルタリングルータ ルータとは, 二つまたはそれ以上のネットワークの間で パケットの転送をおこなう マシンのことです. パケットフィルタリングルータは, そのカーネルの内部に, 一つ一つのパケットをルールリストと比較して 転送するかしないかを決める 特別なコードを持っています. 最近の IP ルーティングソフトウェアのほとんどは, 内部に パケットのフィルタリングをおこなうためのコードを持っていて, デフォルトでは すべてのパケットを転送するようになっています. このフィルタを有効にするためには, パケットの通過を許すべきかどうかを決める ルールを自分で定義する必要があります. パケットを通すべきか通すべきでないかを決めるために, パケットヘッダの内容にマッチするものが ルールリストから探されます. マッチするルールが見つかると, ルールアクションが実行されます. ルールアクションには, パケットを捨てる, パケットを転送する, またはパケットの発信元に ICMP メッセージを送り返すというものがあります. ルールの検索は先頭から順番におこなわれ, 通常は最初にマッチしたものだけが 適用されます. そのため, このルールリストはルールチェーン と呼ばれることもあります. パケットマッチングの基準は使用するソフトウェアに よって異なりますが, 通常はパケットの発信元 IP アドレス, 宛先 IP アドレス, 発信元ポート番号, 宛先ポート番号 (ポート番号はポートをサポートするプロトコルの場合のみ), パケットタイプ (UDP, TCP, ICMP など) に基づくルールを指定することができます. Proxy サーバ Proxy サーバとは通常のシステムデーモン (telnetd, ftpd など) を 特別なサーバで置き換えたマシンのことです. これらのサーバは, 通常は中継をおこなって特定方向への接続だけを許すため, proxy サーバ と呼ばれます. (たとえば) proxy telnet サーバをファイアウォールホストで走らせておきます. 外部からユーザがファイアウォールに対して telnet を実行すると, proxy telnet サーバが応答して, 何らかの認証機構を実行します. これを通過した後で, 内部ネットワークへのアクセスがおこなえるように なるのです. (内部ネットワークからの信号は proxy サーバがかわりに受け取り, 外へ向けて送り出します.) Proxy サーバは通常, 普通のサーバより堅固に構築されていて, しばしば 使い捨てパスワードシステムなどを含む, 多様な認証機構を持っています. 使い捨てパスワードシステムとは, どういうものなのでしょうか. 仮に誰かが何らかの方法で, あなたが使用したパスワードを手に入れたとします. しかし, 一度使用したことで, そのパスワードは既に無効になっているのです. ですから, そのパスワードをもう一度使用したとしても, あなたのシステムへ アクセスすることはできないというわけです. これらのサーバは中継をおこなうだけで, 実際のところサーバホスト自身への アクセスをユーザに許してはいません. そのため, 何者かがセキュリティシステムに 侵入用の裏口を取り付けることは, より困難になっています. proxy サーバはアクセス制限の方法をいくつも持っていて, 特定のホスト だけがサーバへのアクセス権を得ることができるように なっていることがあり ます. そして目的のマシンと通信できるユーザを制限するように 設定することもできます. もう一度言いますが, どんなファシリティ (機能) が使えるかは, どんな proxy サービスをおこなうソフトウェアを選ぶかに大きく 依存します. IPFW で何ができるか FreeBSD とともに配布されている IPFW は, カーネル内部にあって パケットのフィルタリングとアカウンティングを おこなうシステムであり, ユーザ側のコントロールユーティリティである &man.ipfw.8; を 含んでいます. ルーティングの決定をおこなう際に, これらは互いに協力して, カーネルで使用されるルールを定義したり, 現在使用されているルールを 問い合わせたりすることができます. IPFW は互いに関連する二つの部分からなっています. ファイアウォールセクションは パケットフィルタリングをおこないます. また, IP アカウンティングセクションはファイアウォールセクションのものと 似たルールに基づいてルータの使用を追跡します. これにより, (たとえば) 特定のマシンからルータへのトラフィックがどのくらい 発生しているか調べたり, どれだけの WWW (World Wide Web) トラフィックが フォワードされているかを知ることができます. IPFW は, ルータではないマシンにおいても入出力コネクションの パケットフィルタリングのために 使用することができるように設計されています. これは一般的な IPFW の使用法とは異なる特別な使い方ですが, こういった状況でも同じコマンドと テクニックが使用されます. FreeBSD で IPFW を有効にする IPFW システムの中心となる部分はカーネル内部にあります. そのため, どのファシリティ (機能) を必要とするかによって, 一つまたは それ以上のオプションをカーネルコンフィグレーション ファイルに追加し, カーネルを再コンパイルする必要があるでしょう. カーネルの再コンパイル方法の詳細については, カーネルコンフィグレーション を参照してください. 現在, IPFW に関係するカーネルコンフィグレーションオプションは 三つあります: options IPFIREWALL パケットフィルタリングのためのコードを カーネルに組み込みます. options IPFIREWALL_VERBOSE &man.syslogd.8; を通じて パケットのログを取るためのコードを有効にします. フィルタルールでパケットのログを取るように指定しても, このオプションが指定されていなければ, ログを取ることはできません. options IPFIREWALL_VERBOSE_LIMIT=10 &man.syslogd.8; を通じて ログを取るパケットの数をエントリ毎に制限します. 敵対的な環境においてファイアウォールの 動作のログを取りたいけれど, syslog の洪水によるサービス拒絶攻撃に対し 無防備でありたくないという場合に, このオプションを使用したいと思うことが あるかもしれません. チェーンエントリのログが指定された制限数に達すると, そのエントリに関するログ取りは停止されます. ログ取りを再開するには, &man.ipfw.8; ユーティリティを使用して 関連するカウンタをリセットする必要があります: &prompt.root; ipfw zero 4500 4500 とは, ログ取りを続行したいチェーンエントリの番号です. 以前のバージョンの FreeBSD は IPFIREWALL_ACCT というオプションを 持っていました. しかし, ファイアウォールコードがアカウンティングファシリティ (機能) を 自動的に含むようになったため, 現在では使用されることはなくなっています. IPFW の設定 IPFW ソフトウェアの設定は &man.ipfw.8; ユーティリティを 通じておこないます. このコマンドの構文は非常に 複雑に見えますが, 一旦その構造を理解すれば比較的単純です. このユーティリティでは今のところ四つの異なる コマンドカテゴリが 使用されています: それは追加 / 削除, 表示, フラッシュ, およびクリアです. 追加 / 削除はパケットの受け入れ, 拒絶, ログ取りをどのようにおこなうか というルールを構築するのに使用します. 表示はルールリスト (またはチェーン) と (アカウンティング用) パケットカウンタの 内容を調べるのに使用します. フラッシュはチェーンからすべてのエントリを 取り除くのに使用します. クリアは一つまたはそれ以上のアカウンティングエントリを ゼロにするのに 使用します. IPFW ルールの変更 この形式での使用法は: ipfw -N コマンド index アクション log プロトコル アドレス オプション この形式で使用する際に有効なフラグは一つだけです: -N アドレスやサービス名を 文字列に変換して表示します. コマンド は一意である限り短縮可能です. 有効な コマンド は: add ファイアウォール / アカウンティングルールリストに エントリを追加します. delete ファイアウォール / アカウンティングルールリストから エントリを削除します. 以前のバージョンの IPFW では, ファイアウォールエントリと パケットアカウンティングエントリが別々に利用されていました. 現在のバージョンでは, それぞれのファイアウォールエントリ毎に パケットアカウンティングエントリが備えられています. index が指定されていると, エントリはチェーン中の index で示される位置に置かれます. index が指定されて いなければ, エントリは (65535 番のデフォルトルールである パケット拒絶を別にして) 最後のチェーンエントリの index に 100 を足した 位置 (チェーンの最後) に置かれます. カーネルが IPFIREWALL_VERBOSE つきでコンパイルされている場合, log オプションはマッチしたルールを システムコンソールに出力させます. 有効な アクション は: reject パケットを捨てます, ICMP ホスト / ポート到達不能パケットを (適切な方を) 発信元へ送ります. allow 通常通りパケットを通過させます. (別名: pass および accept) deny パケットを捨てます. 発信元は ICMP メッセージによる 通知を受けません (そのためパケットが 宛先に到達しなかったように見えます). count このルールはパケットカウンタを更新するだけで, パケットを 通過させたり拒絶したりしません. 検索は次のチェーンエントリから続けられます. それぞれの アクション は一意な先頭部分だけでも認識されます. 指定可能な プロトコル は以下の通り: all 任意の IP パケットにマッチします. icmp ICMP パケットにマッチします. tcp TCP パケットにマッチします. udp UDP パケットにマッチします. アドレス の指定は: from address/mask port to address/mask port via interface port はポートをサポートする プロトコル (UDP と TCP) の 場合にだけ指定可能です. は必須ではなく, 特定のインターフェースを通ってきたパケット だけにマッチするように, IP アドレスまたはローカル IP インターフェースの ドメイン名, またはインターフェース名 (たとえば ed0) を 指定することができます. インターフェースユニット番号はオプションで, ワイルドカードで指定することが できます. たとえば, ppp* はすべてのカーネル PPP インターフェースに マッチします. address/mask の指定は: address または address/mask-bits または address:mask-pattern IP アドレスのかわりに有効なホスト名を指定することも可能です. はアドレスマスクで上位何ビットを１にするべきかを 示す十進数値です. たとえば次の指定, 192.216.222.1/24 はクラス C のサブネット (この場合 192.216.222) の任意のアドレスにマッチする マスクを作成します. は与えられたアドレスと 論理 AND される IP アドレスです. キーワード any は任意の IP アドレスを指定するために 使用することができます. ブロックするポート番号は以下のように指定します: port, port, port… のように単独のポートまたはポートのリストを指定します. または port- port のようにポートの範囲を指定します. 単独のポートとポートのリストを 組み合わせて指定することも可能ですが, その場合は常に範囲の方を 最初に指定しなければなりません. 使用可能な オプション は: frag データグラムの最初の フラグメントでなければマッチします. in 入力途中のパケットであればマッチします. out 出力途中のパケットであればマッチします. ipoptions spec IP ヘッダが spec に指定された カンマで区切られた オプションのリストを含んでいればマッチします. サポートされている IP オプションのリストは: ssrr (ストリクトソースルート), lsrr (ルーズソースルート), rr (レコードパケットルート), そして ts (タイムスタンプ) です. 特定のオプションを含まないことを指定するには ! を先頭につけます. established パケットが既に確立されている TCP コネクションの一部であれば (つまり RST または ACK ビットがセットされていれば) マッチします. established ルールをチェーンの最初の方に置くことで, ファイアウォールのパフォーマンスを向上させることが できます. setup パケットが TCP コネクションを確立しようとするものであれば (SYN ビットがセットされ ACK ビットはセットされていなければ) マッチします. tcpflags flags TCP ヘッダが flags に指定された カンマで区切られたフラグの リストを含んでいればマッチします. サポートされているフラグは, fin, syn, rst, psh, ack と urg です. 特定のフラグを含まないことを指定するには ! を先頭につけます. icmptypes types ICMP タイプが types リストに 存在していればマッチします. リストはタイプの範囲または個々のタイプを カンマで区切った任意の組合せで指定できます. 一般的に使用されている ICMP タイプは: 0 エコーリプライ (ping リプライ), 3 相手先到達不可能, 5 リダイレクト, 8 エコーリクエスト (ping リクエスト), そして 11 時間超過 (&man.traceroute.8; で使用されているように, TTL 満了を示すのに使用されます) です. IPFW ルールリストの表示 この形式での使用法は: ipfw -a -t -N l この形式で使用する際に有効なフラグは三つあります: -a リスト表示の際にカウンタの値も表示します. このオプションは アカウンティングカウンタの 内容を見る唯一の手段です. -t 各チェーンエントリが最後に マッチした時刻を表示します. この時刻表示は &man.ipfw.8; ユーティリティで使用される入力形式と 互換性がありません. -N (可能であれば) アドレスやサービス名を文字列に変換して表示します. IPFW ルールのフラッシュ チェーンをフラッシュするには: ipfw flush カーネルに固定されているデフォルトルール (インデックス 65535 番) 以外の, ファイアウォールチェーンの中のすべてのエントリを削除します. デフォルトではすべてのパケットが拒絶されるので, 一旦これを実行すると, パケットを許可するエントリがチェーンに追加されるまで, あなたのシステムがネットワークから切り放されてしまいます. そのため, ルールのフラッシュをおこなうときは注意が必要です. IPFW パケットカウンタのクリア 一つまたはそれ以上のパケットカウンタをクリアするためには: ipfw zero index index が指定されていなければ, すべてのパケットカウンタが クリアされます. index が指定されていれば, 特定のチェーンエントリだけが クリアされます. ipfw に対するコマンドの例 このコマンドは, ホスト evil.crackers.org から ホスト nice.people.org の telnet ポートへの すべてのパケットを拒絶します: &prompt.root; ipfw add deny tcp from evil.crackers.org to nice.people.org 23 次の例は, ネットワーク crackers.org (クラス C) 全体から マシン nice.people.org (の任意のポート) への 任意の TCP トラフィックを拒絶し, ログを取ります. &prompt.root; ipfw add deny log tcp from evil.crackers.org/24 to nice.people.org あなたの内部ネットワーク (クラス C のサブネット) に対する X セッションを 張れないようにする場合, 以下のコマンドで必要なフィルタリングがおこなえます: &prompt.root; ipfw add deny tcp from any to my.org/28 6000 setup アカウンティングレコードを見るには: &prompt.root; ipfw -a list または短縮形式で &prompt.root; ipfw -a l 最後にチェーンエントリがマッチした 時刻を見ることもできます. &prompt.root; ipfw -at l パケットフィルタリングファイアウォールの構築 以下の提案は, ただの提案にすぎません: 必要な処理はそれぞれのファイアウォールで異なるため, あなた独自の要求にあったファイアウォールを構築する方法を ここで述べることはできないのです. 最初にファイアウォールをセットアップするとき, コントロールされた環境でファイアウォールホストの 設定がおこなえるような テストベンチセットアップが用意できない場合には, カーネルのログ取りを 有効にしてログ取り版のコマンドを使用することを 強くおすすめします. そうすることで, 大した混乱や中断なしに問題となる範囲の特定と処置を 素早くおこなうことができます. 初期セットアップフェーズが完了してからであっても, アタックの可能性のあるアクセスをトレースしたり, 要求の変化に応じてファイアウォールルールを 変更したりできるので, `deny' に対するログ取りをおこなうことをおすすめします. accept コマンドのログ取りをおこなっていると, ファイアウォールをパケットが一つ通過する毎に 1 行のログが生成されるため 大量の ログデータが発生します. そのため, 大規模な ftp/http 転送などをおこなうと, システムが非常に 遅くなってしまいます. また, パケットが通過するまでにカーネルにより 多くの仕事を要求するため, パケットのレイテンシ (latency) を増加させてしまいます. syslogd もログをディスクに記録するなど, より多くの CPU タイムを 使用し始め, 実に容易に /var/log が置かれているパーティションを パンクさせてしまう可能性があります. ファイアウォールは, /etc/rc.conf.local か, もしくは /etc/rc.conf によって有効化されるべきです. 関連マニュアルページには, どのドアノブ(訳注: ポートや IP アドレスなど, ネットワークからの入口を示すもののこと)に手をつければ良いのかに ついての説明と, ファイアウォール設定の既定値のリストがあります. もし, 設定の既定値を使わない場合には, ipfw list とすることで, 現在のルールセットを rc.conf から読み込める形で ファイルに出力することができます. また, /etc/rc.conf.local や /etc/rc.conf によってファイアウォールを 有効化しない場合には, ファイアウォールの有効化がすべての IP インターフェイス設定より先に行なわれるように確認することが重要です. 次の問題は, ファイアウォールが実際には何を する べきかです ! これは外部からそのネットワークへのどんなアクセスを許したいか, また内部から外界へのアクセスを どのくらい許したいかに大きく依存します. いくつか一般的なルールを挙げると: 1024 番以下のポートへのすべての TCP 入力アクセスをブロックします. ここは finger, SMTP (mail) そして telnet など, 最もセキュリティに敏感な サービスが存在する場所だからです. すべての 入力 UDP トラフィックをブロックします. これは UDP を使用しているサービスで有用なものは極めて少ないうえ, 有用なトラフィック (たとえば Sun の RPC と NFS プロトコル) は, 通常セキュリティに対する脅威となるためです. UDP はコネクションレスプロトコルであるため, 入力 UDP トラフィックを拒絶することは すなわち出力 UDP トラフィックに対する返答をも ブロックすることになるので, このことはそれなりの不利益をもたらします. たとえば外部の archie (prospero) サーバを使用している (内部の) ユーザに とって問題となる可能性があります. もし archie へのアクセスを許したければ, 191 番と 1525 番のポートから 任意の UDP ポートへ来るパケットがファイアウォールを通過することを 許可しなければなりません. 123 番のポートから来るパケットは ntp パケットで, これも通過の許可を考慮する必要がある もう一つのサービスです. 外部から 6000 番のポートへのトラフィックをブロックします. 6000 番のポートは X11 サーバへのアクセスに使用されるポートで, セキュリティに対する脅威となりえます. (特に自分のワークステーションで xhost + をおこなう癖を持っている人がいればなおさらです). X11 は実際に 6000 番以降のポートを使用する可能性があるため, 通過許可に 上限を定めると, そのマシンで走らせることのできる X ディスプレイの 個数が制限されます. RFC 1700 (Assigned Numbers) で定義されているように, 上限は 6063 です. 内部のサーバ (たとえば SQL サーバなど) がどのポートを使用するかを チェックします. それらのポートは通常, 上で指定した 1-1024 番の範囲から外れていますので, これらも同様にブロックしておくことは おそらく良い考えです. これとは別のファイアウォール設定に 関するチェックリストが CERT から 入手可能です. http://www.cert.org/tech_tips/packet_filtering.html 前にも述べたように, これはただの ガイドライン にすぎません. ファイアウォールでどのようなフィルタルールを使用するかは, あなた自身が 決めなければなりません. これまでのアドバイスにしたがったにも関わらず, 誰かがあなたのネットワークに 侵入してきたとしても, わたしたちは「いかなる」責任もとることはできません. OpenSSL FreeBSD 4.0 では, OpenSSL ツールキットが基本構成の一部に 含まれています. OpenSSL は, Secure Sockets Layer v2/v3 (SSLv2/SSLv3) や Transport Layer Security v1 (TLSv1) ネットワークセキュリティプロトコルと同様の 多目的な暗号化ライブラリを提供します. しかしながら, OpenSSL に含まれるアルゴリズムのひとつ (特に IDEA) は, 合衆国内, その他の地域において, 特許により保護されています. そのため, 無制約な利用は許されません. IDEA は FreeBSD の OpenSSL 配布に含まれていますが, デフォルトではコンパ イルされません. もし IDEA を使いたいなら, そしてあなたがそのライ センス条項に合致するなら, /etc/make.conf の中の MAKE_IDEA スイッ チを有効にして, 'make world' でソースをリビルドしてください. 現在は RSA アルゴリズムはアメリカとその他の国で自由に利用で きます. 以前は特許により保護されていました. ソースコードのインストール OpenSSL は src-crypto と src-secure cvsup コレクションの一部です. FreeBSD のソースコードの取得と更新の詳細は, FreeBSD の入手の項を参照して下さい. IPsec 原作: &a.shin;, 5 March 2000. 訳: &a.jp.hino;, 14 March 2001. IPsec 機構は, IP 層とソケット層の両方に対して安全な通 信を提供します. 実装の詳細に関しては The Developers' Handbook を参照してください. 現在の IPsec の実装は, トランスポートモードとトンネルモード の両方をサポートしています. しかし, トンネルモードにはいくつかの 制限事項があります. http://www.kame.net/newsletter/ にはより総合的な例が載っています. ここで述べる機能を利用するには, 以下のオプションをカーネルコ ンパイル時に指定する必要があることにご注意ください. options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/IPSEC) IPv4 におけるトランスポートモードの例 ホスト A (10.2.3.4) とホスト B (10.6.7.8) との間に安全なチャ ネルを配置するために, セキュリティアソシエーションを設定しましょ う. ここでは, 少し込み入った例を示します. ホスト A からホストB へは old AH のみを使います. ホスト B からホスト A へは new AH と new ESP を組み合わせます. ここで "AH"/"new AH"/"ESP"/"new ESP" に対応するアルゴリズ ムを決めないといけません. アルゴリズムの名前を知るには, &man.setkey.8; マニュアルページをご覧ください. ここでは, AH に MD5 を, new AH には new-HMAC-SHA1 を, new ESP には 8 バイト IV の new-DES-expIV を選びました. 鍵長はそれぞれのアルゴリズムに大きく依存します. たとえば, MD5 では鍵長は 16 バイトでなければなりませんし, new-HMAC-SHA1 では 20 バイトでなければなりませんし, new-DES-expIV では 8 バ イトでなければなりません. ここではそれぞれ "MYSECRETMYSECRET", "KAMEKAMEKAMEKAMEKAME", "PASSWORD", とします. 次に, それぞれのプロトコルに対して SPI (セキュリティパラメー タインデックス: Security Parameter Index) を割り当てます. 三種 類のセキュリティヘッダ (ホスト A からホスト B に一つ, ホスト B から ホスト A に二つ) を生成するので, この安全なチャネルには三 つの SPI が必要になることに注意してください. さらに, SPI は 256 以上である必要があることにも注意してください. ここではそれ ぞれ 1000, 2000, 3000 を割り当てます. (1) ホスト A ------> ホスト B (1)PROTO=AH ALG=MD5(RFC1826) KEY=MYSECRETMYSECRET SPI=1000 (2.1) ホスト A <------ ホスト B <------ (2.2) (2.1) PROTO=AH ALG=new-HMAC-SHA1(new AH) KEY=KAMEKAMEKAMEKAMEKAME SPI=2000 (2.2) PROTO=ESP ALG=new-DES-expIV(new ESP) IV length = 8 KEY=PASSWORD SPI=3000 次に, セキュリティアソシエーションを設定しましょう. ホスト A とホスト B の両方で, &man.setkey.8; を実行します: &prompt.root; setkey -c add 10.2.3.4 10.6.7.8 ah-old 1000 -m transport -A keyed-md5 "MYSECRETMYSECRET" ; add 10.6.7.8 10.2.3.4 ah 2000 -m transport -A hmac-sha1 "KAMEKAMEKAMEKAMEKAME" ; add 10.6.7.8 10.2.3.4 esp 3000 -m transport -E des-cbc "PASSWORD" ; ^D 実際には, セキュリティポリシのエントリが定義されるまでは IPsec による通信は行われません. この例の場合, 両方のホストを設 定する必要があります. A で: &prompt.root; setkey -c spdadd 10.2.3.4 10.6.7.8 any -P out ipsec ah/transport/10.2.3.4-10.6.7.8/require ; ^D B で: &prompt.root; setkey -c spdadd 10.6.7.8 10.2.3.4 any -P out ipsec esp/transport/10.6.7.8-10.2.3.4/require ; spdadd 10.6.7.8 10.2.3.4 any -P out ipsec ah/transport/10.6.7.8-10.2.3.4/require ; ^D ホスト A -------------------------------------> ホスト B 10.2.3.4 10.6.7.8 | | ========== old AH keyed-md5 ==========> <========= new AH hmac-sha1 =========== <========= new ESP des-cbc ============ IPv6 におけるトランスポートモードの例 IPv6 を使ったもう一つの例. ホスト-A とホスト-B 間の TCP ポート番号 110 番の通信には, ESP トランスポートモードが推奨されます. ============ ESP ============ | | ホスト-A ホスト-B fec0::10 -------------------- fec0::11 暗号化アルゴリズムは blowfish-cbc で, その鍵は "kamekame", 認証アルゴリズムは hmac-sha1 で, その鍵は "this is the test key" とします. ホスト-A の設定: &prompt.root; setkey -c <<EOF spdadd fec0::10[any] fec0::11[110] tcp -P out ipsec esp/transport/fec0::10-fec0::11/use ; spdadd fec0::11[110] fec0::10[any] tcp -P in ipsec esp/transport/fec0::11-fec0::10/use ; add fec0::10 fec0::11 esp 0x10001 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; add fec0::11 fec0::10 esp 0x10002 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; EOF そしてホスト-B の設定: &prompt.root; setkey -c <<EOF spdadd fec0::11[110] fec0::10[any] tcp -P out ipsec esp/transport/fec0::11-fec0::10/use ; spdadd fec0::10[any] fec0::11[110] tcp -P in ipsec esp/transport/fec0::10-fec0::11/use ; add fec0::10 fec0::11 esp 0x10001 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; add fec0::11 fec0::10 esp 0x10002 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; EOF SP の方向に注意してください. IPv4 におけるトンネルモードの例 二台のセキュリティゲートウェイ間のトンネルモード セキュリティプロトコルは old AH トンネルモード, すなわち RFC1826 で指定されるものです. 認証アルゴリズムは "this is the test" を鍵とする keyed-md5 です. ======= AH ======= | | ネットワーク-A ゲートウェイ-A ゲートウェイ-B ネットワーク-B 10.0.1.0/24 ---- 172.16.0.1 ----- 172.16.0.2 ---- 10.0.2.0/24 ゲートウェイ-A における設定: &prompt.root; setkey -c <<EOF spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec ah/tunnel/172.16.0.1-172.16.0.2/require ; spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec ah/tunnel/172.16.0.2-172.16.0.1/require ; add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any -A keyed-md5 "this is the test" ; add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any -A keyed-md5 "this is the test" ; EOF 上記の例のように, もしポート番号フィールドを書かないと, "[any]" と同じ意味になります. `-m' は使用される SA のモードを 指定します. "-m any" はセキュリティプロトコルのモードのワイル ドカードを意味します. この SA をトンネルモードとトランスポート モードの両方で使用できます. そしてゲートウェイ-B では: &prompt.root; setkey -c <<EOF spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec ah/tunnel/172.16.0.2-172.16.0.1/require ; spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec ah/tunnel/172.16.0.1-172.16.0.2/require ; add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any -A keyed-md5 "this is the test" ; add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any -A keyed-md5 "this is the test" ; EOF 二台のセキュリティゲートウェイ間の SA の束を作ります ゲートウェイ-A とゲートウェイ-B の間では, AH トランスポー トモードと ESP トンネルモードが要求されます. この例では, ESP ト ンネルモードが先に適用され, 次に AH トランスポートモードが適用さ れます. ========== AH ========= | ======= ESP ===== | | | | | ネットワーク-A ゲートウェイ-A ゲートウェイ-B ネットワーク-B fec0:0:0:1::/64 --- fec0:0:0:1::1 ---- fec0:0:0:2::1 --- fec0:0:0:2::/64 IPv6 におけるトンネルモードの例 暗号化アルゴリズムは 3des-cbc, ESP の認証アルゴリズムは hmac-sha1 とします. AH の認証アルゴリズムは hmac-md5 とします. ゲートウェイ-A での設定は: &prompt.root; setkey -c <<EOF spdadd fec0:0:0:1::/64 fec0:0:0:2::/64 any -P out ipsec esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require ah/transport/fec0:0:0:1::1-fec0:0:0:2::1/require ; spdadd fec0:0:0:2::/64 fec0:0:0:1::/64 any -P in ipsec esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require ah/transport/fec0:0:0:2::1-fec0:0:0:1::1/require ; add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10001 -m tunnel -E 3des-cbc "kamekame12341234kame1234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:1::1 fec0:0:0:2::1 ah 0x10001 -m transport -A hmac-md5 "this is the test" ; add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10001 -m tunnel -E 3des-cbc "kamekame12341234kame1234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:2::1 fec0:0:0:1::1 ah 0x10001 -m transport -A hmac-md5 "this is the test" ; EOF 異なる通信端での SA を作る ホスト-A とゲートウェイ-A の間では ESP トンネルモードが要 求されています. 暗号化アルゴリズムは cast128-cbc で, ESP の認 証アルゴリズムは hmac-sha1 です. ホスト-A とホスト-B との間で は ESP トランスポートモードが推奨されています. 暗号化アルゴリ ズムは rc5-cbc で, ESP の認証アルゴリズムは hmac-md5 です. ================== ESP ================= | ======= ESP ======= | | | | | ホスト-A ゲートウェイ-A ホスト-B fec0:0:0:1::1 ---- fec0:0:0:2::1 ---- fec0:0:0:2::2 ホスト-A での設定: &prompt.root; setkey -c <<EOF spdadd fec0:0:0:1::1[any] fec0:0:0:2::2[80] tcp -P out ipsec esp/transport/fec0:0:0:1::1-fec0:0:0:2::2/use esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require ; spdadd fec0:0:0:2::1[80] fec0:0:0:1::1[any] tcp -P in ipsec esp/transport/fec0:0:0:2::2-fec0:0:0:l::1/use esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require ; add fec0:0:0:1::1 fec0:0:0:2::2 esp 0x10001 -m transport -E cast128-cbc "12341234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10002 -E rc5-cbc "kamekame" -A hmac-md5 "this is the test" ; add fec0:0:0:2::2 fec0:0:0:1::1 esp 0x10003 -m transport -E cast128-cbc "12341234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10004 -E rc5-cbc "kamekame" -A hmac-md5 "this is the test" ; EOF OpenSSH 原作: &a.chern;, 2001 年 4 月 21 日. セキュアシェル (secure shell) はリモートマシンへのセキュアなアクセスに使われる ネットワーク接続ツールのセットです. それは rlogin, rsh, rcp, telnet を直接置き換えて使うことができます. また, 他のあらゆる TCP/IP 接続を ssh 経由でセキュアにトンネル/フォワードすることもできます. ssh はすべてのトラフィックを暗号化し, 盗聴や接続の乗っ取り等のネットワークレベルの攻撃を事実上無効化します. OpenSSH は OpenBSD プロジェクトによって維持管理されており, SSH v1.2.12 に最新のすべてのバグ修正と更新を適用したものをベースにしています. OpenSSH クライアントは SSH プロトコル 1 と 2 の両方に互換性があります. OpenSSH は FreeBSD 4.0 以降ベースシステムに取り込まれています. OpenSSH を使うことの利点 &man.telnet.1; や &man.rlogin.1; を使う場合, 一般にデータはネットワークを平文で流れます. ネットワークをクライアントとサーバの間のどこかで盗聴することで あなたのユーザ/パスワード情報やセション中を流れるデータを盗むことが可能です. OpenSSH はこれらを予防する為にさまざまな認証と暗号化の方法を提供します. sshd を有効にする rc.conf ファイルに 以下の行を追加してください. sshd_enable="YES" 次に起動したときから ssh デーモンが起動します. もしくは単に sshd デーモンを実行しても構いません. SSH クライアント &man.ssh.1; ユーティリティは &man.rlogin.1; と同様に働きます. &prompt.root ssh user@foobardomain.com Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes Host 'foobardomain.com' added to the list of known hosts. user@foobardomain.com's password: ******* ログインは rlogin や telnet でセションを張った時と同様に続きます. SSH はクライアントが接続した時, サーバの信頼性の検証のために鍵指紋システム (key fingerprint system) を利用します. 初めての接続の際にのみ, ユーザは 'yes' と入力することを要求されます. これ以降の login では保存されていた鍵指紋を照合することで検証されます. SSH クライアントは保存されていた鍵指紋が login しようとした際に送られてきたものと異なっていた場合には警告を表示します. 指紋は ~/.ssh/known_hosts に保存されます. Secure copy scp コマンドが rcp と異なるのは, セキュアになっているという点だけです. つまりローカルのファイルをリモートマシンへ, あるいはリモートマシンのファイルをローカルにコピーします. &prompt.root scp user@foobardomain.com:/COPYRIGHT COPYRIGHT user@foobardomain.com's password: COPYRIGHT 100% |*****************************| 4735 00:00 &prompt.root 前回の例でこのホストの指紋がすでに保存されていれば この scp を使う時に検証が行なわれます. 設定 システム全体の設定ファイルは, OpenSSH デーモン, クライアントの両方とも /etc/ssh ディレクトリにあります. ssh_config はクライアントの動作設定, sshd_config はデーモンの動作設定を行ないます. ssh-keygen パスワードの代わりに &man.ssh-keygen.1; を使って ユーザの認証用の RSA 暗号鍵を作ることができます. &prompt.user ssh-keygen Initializing random number generator... Generating p: .++ (distance 66) Generating q: ..............................++ (distance 498) Computing the keys... Key generation complete. Enter file in which to save the key (/home/user/.ssh/identity): Enter passphrase: Enter the same passphrase again: Your identification has been saved in /home/user/.ssh/identity. ... &man.ssh-keygen.1; は認証に使う為の公開鍵と秘密鍵のペアを作ります. 秘密鍵は ~/.ssh/identity に保存され, 公開鍵は ~/.ssh/identity.pub に保存されます. 公開鍵はリモートマシンの ~/.ssh/authorized_keys にも置かなければなりません. これでパスワードの代わり RSA 認証を使って リモートマシンに接続できるようになったはずです. &man.ssh-keygen.1; でパスフレーズを使っている場合は, ユーザは秘密鍵を使うために毎回パスフレーズの入力を行なう必要があります. &man.ssh-agent.1; と &man.ssh-add.1; は 多重にパスワード化された秘密鍵の管理に使われます. SSH トンネリング OpenSSH は暗号化されたセションの中に他のプロトコルを カプセル化することでトンネルを作ることができます. 以下のコマンドは &man.ssh.1; で telnet 用のトンネルを作成します. &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.bar.com &prompt.user; -2 は &man.ssh.1; にプロトコル 2 を使うことを指示します. (古い ssh サーバを使っているときには指定しないでください) -N はトンネルだけでコマンドはないことを示します. 省略されると &man.ssh.1; は通常のセッションを開始します. -f は &man.ssh.1; にバックグラウンド実行を強制します. -L はローカルトンネルとして localport:localhost:remoteport 形式を指示します. foo.bar.com はリモート/ターゲットの SSH サーバです. SSH のトンネルは指定されたローカルホストとポートを listen する ソケットを作ることで実現されています. SSH はローカルのホスト/ポートへのすべての接続を SSH 接続経由でリモートマシンの指定されたリモートポートへ 転送 (フォワード) します. たとえば, ローカルホストのポート 5023 がリモートマシンの 23 に転送されるようになっているとします. 23 は telnet なのでこれは SSH トンネルを通るセキュアな telnet セッションを作ります. このようにして smtp や pop3, ftp 等のセキュアではない TCP プロトコルをカプセル化することができます. 典型的な SSH トンネル &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.foobar.com user@mailserver.foobar.com's password: ***** &prompt.user; telnet localhost 5025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailserver.foobar.com ESMTP &man.ssh-keygen.1; と別のユーザアカウントを組み合わせて使うことで より透過的で悩まずに済むような SSH のトンネル環境を作ることができます. パスワードを入力するところで暗号鍵を使い, トンネルは別のユーザ権限で実行することが可能です. さらに知りたい人へ OpenSSH &man.ssh.1; &man.scp.1; &man.ssh-keygen.1; &man.ssh-agent.1; &man.ssh-add.1; &man.sshd.8; &man.sftp-server.8; diff --git a/ja_JP.eucJP/books/handbook/serialcomms/chapter.sgml b/ja_JP.eucJP/books/handbook/serialcomms/chapter.sgml index 89b927d05d..3c8a3ddc9b 100644 --- a/ja_JP.eucJP/books/handbook/serialcomms/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/serialcomms/chapter.sgml @@ -1,3159 +1,3159 @@ シリアル通信 この章では シリアル通信 Unix は現在に至るまで, 常にシリアル通信機能をサポートしていました. 実際, 本当に初期の Unix マシンは, ユーザとの入出力にシリアル通信を使っていました. 10 文字毎秒のシリアルプリンタ, キーボードから構成された 端末(terminal) が広く使われていた当時とは, 何もかもがすっかり変わっています. この章では, FreeBSD でシリアル通信を行なういくつかの方法について説明しています. シリアル接続の基礎 Assembled from FAQ. このセクションには, シリアルポートについての一般的な情報が書かれていま す. あなたが求めている情報が, もしここで見つからなかった場合には, ハン ドブックの端末とダイアルアップのセクションを見てください. ttyd cuaa ttydX (または cuaaX) デバイスは, アプリケーション上 でシリアルポートをオープンする時に使用する, 標準的なデバイスです. プロセスがデバイスをオープンする際, 端末 I/O 設定の デフォルトセットが使用されます. これらの設定内容は, 次のコマンドで確認することができます. &prompt.root; stty -a -f /dev/ttyd1 このデバイスの設定を変更した場合, その設定はデバイスが クローズされるまで有効です. デバイスが再びオープンされる時, デフォルトの設定値に戻ります. デフォルトの設定を変更するためには, 初期状態 を設定した いデバイスをオープンして調節することができます. 例えば, ttyd5 というデバイスに対して, デフォルトで CLOCAL モードを ON にして, 8 bits の設定をおこない, XON/XOFF フロー制御を行うように設定したい場合は, 次のようにします. &prompt.root; stty -f /dev/ttyid5 clocal cs8 ixon ixoff rc ファイル rc.serial このコマンドを記述するのに適しているファイルは, /etc/rc.serial です. アプリケーションがttyd5 をオープンするときに, デフォルトでこの設定をおこなうようになります. これらの設定は, 好きなように変更することができます. また, 固定状態 のデバイスに調節を行うことで, ある一定の設定が アプリケーションに変更されることを防ぐこともできます. 例えば, ttyd5 のスピードを 57600 bps に固定したい場合には, 次のようにします. &prompt.root; stty -f /dev/ttyld5 57600 これで, ttyd5 をオープンして, シリアルポートの転送スピードを 変更しようとするアプリケーションは 57600 bps に固定されるでしょう. MAKEDEV 本来, デバイスの初期状態を変更したり設定を固定するのは, root だけが行うべきです. MAKEDEV スクリプトがデバイスエントリを作成する時は, これをおこないません. シリアル端末 端末 - 原作: &a.kelly; + 原作: Sean Kelly kelly@ad1440.net 28 July 1996 訳: &a.max; シリアル端末を利用することで, コンピュータのコンソールのそばにいないと きや, 手近にネットワーク接続されているコンピュータがないときでも, FreeBSD の機能を便利に, かつ安価に利用することができます. ここでは, FreeBSD にシリアル端末を接続する方法を解説します. 端末の種類と利用方法 もともと Unix システムにはコンソールがありませんでした. ユー ザはコンピュータのシリアル ポートに接続された端末からログインして プログラムを利用していました. ちょうどモデムと通信ソフトを使ってリモート のコンピュータにログインし, テキスト ベースのプログラムを利用するのと よく似ています. 最近の PC は, 高品質の画像を表示できるコンソールを搭載していま すが, ほとんどすべての Unix 系 OS には未だにシリアル ポートを使ってログ インするための機能があり, FreeBSD でもこの機能がサポートされています. 現在使用されていないシリアル ポートに端末を接続することでシステムに ログインし, 通常はコンソールや Xウィンドウ システムの xterm のウィ ンドウ上で起動しているテキスト ベースのプログラムであれば何 でも利用することができます. 職場での利用ということで考えるならば, FreeBSD が動作しているコンピュー タに接続された何台ものシリアル端末を 各社員の机に配置するというようなこ とが可能です. また, 家庭での利用方法としては, 余っている古い IBM PC や Macintosh を FreeBSD が動いているパワフルなコンピュータの端末として利 用することができます. 普通ならシングルユーザのコンピュータを, パワフ ルなマルチユーザのシステムに変えることができるのです. FreeBSD では, 以下に挙げる3種類の端末が利用できます. ダム (dumb) 端末 PCを利用した端末 X 端末 以下は, それぞれについての解説です. ダム端末 ダム端末は, シリアルライン経由でのコンピュータとの接続専 用のハードウェアです. ダム端末は, テキストの送受信および表示ができる 程度の計算能力しかもっていないので, dumb (間抜け) というように呼ば れています. この端末上でプログラムを実行することはできません. テキスト エディタ, コンパイラ, E-mail, ゲームなどなどのプログラムを実行するのは, ダム端末を接続しているコンピュータの方です. Digital Equipment社の VT-100 や, Wyse社の WY-75 を初めとして, 多くのメーカが何百種類もの ダム端末を作っています. ほとんどどんな種 類のダム端末でも FreeBSD に接続して使用できます. さらに, 高性能の端 末の中には画像を取り扱えるものもありますが, 限られた数のソフトウェア パッケージしかこういった機能には対応していません. ダム端末は, X ウィンドウ システムで提供されるようなグラ フィックアプリケーションを必要としない 職場で広く用いられています. PC を端末として利用する ダム端末 がテキストの表示およ び送受信の機能をそなえただけのものならば, 言うまでもなく, どんなPC もダム端末になり得ます. 必要なものは適切なケーブルと, そのPCの上 で動作する端末エミュレーション を行うソフトウェアのみです. このような環境は, 家庭においてよく利用されます. たとえば, あなたの同居 人が FreeBSD のコンソールを専有している時などに, あまりパワーのないコ ンピュータを FreeBSD システムにシリアル端末として接続し, その端末上で テキストだけを用いる作業をおこなうことができます. X 端末 X 端末は, 既存のものの中で最も洗練された種類の端末といえ ます. X 端末は, たいていの場合シリアル ポートではなく, イーサネッ トのようなネットワークを利用した接続をおこないます. また, アプリケーション の利用においても, テキストベースのものだけでなく, X アプリケーション の利用が可能です. ここでは, 参考までに 端末について紹介しただけで, X 端 末の設定や利用についての解説は おこないません. ケーブルとポート シリアル端末を FreeBSD システムに接続するためには, 適切なケー ブルと, 端末を接続するためのシリアルポートが必要です. ここでは, これ らについて説明します. もし既にあなたの利用したい端末と, その端末 を接続するためのケーブルについてよく理解していれば, 設定 の章まで読み飛ばしてください. ケーブル 端末の接続は, シリアルポートを利用します. そこで, 端末を FreeBSD システムに接続するためには, シリアルケーブル (RS-232C ケーブ ルとも呼ばれています) が必要となります. シリアルケーブルには2種類のケーブルがあります. どちらの種類の ケーブルを使わなければいけないかは, どんな端末を接続したいかによります. ヌルモデムケーブル もし, PC を端末として利用したい場合は, ヌルモデム ケーブル (リバースケーブルもしくは クロスケーブルと呼ばれることもしばしばあります) を使用してください. ヌルモデムケーブルは, コンピュータ同士や端末同士を接続するために用い られるケーブルです. もし, 本物の端末を接続するのであれば, その端末につい てきたドキュメントからどのようなケーブルを 使うべきか調べてください. も しドキュメントがない場合は, まず ヌルモデム ケーブルを試してみて, うまくいかない場合は スタンダード ケーブル (しばしばストレートケーブルと呼 ばれます) を試してみてください. また, 端末側と FreeBSD 側の 両方の シリア ポート の形状が, あなたが使用しようとしているケーブルについているコネクタの形 状と一致していなければなりません. ヌルモデムケーブル ヌルモデムケーブル (またはリバースケーブルあるいはクロ スケーブル) は, たとえば signal ground 信号のように, いくつかの信 号はそのまま通しますが, 他の信号は途中で入れ替えて通します. たとえば, send data 信号のピンは, 反対側のコネクタの receive data 信号の ピンと繋がっています. 自分で使うケーブルは自分で作りたいということであれば, 以下にター ミナルを接続する際に推奨される ヌルモデムケーブルの結線を示しておきま す. この表では, RS-232C の信号線の名前と, DB-25 コネクタ上のピンの番 号を示しています. Signal Pin # Pin # Signal TxD 2 connects to 3 RxD RxD 3 connects to 2 TxD DTR 20 connects to 6 DSR DSR 6 connects to 20 DTR SG 7 connects to 7 SG DCD 8 connects to 4 RTS RTS 4 5 CTS CTS 5 connects to 8 DCD DCD と RST では, コネクタ内部でピン4を5に接続し, そして逆側のコネクタのピン8と接続します. スタンダード RS-232C ケーブル RS-232C ケーブル スタンダードシリアルケーブル (またはストレートケーブル) の場合は, すべての RS-232C 信号をそのまま通します. つまり, 片方の send data 信号のピンは, 逆側の send data 信号のピンと繋がっています. モデムを FreeBSD に接続するときや, 一部の端末を接続するときにこのタイプの ケーブルを使用します. ポート シリアルポートは, FreeBSDが動作しているホスト コンピュータと端 末の間でデータのやりとりを行うために用いるデバイスです. ここでは, 現在存在するポートの種類と FreeBSD でのポートのアクセス方法について解 説します. ポートの種類 シリアルポートには何種類かのものがあります. ケーブルを購 入したり自作したりする前に, そのケーブルのコネクタの形状が端末および FreeBSD システムのポートの形状と一致していることを 確認してください. ほとんどの端末は DB25 ポートを搭載しています. FreeBSDが動作しているも のを含めて, PCは DB25 または DB9 ポートを搭載しています. マルチポート のシリアルカードの場合は, RJ-12 や RJ-45 のポートを搭載しているかもし れません. 利用されているポートの種類に関しては, ハードウェアについてきたドキュメ ントを参照してください. また, 多くの場合, ポートの形状から判断すること もできるでしょう. ポートの名前 FreeBSDでは, /dev ディレクトリ内のエントリを介 してシリアルポートへのアクセスがおこなわれます. 2種類の異なったエン トリがあります. 着信用のポートの名前は, /dev/ttydx ( x は 0から始まるポート番号) となっています. 一般に端末の接続には 着信用ポートを用います. 着信用のポートでは, シリアルラインのデータ キャリア検出 (DCD) 信号がオンになっている必要があります. 発信用のポートの名前は, /dev/cuaax となっています. 発信用のポートは普通モデムの接続に用い, 端末の接続には 利用しません. ただ, ケーブルまたは端末がキャリア検出信号を使えない タイプのものの場合は, 発信用のポートを使うとよいでしょう. 詳しくは, &man.sio.4; のマニュアルをご覧ください. たとえば, 端末を一つ目のシリアルポート (DOS でいうところの COM1) に接 続したとすると, /dev/ttyd0 がこの端末を指すことになります. また, 二つ目のシリアルポート (COM2) ならば /dev/ttyd1 となり, 以下この形式のデバイスエントリを使います. 各シリアルポート, 特にマルチポートのシリアルカードを利用する ために, kernel の設定をおこなう必要がある場合がありますので, 注意してくだ さい. 詳しくは, FreeBSD カーネルのコンフィグレーション をご覧ください. 設定 ここでは, 端末からのログインを可能にするために必要な FreeBSD 側の設定について解説します. 既に端末を接続するポートが利用できるように kernel の設定をおこない, 端末が接続されているものと考えて, 解説を進め ます. 簡単に言えば, プロセス管理や初期化をおこなっている init プロセス に対して, ログイン名を読み込み login プログラムを起動している getty を実行するように指示します. これをおこなうには, /etc/ttys の内容を編集する必要があります. まず, su コマンドで root になって, /etc/ttys に以下の 変更を加えてください. 端末を接続するポートの /dev のエントリが含ま れている行がまだ存在しなければ, これを /etc/ttys に追加してく ださい. /usr/libexec/getty が対象となるポートに対して 実行されるように指定してください. また, /etc/gettytab ファイ ル内の適切な getty タイプのエントリを指定してください. デフォルトのターミナルタイプを指定してください. 対象となるポートを on に設定してください. そのポートが secure であるかどうかを指定してください. init に /etc/ttys を読み込みなおさせてく ださい. また, 必要に応じて /etc/gettytab を変更し, 上の 2で使用する getty のエントリを追加してください. このドキュメントではこの方 法については特に解説しませんので, &man.gettytab.5; および &man.getty.8; のマニュアルをご覧ください. 以下では, 上のステップについて詳しく解説します. 実例を用いて, 何をす べきかを解説していきます. Wyse-50 と, 古い IBM の 286 マシン上で通信 ソフト Procomm を使って VT-100 エミュレーションをおこなっているものを端 末の例として紹介します. また, Wyse は 2番目のポートに, 286マシンは 6 番目のポート (マルチポートのシリアルカード上のポート) に接続します. /etc/ttys について, より詳しくは, &man.ttys.5; のマニュアルをご覧 ください. <filename>/etc/ttys</filename> へのエントリの追加 既にエントリがある場合を除いて, まず初めに /etc/ttys にエントリを追加しなければいけません. /etc/ttys には, FreeBSDシステム上のログインを許可するすべての ポートを記述します. たとえば, 一つ目の仮想コンソール ttyv0 のエン トリもこのファイルにあります. このエントリのおかげで, コンソールからの ログインが可能になっています. このファイルには, 他の仮想コンソール, シ リアルポートおよび仮想端末のエントリも含まれています. 端末を接続する 場合は, そのポートの /dev のエントリを, /dev の部分 を省略して記述します. FreeBSD のインストール当初の状態では, ttyd0 から ttyd3 までの, 初めの四つのシリアルポートのエントリが /etc/ttys に記述され ています. これらのポートのいずれかに端末を接続する場合は, 新たなエント リを追加する必要はありません. ここで紹介している例では, 既にファイルにエントリが存在する 2番目のシリ アルポート, ttyd1 に Wyse-50 を接続しています. 一方, 6番目のシ リアルポートに接続する 286マシン用のエントリは, 新たに追加してやらな ければなりません. 以下に, エントリを追加した後の /etc/ttys か ら抜粋して示します. ttyd1 "/usr/libexec/getty std.9600" unknown off secure ttyd5 <replaceable>getty</replaceable> タイプの指定 次に, 端末からのログインを処理するプログラムの指定をおこな います. FreeBSDでは, 標準的には /usr/libexec/getty をこの目的 で利用しています. login: プロンプトを送り出しているのは, このプロ グラムです. getty プログラムは, コマンドラインパラメータとして, getty タイプをとります. ただし, このパラメータは必須ではあ りません. getty タイプは, ボーレートやパリティといった, 接続され た端末の特徴を表すものです. getty プログラムは, 与えられた getty タイプに対応したこれらの特徴を /etc/gettytab から 読み込みます. ファイル /etc/gettytab には, 新旧の端末に関する多数のエントリ が記述されています. ほとんどの場合, std という文字列で始まる名前 のエントリを使えば, 接続された端末に対してログインセッションを提供す ることができます. これらのエントリを利用した場合, パリティは無視されま す. 110 bps から 115200 bps までのボーレートに対応した std のエン トリがあります. 当然, 新たなエントリを追加することも可能です. &man.gettytab.5; のマニュアルに, さらに詳しく解説されています. /etc/ttys の getty タイプの設定をする際は, 端末側の通信 パラメータの設定が, getty タイプのものと一致していることを確認し てください. 紹介している実例では, Wyse50 はパリティなし 38400 bps で接続していま す. また, 286 マシンの方は, パリティなし 19200 bps の接続です. 以下は, この段階でのこの二つの端末に関する /etc/ttys の設定です. ttyd1 "/usr/libexec/getty std.38400" unknown off secure ttyd5 "/usr/libexec/getty std.19200" ここで, 実行するプログラムを指定している 2番目のフィールドが, ダブルクォー テーションに囲まれていることに注意してください. こうしないと, getty のタイプの指定が, つぎのフィールドとして判断されてしまう可 能性があるので, 十分注意することが必要です. デフォルトのターミナルタイプの指定 /etc/ttys の 3番目のフィールドには, そのポートのター ミナルタイプのデフォルトを指定します. ダイアルアップ用のポートの場合 は, ユーザがどのタイプの端末あるいは 通信ソフトを利用してダイアルアップ してくるかは分からないので, unknown や dialup を記述するの が一般的です. 一方, 直結された端末の場合, ターミナルタイプが変わるこ とはありませんから, このフィールドには実際のターミナルタイプを記述し ます. 一般に, ユーザは .login や .profile などのファイル内で tset コマンドを使って, ターミナルタイプをチェックし, 必要ならば ターミナルタイプの入力を求めるプロンプトを 表示するようにします. この とき, /etc/ttys の中でターミナルタイプが指定されていれば, このプロンプトを表示せずに先に進むことが可能です. termcap FreeBSD 上で, どのターミナルタイプを利用できるかは, /usr/share/misc/termcap をご覧ください. このファイルには, お よそ 600 のターミナルタイプが定義されています. 必要ならば, 新たなエン トリを追加することも可能です. 詳しくは &man.termcap.5; のマニュアルをご覧ください. 紹介している例では, Wyse-50 のターミナルタイプは Wyse-50 です (もっ とも他のタイプをエミュレートすることも可能ですが, ここでは Wyse-50 モー ドで使用します. ). また, 286マシン上では Procomm が VT-100 エミュレー ションをおこなうように設定されています. 以下が, まだ未完成の /etc/ttys の関連部分です. ttyd1 "/usr/libexec/getty std.38400" wy50 off secure ttyd5 "/usr/libexec/getty std.19200" vt100 ポートを利用可能にする /etc/ttys のつぎのフィールド, つまり 4番目のフィー ルドは, そのポートをアクティブにするかどうかの設定です. このフィールド に on を指定すると, init プロセスが2番目のフィールドに書かれ たプログラム, getty を実行し, ログインのためのプロンプトを送り出 すようになります. このフィールドに off を記述すると, getty は起動されず, よってこのポートからのログインもできなくなります. ということで, 当然このフィールドには on を指定します. 以下が /etc/ttys です. それぞれのポートを on にしました. ttyd1 "/usr/libexec/getty std.38400" wy50 on secure ttyd5 "/usr/libexec/getty std.19200" vt100 on ``secure'' なポートの指定 とうとう最後のフィールドの設定です. (実際にはここでは触れ ませんが, オプショナルなwindow の設定のフィールドも存在するので, ほぼ最後のフィールドといった方が正確かもしれません. ) 最後のフィールド では, そのポートが安全かどうかを指定します. ここで, 安全 なポートとはどういうポートのことでしょう? これは, root のアカウント (または, ユーザ ID が 0 のアカウント) がロ グインしてもよいポートということです. 安全でないポートでは, root のロ グインは許可されません. では, どのように安全なポートとそうでない ポートを使えばよいでしょう? ポートを安全ではないとすることで, そのポートに接続された端末からは, root のログインを禁止することができます. FreeBSDシステムの root のパス ワードを知っている人は, まず一般ユーザとしてログインしなければなりませ ん. スーパユーザの特権を得るためには, そのうえで su コマンドを 利用しなければいけません. これによって, root アカウントが不正に利用された場合に, その経過を調査 する上で二つの記録を利用できるようになります. login と su コマンドは, 共にシステムのログに記録を残します (また, ログイン は wtmp にも記録を残します. ). ポートを安全なものとして指定すると, その端末からの root のログインが可 能になります. root のパスワードを知っている人は, 単に root としてログ インできます. この場合は, 当然ログインの記録や su コマンドのログ は残りません. では, どちらを使うべきでしょうか? 単純に insecure を使うのがよいでしょう. 公共の場所にある訳ではな い端末や, 鍵のかかったドアの内側にある端末にも insecure を指 定する方がよいでしょう. スーパユーザの特権が必要な場合でも, ログイ ンして su を実行するのは, ごく簡単なことなんですから. 以下に, ようやく完成した /etc/ttys のエントリに端末の場所を表 すコメントを追加したものを示します. ttyd1 "/usr/libexec/getty std.38400" wy50 on insecure # Kitchen ttyd5 "/usr/libexec/getty std.19200" vt100 on insecure # Guest bathroom <command>init</command> にファイル <filename>/etc/ttys</filename> の再読み 込みをさせる FreeBSD をブートすると, 最初に起動されるプロセス, initが /etc/ttys を読み込んで, 記述されているプログラムを利用可能な ポートに対して実行し, ログインプロンプトを送り出させます. /etc/ttys の編集が終わった後, init に変更を認識させるた めに, わざわざ FreeBSD をブートしなおしたくはないでしょう. このような 場合のために, init は, SIGHUP (hangup) シグナルを受信すると, /etc/ttys を読み込みなおすようになっています. /etc/ttys の変更を保存したら, 以下のようなコマンドを実行して, init に対して SIGHUP を送信します. &prompt.root; kill -HUP 1 (init プロセスのプロセス ID は 常に 1です. ) すべての設定が正しくおこなわれ, すべてのケーブルがただしく接続されてい て, かつ端末の電源が入っていれば, 端末にはログインプロンプトが表示され ているはずです. これで, これらの端末からの最初のログインの準備が完了で す! トラブルシューティング 細心の注意を払って設定をおこなっても, ときには端末の接続がう まくいかない場合があるでしょう. 以下に, よく見られる問題とその解決方法 を示します. ログインプロンプトが表示されない 端末の電源が接続され, スイッチが入っていることを確認してください. もし, PC を端末として利用している場合は, 通信ソフトが適切なシリアルポー トを利用する設定になっているかどうか確かめてください. ケーブルがしっかりと端末と FreeBSDが動作しているコンピュータの両方に接続され ていることを確認してください. また, 正しい種類のケーブルを利用している か確かめてください. 端末と FreeBSD の間の通信速度とパリティの設定が一致していることを確認 してください. 出力をモニタに表示するタイプの端末の場合は, モニタ のコントラストと明るさの設定を確認してください. また, 出力が印刷 されるタイプの端末の場合は, 紙とインクが十分にあるかどうかを確かめてく ださい. getty が動いていて, 端末を認識していることを確認してください. 以 下のコマンドで動作中の getty プロセスのリストを得ることができます. &prompt.root; ps -axww|grep getty その端末に対する getty の情報が表示されるはずです. たとえば, 以下 の表示例は, getty は 2番目のシリアルポート (ttyd1) に対し て /etc/gettytab 中の std.38400 のエントリを使って動作し ているということを示しています. 22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyd1 もし, getty プロセスが一つも動いていないようであれば, /etc/ttys の中で, そのポートを利用可能にする設定をしたかどう か確かめてください. また, kill -HUP 1 を確実に実行してください. ログインプロンプトの代わりにゴミが表示される 端末と FreeBSD の間の通信速度およびパリティの設定が一致していることを確 かめてください. また, getty プロセスの情報を調べて, 適切な getty のタイプが使用されていることを確認してください. 間違った getty タイプが使用されている場合は, /etc/ttys を修正し てから, kill -HUP 1 を実行してください. 文字が重複して表示される, 入力したパスワードが表示される 端末または通信ソフトの設定で, 半二重 (half duplex) あるいは ローカ ルエコー となっているところを, 全二重 (full duplex) に変更してください. ダイアルインサービス ダイアルインサービス 原作: &a.ghelmer;. 訳: &a.max;. 6 September 1996. このドキュメントでは, FreeBSD で外部からのモデムによるアクセスを受け付 けるための設定に関してまとめてあります. このドキュメントは筆者が FreeBSD 1.0, 1.1 および 1.1.5.1 での経験と, 他の Unix 系 OS での経験を 基に書いたものですが, 必ずしも十分な内容でないかもしれませんし, 掲載し た実例もあなたが今お使いの環境とは一致しないかもしれません. また, 筆者 はこのドキュメントに従って行われた作業で データが失われたりシステムが破 壊されるようなことがあっても, 一切責任をとれません. 設定を始める前に 筆者は, 読者が FreeBSD に関する基本的な知識をもっていることを仮定して このドキュメントをまとめました. まず, FreeBSD が既にインストールされ ていて, Unix 系環境においてファイルの編集の方法やシステムに付属のマニュ アルを参照する方法を知っている必要があります. また, 以下に示すように, FreeBSD の特定のバージョンが必要となりますし, いくつかの用語に関する 知識, そしてモデムや多少の配線に関する知識も必要となります. FreeBSD のバージョン まず, FreeBSD のバージョンは 1.1 以上を使用してください (バージョン 2.X でもかまいません. ). FreeBSD 1.0 には, 2種類のシリアル ドライバ が含まれているので, 混乱の元となり得ます. また, FreeBSD のシリアル ディバイス ドライバ (sio) は, バージョンを追う毎に改善されてき ていますので, より新しいバージョンの FreeBSD を使用することで, よりよ い, より効率の高いドライバを利用することができるはずです. 用語解説 以下, 簡単にいくつかの用語について解説しておきます. bps bits-per-second Bits per Second　の略で, データの転送速度を表す単位. DTE DTE Data Terminal Equipment の略. たとえばコンピュータ本体のこと. DCE DCE Data Communications Equipment の略で, 具体的にはモデムのこと. RS-232 RS-232 ケーブル EIA (米電気産業協会) のハードウェア間シリアル通信の標準規 格. これらの用語やデータ通信一般に関して, より詳しい情報が必要な場合は, The RS-232 Bible という本 (誰か ISBN 分かる方いませんか?) が参考 になると思います. 通信においてのデータ転送速度に関して, このドキュメントでは ボーレー ト (baud rate) ではなく, bps (bits per second) をその単位として 使うことにします. これは, ボーというのは一定時間に生じる電気的状態の変 化の数を表す単位にすぎず, bps という単位の方が実体に即しているか らです. (少なくとも, こういう表現をしておけば, 意地の悪い人に怒られる こともないのではないかと思います. ) 外づけモデムと内蔵モデムについて ダイアルアップのサービスに関していえば, 外づけのモデムの方が適している ようです. これは, 多くの外づけのモデムは設定を不揮発ラムに書き込んで半 永久的に保存することができますし, また RS-232 に関する重要な情報を知る ための点滅するライトによるインディケータが 搭載されているからです. 点滅 するライトは, システムを見に来た訪問者に強い印象を与えるという効果だけ でなく, モデムが適切に動作しているかどうかを知るためにも 有効です. 一方, たいていの内蔵型のモデムには 不揮発性ラムが搭載されていないため, ディップ スイッチの変更以外に設定を保存する方法がありません. また, も しインディケータがついていても, おそらくコンピュータのケース カバーが 外されていなければその状態を確認するのは 難しいでしょう. モデムとケーブル 以下のことに関して, 予め知っておく必要があります. コンピュータとモデムの間での通信が 行えるようにするための接続方 法. (内蔵型の場合は接続の必要はありません) お使いのモデムのコマンドについての知識, あるいはコマンドの解説 の在処 (通信ソフトを使っての) モデムの不揮発ラムに保存可能な設定の変更 方法 1番目のモデムの接続はたいてい簡単に行えるはずです. ほとんどのストレー ト シリアル ケーブルが使えるでしょう. 使用すべきケーブルは, 両端に適 切なコネクタ (DB-25 または DB-9 の雄または雌) のついた, DCE-DTE 間接 続用のもので, 以下の信号線が接続されていなければなりません. モデムコマンド Transmitted Data (SD) Received Data (RD) Request to Send (RTS) Clear to Send (CTS) Data Set Ready (DSR) Data Terminal Ready (DTR) Carrier Detect (CD) Signal Ground (SG) FreeBSD で 2400bps 以上の転送速度を利用する場合には, フロー制御のため に RTS 信号と CTS 信号が必要です. また, 接続の確立と回線の切 断を検出するために CD 信号を利用します. さらに, DTR 信号を使っ て回線切断後のモデムのリセットを行います. ケーブルの中には, 総ての必要 な信号線が接続されていないものもありますので, たとえば, 回線切断後でも ログイン セッションが残ってしまうといった問題が発生した場合などには, ケーブルに問題がある可能性もあります. 次に, お使いのモデムにもよりますが, もしモデムのコマンドをよく覚えてい ない場合は, モデムのマニュアルをすぐに参照できるようにしておいてくださ い. このドキュメントでは例として USR Sportstar の 14,400 bps の外づけ型 モデムのコマンドを示しておきます. 他の種類のモデムをお使いの場合も, 参 考になるかもしれません. 最後に, FreeBSDで快適にモデムを使うためにも, モデムの設定方法を知って おく必要があります. FreeBSD も他の Unix 系 OS と同様, 回線の接続およ び切断の検出や回線の切断および回線切断後の モデムの初期化にハードウェア シグナルを利用します. FreeBSD は, モデムに対するコマンドの送信やモデ ムの状態の監視を行いません. パソコンで運用されている BBS への接続に慣 れている方にとっては, ちょっとめんどうかもしれませんね. シリアル インタフェースについて FreeBSD では, NS8250-, NS16450-, NS16550- および NS16550A- に基づ いた EIA RS-232C (CCITT V.24) 規格のシリアル インタフェースをサポート しています. 8250 および 16450 ベースのディバイスには1文字のキャラクタ バッファが搭載されています. また, 16550 系のディバイスには, 16文字分 のバッファが搭載されていて, はるかによいパフォーマンスを得られます. (ただし, 無印の 16550 では, バグがあって 16 文字バッファが利用できませ んので, 可能であれば 16550A 系のディバイスを利用してください. ) 1文字 のバッファの物は, 16550 系のものと比べて OS にかける負荷が大きいので, 16550A 系ディバイスの利用を強く推奨します. 多数のシリアル ポートを利 用する場合や, 負荷の高いシステムにおいては, 16550A 系ディバイスを使う ことで, エラー発生率を低く押さえることができます. 概要 FreeBSD は以下の手順でモデムからのログインを受付ます. init から起 動された getty のプロセスが, 割り当てられたシリアル ポート (この 例では /dev/ttyd0) がオープンされるのを辛抱強く待ちます. ps ax コマンドを実行すると, 以下のような出力が得られるはずです. 4850 ?? I 0:00.09 /usr/libexec/getty V19200 ttyd0 ユーザがモデムに電話をかけ, モデム同士が接続されると, モデムの CD が検出されます. その結果, kernel がキャリア信号を検出して, getty によるポートのオープンの処理が終了します. getty は, login: プロンプトを指定されている初期回線速度で送信します. getty は, 正常に文字列を受信できるかどうか監視し, 通常の設定では, もし以上な文字列を検出した場合 (理由としては, getty の速度とモデ ムの接続速度が異なっているような場合が考えられます. ), 正常に文字列が 受信できるまで, getty は速度を変え続けます. /usr/bin/login getty が正しい速度を検出すれば, ユーザに対して login: プロン プトが表示されるはずです. ユーザがログイン名を入力すると, getty は /usr/bin/login を起動して, パスワードの入力を要求し, その 後ユーザのシェルを起動します. それでは, 続いて設定についての解説です. kernel の設定 通常, FreeBSD の kernel は, MS-DOS の世界で COM1:, COM2: , COM3: および COM4: と呼ばれる四つのシリアル ポートを 探す ように設定されています. また, FreeBSD では, 現在のところ Boca の 1008 や 2016 のような, 単純なマルチポートのシリアル インタフェースもサポー トしています. (マルチポートのシリアル ボードに関しての kernel の設定 については, &man.sio.4; のマニュアルを参照してください. ) デフォルト の kernel は, COM ポートだけを探します. 搭載されているシリアル ポートのいずれかを, kernel が認識しているかどう か確認したい場合は, kernel 起動時のメッセージを注意深く見ているか, あ るいは /sbin/dmesg コマンドを使って, ブート時の出力メッセージ を確認してください. 特に, sio で始まるメッセージをよく見てくださ い. 参考までに, 以下のコマンドで sio という文字列を含むメッセージ だけを表示することができます. &prompt.root; /sbin/dmesg | grep 'sio' たとえば, シリアル ポートを四つ持つシステムの場合は, 以下のようなシリ アル ポートに関するメッセージが kernel によって表示されます. sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A sio3 at 0x2e8-0x2ef irq 9 on isa sio3: type 16550A もし, kernel に正常に認識されないポートがある場合は, おそらくカスタマ イズした kernel を構築する必要があるでしょう. kernel 構築と構築のための設定に関しては, BSD System Manager's Manual の Building Berkeley Kernels with Config (config コマンドによる BSD kernel の構築) [ソース ファイルは /usr/src/share/doc/smm にあります]と FreeBSD Configuration Options [ /sys/conf/options および /sys/arch/conf/options.arch の arch の部分をたとえば i386 としたファイル ] を参照 してください. kernel の設定と構築をするためには, kernel のソース (FreeBSD 1.1 では srcdist/srcsys.??, FreeBSD 1.1.5.1 では srcdist/sys.??, またFreeBSD 2.0 では総てのソース)を展開 する必要があります. まだ自分のシステムの kernel 用のコンフィギュレーション ファイルを作っ ていない場合は, /sys/i386/conf に cd して作成してくださ い. 初めてコンフィギュレーション ファイルを作る場合は, まず GENERICAH (FreeBSD 1.x で BusTek の SCSI コントローラを使っている場合は GENERICBT) というファイルを, YOURSYS にコピーしてください. ここ で, YOURSYS はあなたのシステム名で, 大文字である必要があります. このファイルを編集して, ディバイスに関する記述を変更します. device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr device sio3 at isa? port "IO_COM4" tty irq 9 vector siointr システムに搭載されていないディバイスに関する記述は, コメントアウトまた は削除してしまってかまいません. Boca の BB2016 のようなマルチポートの シリアル ボードをお持ちの場合は, &man.sio.4; のマニュアルを見て, マ ルチポートのボードのためのコンフィギュレーション ファイルの記述のし方 に関して確認してください. ディバイスのフラグの 指定方法がバージョンによっ て異なりますので, 別のバージョンの FreeBSD で利用していたコンフィギュ レーション ファイルを流用する場合には 十分注意してください. なお, port "IO_COM1", IO_COM2, IO_COM3 および IO_COM4 は, それぞれのポートの一般的なアドレスである 0x3f8, 0x2f8, 0x3e8 および 0x2e8 を表します. また, 割り込 み番号 4, 3, 5 と 9 は, それぞれ COM1: から COM4: のポー トで一般的に使用される IRQ です. また, ISA バスのコンピュータの場合, 一般的なシリアルポートは複数のポートで一つの IRQ を共有することが できませんので注意が必要です. (マルチポートのシリアル ボードの 場合は, 複数の 16550A ベースのポートで一つまたは二つの IRQ を共有する ための機構を備えています. ) コンフィギュレーション ファイルの編集が終わったら, Building Berkeley Kernels with Config (config コマンドによる BSD kernel の構築) および &man.config.8; のマニュアルにしたがって, config コマンド を使って kernel 構築のためのディレクトリを作成した後, kernel の構築, インストールおよびテストを行ってください. ディバイス スペシャル ファイル kernel に組み込まれているほとんどのディバイスは, /dev ディレ クトリにある, ディバイス スペシャル ファイル を介してアクセスされ ます. sio ディバイスの場合は, 着信用の /dev/ttyd? およ び, 発信用の /dev/cuaa? が利用されます. さらに, FreeBSD の 1.1.5 以降では, 初期化ディバイス (/dev/ttyi? と /dev/cuai0?) およびロッキング ディバイス (/dev/ttyld? と /dev/cual0?) も合わせて利用されます. 初期化ディバイスは, 通信 ポートがオープンされる度に, そのポートの初期設定を行うために使われます. たとえば, CTS/RTS によるフロー制御を行うモデムが接続されてい る場合の crtscts などのパラメータの初期化が行われます. ロッキング ディバイスは, ポートの設定をロックし, 他のユーザやプログラムにこれらを 変更されることのないようにするために利用されます. 通信ポートの設定, 初 期化とロックおよび設定の変更に関しては, それぞれ &man.termios.4;, &man.sio.4; と &man.stty.1; のマニュアルをご覧ください. ディバイス スペシャル ファイルの作成 ディバイス スペシャル ファイルの管理は, ディレクトリ /dev にあるシェル スクリプト MAKEDEV によって行います. (FreeBSD 1.1.5 の &man.MAKEDEV.8; のマニュアルの COM ポートに関する記述は, かなりいい加減なので無視してください. ) MAKEDEV を使って, COM1: (ポート 0) をダイアルアップのポートとして利用するためのディ バイス スペシャル ファイルを作るには, /dev に cd して から, MAKEDEV ttyd0 と実行してください. 同様に, MAKEDEV ttyd1 とすることで, COM2: (ポート 1) 用のディバイス スペシャル ファイル を作成することができます. MAKEDEV は, /dev/ttyd? のディバイス ファイルだけでなく, /dev/cuaa? (および FreeBSD 1.1.5 以降では総ての初期化ディバイ スとロッキング ディバイスのスペシャル ファイル) も作成します. さらに, もしシリアル端末用のスペシャル ファイル /dev/tty0? が存在すれ ば, それらの削除も行います. ディバイス スペシャル ファイルの作成後, これらのファイルのパーミション が適切に設定されていて, これらのディバイスを利用してもよいユーザのみが 読み書きできるようになっていることを確認してください. (特に /dev/cua* のパーミションには注意を払ってください. ) この確認 を怠ると, 一般のユーザがあなたのモデムを使うことができるようなことにな りかねません. デフォルトの /dev/cua* のパーミションは, 以下の ようになっていて, たいていの場合適切なものだと思います. crw-rw---- 1 uucp dialer 28, 129 Feb 15 14:38 /dev/cuaa1 crw-rw---- 1 uucp dialer 28, 161 Feb 15 14:38 /dev/cuaia1 crw-rw---- 1 uucp dialer 28, 193 Feb 15 14:38 /dev/cuala1 上の設定では, ユーザ uucp と, グループ dialer に属するユーザ が発信用のディバイスを利用できます. 設定ファイル FreeBSD のシステムへのダイアル アップによるアクセスを実現するために編 集が必要と思われる設定ファイルが, /etc ディレクトリに三つあ ります. まず, /etc/gettytab には, /usr/libexec/getty デーモンの設定を記述します. つぎに, /etc/ttys に保存されている情報から, /sbin/init はど の tty ディバイスに対して getty のプロセスを実行するべきか判 断します. 最後に, お使いの FreeBSD が 1.1.5.1 以降のものならば /etc/rc.serial スクリプトに, それ以前のものならば /etc/rc.local スクリプトにシリアル ポートの初期化のためのコマ ンドを記述することができます. Unix にダイアル アップ モデムを接続する方法には, 二つの考え方がありま す. 一つの方法は, ダイアル インしてくるユーザの接続速度に関係なく, 常 にモデムとローカルのコンピュータの RS-232 インタフェースの接続速度を一 定に保つように設定する方法です. この設定の長所は, ユーザがダイアル イ ンして接続されると, 即座にシステムからのログイン プロンプトが送信され るということです. 短所は, システムが実際のモデム間の速度を知ることがで きないために, Emacs のようなフル スクリーンのプログラムが, 端末との接 続速度が遅い場合でも, そのような場合に効果的な方法で画面出力を行わない 点です. もう一つは, モデムの RS-232 インタフェースとコンピュータの接続速度を, モデム間の接続速度に応じて変化させるような設定です. たとえば, モデム間 の接続が V.32bis (14.4 Kbps) ならば, モデムとコンピュータの間の接続を 19.2 Kbps とし, モデム間の接続が 2400 bps の時には, モデムとコンピュー タ間も 2400 bps で接続するような設定をします. この場合, getty は, モデムが返すリザルト コードからモデムとコンピュータの接続速度を認識す ることができませんので, getty は, まず初期速度で login: とい う文字列を送信して, それに対する応答の文字列を監視します. ここで, ユー ザ側の端末に無意味な文字列が表示された場合, ユーザは意味のある文字列を 受信するまで <Enter> キーを繰り返し押さなければならない ということを知っていると仮定しています. もし接続速度が間違っている場合, getty は, ユーザから送られた文字を無意味な文字列として扱い, 次の 速度を試します. そして, ここで再度 login: プロンプトを送信します. この一連の動作が異常な回数繰り返されることも考えられますが, 普通は1度 か2度のキー入力があれば, ユーザはまともなプロンプトを受信できます. こ のログインの動作が前者の固定速度による方法に 比べて美しくないのは明らか ですが, この方法では, 低速度で接続しているユーザに対するフル スクリー ンのプログラムからのレスポンスが改善されます. このドキュメントでは, 両方の設定方法について解説しますが, どちらかとい うとモデム間の速度に応じて RS-232 インタフェースの速度が変化するような 設定の方に偏った説明になってしまうと思います. <filename>/etc/gettytab</filename> /etc/gettytab /etc/gettytab は, &man.getty.8; の設定ファイルで, &man.termcap.5; と同様の形式で記述されます. ファイルのフォーマットや定 義できる機能についての詳細については, &man.gettytab.5; のマニュアルを ご覧ください. 固定速度の設定 モデムとコンピュータ間の通信速度を固定して使う場合, おそらく /etc/gettytab に特に変更を加える必要はないはずです. 可変速度の設定 getty が利用するモデムとコンピュータの接続速度に関する情報を /etc/gettytab に記述する必要があります. もし, 2400 bps のモ デムをお使いになるのであれば, 既存の D2400 のエントリがそのまま利 用できるでしょう. このエントリは FreeBSD の 1.1.5.1 の gettytab には既に含まれていますので, あなたの FreeBSD のバージョンでこのエント リが存在しているのであれば, 新たに追加する必要はありません. # # Fast dialup terminals, 2400/1200/300 rotary (can start either way) # D2400|d2400|Fast-Dial-2400:\ :nx=D1200:tc=2400-baud: 3|D1200|Fast-Dial-1200:\ :nx=D300:tc=1200-baud: 5|D300|Fast-Dial-300:\ :nx=D2400:tc=300-baud: 高速モデムをお使いの場合は, おそらく /etc/gettytab に新たなエ ントリを追加する必要があります. 以下の例は, 14.4 Kbps のモデムを, 最 大インタフェース速度を 19.2 Kbps として利用するためのエントリです. # # Additions for a V.32bis Modem # um|V300|High Speed Modem at 300,8-bit:\ :nx=V19200:tc=std.300: un|V1200|High Speed Modem at 1200,8-bit:\ :nx=V300:tc=std.1200: uo|V2400|High Speed Modem at 2400,8-bit:\ :nx=V1200:tc=std.2400: up|V9600|High Speed Modem at 9600,8-bit:\ :nx=V2400:tc=std.9600: uq|V19200|High Speed Modem at 19200,8-bit:\ :nx=V9600:tc=std.19200: 上記の例を利用した場合, FreeBSD 1.1.5 以降ではパリティなし, 8ビットの 接続が行われます. FreeBSD 1.1 では, :np: パラメータをファイルの 先頭の std.xxx のエントリに追加することで, パリティなし, 8ビットの接続が行われますが, このパラメータを追加しなければ接続は偶数 パリティ, 7ビットになります. 上記の例では, まず 19.2 Kbps (V.32bis) によるモデムとコンピュータ間の 接続を試み, 続いて 9600 bps (V.32), 2400 bps, 1200 bps, 300 bpsと順に 試み, 再び 19.2 Kbps による接続を試みるという循環に入ります. この接続 速度の循環は, nx=(next table) の機能で実現されています. ま た, 各行はそれぞれ tc=(table continuation) の機能を使って, その他の接続速度に依存した 標準的な 設定を取り込んでいます. もし, お使いのモデムが 28.8 Kbps であったり, 14.4 Kbps の圧縮転送の機 能を有効に利用したい場合は, 19.2 Kbps よりも速い速度を利用するように 設定する必要があります. 以下に 57.6 Kbps から接続を試みる gettytab の設定例を示しておきます. # # Additions for a V.32bis or V.34 Modem # Starting at 57.6 Kbps # vm|VH300|Very High Speed Modem at 300,8-bit:\ :nx=VH57600:tc=std.300: vn|VH1200|Very High Speed Modem at 1200,8-bit:\ :nx=VH300:tc=std.1200: vo|VH2400|Very High Speed Modem at 2400,8-bit:\ :nx=VH1200:tc=std.2400: vp|VH9600|Very High Speed Modem at 9600,8-bit:\ :nx=VH2400:tc=std.9600: vq|VH57600|Very High Speed Modem at 57600,8-bit:\ :nx=VH9600:tc=std.57600: もし, お使いの CPU が低速のものであったり, CPU に対する負荷が高い場合 で, 16550A 系のシリアル ポートをお使いでない場合, 57.6 Kbps の接続に おいて, sio の silo エラーが発生するかもしれません. <filename>/etc/ttys</filename> /etc/ttys /etc/ttys には, init が監視すべき tty のリストを記 述します. さらに, /etc/ttys は, login に対してセキュリ ティに関する情報を提供します. (ユーザ root は, secure とマー クされている tty のみからログインできます. ) 詳しくは &man.ttys.5; のマニュアルをご覧ください. /etc/ttys の既存の行を変更するか, あるいは新しい行を追加して, init が自動的に新しいダイアル アップ サービス用のポートに対して getty プロセスを起動するようにしてください. 書式は, 固定速度の設 定か可変速度の設定かに関わらず, 以下のとおりです. ttyd0 "/usr/libexec/getty xxx" dialup on 1番目の項目は, このエントリで対象とするディバイス スペシャル ファイル です. 上の例では ttyd0 として, /dev/ttyd0 を getty に監視させることを表しています. 2番目の項目 "/usr/libexec/getty xxx" (xxx は初期段階で使われる gettytab のエントリ に置き換えてください. ) が, init がこのディバイスに対して起動する プロセスです. 3番目の dialup は, デフォルトのターミナル タイプで す. 4番目の on は, この行が有効であることを init に対して示 しています. 5番目の項目に secure を指定することもできますが, これ は, たとえばシステムのコンソールのように, 物理的に安全な端末に対しての み指定するようにしてください. デフォルトのターミナル タイプ (上記の例では dialup) は, ローカル のユーザの好みによって異なってきます. ユーザがログイン スクリプトをカ スタマイズして, ターミナル タイプが dialup の時には自動的に他のター ミナル タイプを設定できるように, ダイアル アップのポートのデフォルトの ターミナル タイプには dialup が伝統的に用いられています. しかし, 筆者のサイトでは, ほとんどのユーザが VT102 エミュレイションを使ってい るので, ダイアル アップのポートのデフォルト ターミナル タイプとして vt102 を指定しています. /etc/ttys の修正がすんだら, 以下のようなコマンドを使って init プロセスに HUP シグナルを送り, /etc/ttys を 読み込み直させてください. &prompt.root; kill -HUP 1 ただ, もし初めてシステムを設定しているのであれば, モデムが適切に設定さ れて接続されるまでは, init に対してシグナルを送らない方がいいか もしれません. 固定速度の設定 速度を固定する設定では, /etc/ttys の中で, getty に対し て固定速度のエントリを指定する必要があります. たとえば, 以下の例はポー トのスピードが 19.2 Kbps に固定されたモデムのための ttys のエント リです. ttyd0 "/usr/libexec/getty std.19200" dialup on 別の速度でモデムのポートのスピードを固定したい場合は, /etc/gettytab から適切なエントリを選んで, 上の例の std.19200 の部分を std.speed として, 適切な速度のも のに置き換えてください. 可変速度の設定 可変速度の設定では, ttys のエントリが, /etc/gettytab の中の適切な 自動速度調整 の初期設定のエントリを参照していなければな りません. たとえば, もし前述の 19.2 Kbps から接続を試みる可変速度の設 定例 (V19200 の gettytab エントリ)をそのまま ttys に追 加したのであれば, ttys エントリは以下のようになります. ttyd0 "/usr/libexec/getty V19200" dialup on <filename>/etc/rc.serial</filename> または <filename>/etc/rc.local</filename> rc ファイル rc.local rc ファイル rc.serial V.32, V.32bis または V.34 モデムのような高速モデムを利用する場合, ハー ドウェア (RTS/CTS) フロー制御を行う必要があります. FreeBSD kernel のモデム ポートにハードウェア フロー制御のフラグを設定するため の stty コマンドを, FreeBSD 1.1.5.1 以降では /etc/rc.serial に, FreeBSD 1.1 では /etc/rc.local に 記述できます. たとえば, FreeBSD 1.1.5.1 の /etc/rc.serial のサンプルは以下 のとおりです. #!/bin/sh # # Serial port initial configuration stty -f /dev/ttyid1 crtscts stty -f /dev/cuai01 crtscts この例では, termio のフラグ crtscts をシリアル ポート #1 (COM2:) のダイアル インおよびダイアル アウトの初期化ディバイスに 設定しています. 古い FreeBSD 1.1 では, 以下のエントリが crtscts フラグを設定する ために /etc/rc.local に追加されていました. # Set serial ports to use RTS/CTS flow control stty -f /dev/ttyd0 crtscts stty -f /dev/ttyd1 crtscts stty -f /dev/ttyd2 crtscts stty -f /dev/ttyd3 crtscts FreeBSD 1.1 には初期化のためのディバイス スペシャル ファイルがないので, ディバイス ファイルそのものにフラグを設定して, その後はフラグをクリア してしまうような極悪人が現れないことを願うしかありません. モデムの設定 もし, あなたのモデムがパラメータを不揮発ラムに 保存できるタイプならば, MS-DOS 上の Telix や FreeBSD 上の tip などのような通信プログラム を使って, パラメータを設定してください. getty が利用する初期速度でモデムに接続して, 以下の条件を満たすよ うに不揮発ラムの設定を変更してください. 接続時に CD 信号がオンになる 接続時に DTR がオンになり, DTR オフで回線を切断しモ デムをリセットする. 送信時フロー制御には CTS を利用. XON/XOFF によるフロー制御を行わない. 受信時のフロー制御は RTS を使用. Quiet mode (リザルト コードを返さない) コマンド エコーを返さない. これらを実現するためのコマンドやディップ スイッチの設定に関しては, モ デムのマニュアルを参照してください. 以下に, USRobotics Sportster の 14,400 bps の外づけモデムの設定例を示 しておきます. ATZ AT&C1&D2&H1&I0&R2&W ことのついでに, たとえば, V42.bis や MNP5 のデータ圧縮を使用するかど うかなどのモデムの他の設定について確認, 調整しておくのもよいかもしれま せん. さらに, USRobotics Sportster の 14,400 bps の外づけモデムでは, 以下の ようなディップ スイッチの設定も必要です. 他のモデムをお使いの方も, 以 下の例を設定の参考にしてください. スイッチ1: UP — DTR 標準 スイッチ2: 無視 (リザルト コードを単語形式にするか数値形式にす るか) スイッチ3: UP — リザルト コードを返さない スイッチ4: DOWN — コマンド エコーを返さない スイッチ5: UP — 自動着信 スイッチ6: UP — CD 標準 スイッチ7: UP — 不揮発ラムからデフォルト値をロードする スイッチ8: 無視 (Smart Mode/Dumb Mode) リザルト コードを返さないように設定しておかないと, getty が誤っ て login: プロンプトをコマンド モードのモデムに送信してしまった場 合に, モデムがこの入力をエコーしたり, この入力に対するリザルト コード を返してしまったりすることになります. この結果として, モデムと getty の間で延々と無意味なやりとりが続いたというケースを聞いたこ とがあります. 固定速度の設定 固定速度の設定では, モデムとコンピュータ間の通信速度をモデムとモデム間 の接続速度に関係なく, 常に一定に保つように, モデムを設定する必要があり ます. USRobotics Sportster の 14,400 bps 外づけモデムの場合, 以下のコ マンドで, モデムとコンピュータ間の速度が, コマンド送信時の速度に固定さ れます. ATZ AT&B1&W 可変速度の設定 可変速度の設定では, シリアル ポートの速度が, 着信速度に応じて変化する ように設定しなければいけません. USRobotics Sporster の 14,400 bps 外 づけモデムの場合, 以下のコマンドで, エラー訂正機能を利用した通信の場合 は, コマンドを送信した時の通信速度にシリアル ポートの速度を固定し, エ ラー訂正機能を利用しない接続では, シリアル ポートの速度が変化するよう に設定されます. ATZ AT&B2&W モデムの設定の確認 ほとんどの高速モデムには, 現在の設定をある程度人間にも理解できる形式に して表示させるコマンドがあります. USRobotics Sporster の 14,400 bps 外づけモデムの場合は, ATI5 コマンドで, 現在の不揮発ラムの設定を 表示することができます. さらに, ディップ スイッチの設定も含めた現在の 設定を確認するためには, ATZ コマンドを送信してから, ATI4 コマンドを送信してください. 他のメーカーのモデムをお使いの場合は, モデムのマニュアルで設定値の確認 方法を確認してください. トラブルシューティング 以下の手順でダイアル アップ モデムの動作を確認することができます. FreeBSD システムの動作確認 モデムを FreeBSD システムに接続し, システムをブートします. あなたのモ デムにモデムの状態を確認するためのインジケータがあれば, DTR のイ ンジケータの状態に注目してください. もし, システムのコンソールに login: プロンプトが表示された時に, DTR のインジケータが点灯 すれば, FreeBSD が適切なポートに対して getty を起動し, モデムへ の着信を待っている状態であることを意味しています. もし DTR のインジケータが点灯しない場合は, システムのコンソールか ら FreeBSD にログインして, ps ax を実行し, FreeBSD が 適切なポー トに対してgetty プロセスを起動しようとしているのかどうか確認して ください. プロセスに関する情報の中に, 以下のような行が表示されるはずで す. 114 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd0 115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1 モデムにまだ着信がない状態の時に, 以下のように上とは異なる出力があった 場合, getty は既にモデム ポートのオープンを終了したということに なります. 114 d0 I 0:00.10 /usr/libexec/getty V19200 ttyd0 getty は, CD (carrier detect) 信号がオンの状態になるまで, ポートのオープンを完了することはできませんので, この場合は接続に問題が あるか, あるいはモデムの設定に問題があることが考えられます. もし, 適切なポートをオープンしようとしている getty が見あたらない 場合は, 再度 /etc/ttys の内容を確認し, 書式などに誤りがないか 調べてみてください. また, ログ ファイル /var/log/messages に init および getty から何か出力がないかどうかも確認してみてく ださい. もし何かメッセージが記録されていたら, 再度 /etc/ttys , /etc/gettytab の二つの設定ファイルと, ディバイス スペシャル ファイル /dev/ttyd? を確認し, 記述に誤りがないか, 足りないエ ントリがないか, 足りないディバイス スペシャルファイルがないかといった 点について調べてみてください. モデムで接続してみる 実際にモデムを使って別のコンピュータから 接続してみてください. この時, 8ビット, パリティなし, 1ストップ ビットで接続するようにしてください. 接続後すぐにプロンプトが返ってこない場合や, 無意味な文字列が表示される 場合は, 1秒に1回くらいの割合で <Enter> キーを押してみて ください. しばらくたって, なおも login: プロンプトが現れない場合 は, BREAK 信号を送信してみてください. この時, 端末側で使って いるモデムが高速モデムならば, このモデムのインタフェースの接続速度を固 定してから, 再度ダイアル インしてみてください. (たとえば, USRobotics Sportster の場合は, AT&B1) それでもまだ login: プロンプトが表示されない場合は, /etc/gettytab の以下の点について再度確認してみてください. /etc/ttys の対応する行の 2番目の項目で, /etc/gettytab の中で定義されているエントリが指定されているか 各 nx= で /etc/gettytab の中で定義されているもの が指定されているか 各 tc= で /etc/gettytab の中で定義されているもの が指定されているか もしダイアル インしても, FreeBSD システム側のモデムが応答しない場合は, FreeBSD 側のモデムが DTR がオンになった時に電話にでるように設定さ れているかを確認してください. もしモデムの設定に問題がなさそうならば, モデムのインジケータ (がもしあれば) で, DTR がオンになっているか を確認してください. この確認のステップを数回繰り返しても うまくいかない場合は, 一度休憩して, しばらくたってから挑戦してみましょう. それでもだめなら, おそらく &a.questions; にあなたのモデムについての情報と問題を書いたメールを送れ ば, メーリング リストのメンバーが問題の解決を助けるべく努力してくれる でしょう. 謝辞 以下の方々から, 多くのコメントやアドバイスをいただきました. ここに謝意 を表します. Sean Kelly <kelly@fsl.noaa.gov> 多くのすばらしい助言をいた だきました ダイアルアウトサービス ダイアルアウトサービス 原作: FAQ からの情報 訳: &a.jp.tmaruya;. 31 December 1996. 以下はモデムを利用して他のコンピュータと 接続する方法を説明しています. これはリモートホストとターミナル接続を確立するための 適切な方法です. これは BBS に接続するときによく使います. この種の接続は PPP 接続に問題がある場合, Internet 上にあるファイルを 転送するのに非常に役に立ちます. FTP で何らかのファイルを転送したいのに PPP 接続を確立できない場合は, ファイルを FTP 転送するためにターミナルセッション を利用します. そして ZMODEM を利用してファイルを転送します. <command>tip</command> や <command>cu</command> が実行できないはなぜ? あなたのシステムで tip や cu というプログラムは uucp や dialer というグループに所属しているユーザのみが 実行できるようになっているのでしょう. リモートホストやモデムを 利用できる dialer のグループにあなたのアカウントを 加えましょう. もしくは下記のコマンドを使うことによって, そのシステムで tip や cu を誰でも使えるようになります: &prompt.root; chmod 4511 /usr/bin/tip このコマンドは cu に対しておこなう必要はありません, それは cu は tip に対するハードリンクだからです. 私の Hayes モデムはサポートされていません, どうしよう? 実際, tip の マニュアルページは古くなっています. 既に Hayes ダイアラが組み込まれています. /etc/remote ファイル中で at=hayes を使ってください. Hayes ドライバは, 最近のモデムの新しい機能である BUSY, NO DIALTONE, CONNECT 115200などのメッセージを 認識できるほど賢くはなく, 単に混乱を起こすだけです. tipを使う場合には, (ATX0&W とするなどして) これらの メッセージを表示させないようにしなくてはいけません. また, tip のダイアルのタイムアウトは 60秒です. モデムの タイムアウト設定はそれより短くすべきであり, そうしないと tip は通信に問題があると判断するでしょう. ATS7=45&W を実行してください. 実際, デフォルトの tip は Hayes の完全なサポートを しているわけではありません. 解決方法は /usr/src/usr.bin/tip/tip の下の tipconf.h を変更することです. もちろんこれにはソース配布ファイルが必要です. #define HAYES 0 と記述されている行を #define HAYES 1 と変更し, そして make, make install を実行します. これでうまく動作するでしょう. これらの AT コマンドを入力するには? /etc/remote /etc/remote ファイルの中で direct エントリを作ります. たとえばモデムが 1番目のシリアルポートである /dev/cuaa0 に接続されている場合, 次のようにします: cuaa0:dv=/dev/cuaa0:br#19200:pa=none モデムがサポートする最大の bps レートを br フィールドに使います. そして tip cuaa0 を実行すると, モデムが利用できるようになります. /dev/cuaa0 がシステムに存在しない場合は, 次のようにします: &prompt.root; cd /dev &prompt.root; ./MAKEDEV cuaa0 または root になって以下のように cu コマンドを実行します: &prompt.root; cu -lline -sspeed line にはシリアルポートを指定します (例えば /dev/cuaa0). そして speed には接続する速度を指定します (例えば 57600). その後 AT コマンドを実行したら, ~. と入力すれば終了します. pn 機能の <literal>@</literal> 記号が使えません! 電話番号 (pn) 機能の中での @ 記号は, tip に /etc/phone にある電話番号を参照するように伝えます. しかし @ の文字は /etc/remote のような 設定ファイルの中では特殊文字となります. バックスラッシュを使ってエスケープをおこないます: pn=\@ コマンドラインから電話番号を指定するには? generic エントリと呼ばれるものを /etc/remote に追加します. 例えば次のようにします: tip115200|Dial any phone number at 115200 bps:\ :dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du: tip57600|Dial any phone number at 57600bps:\ :dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du: そして &prompt.root; tip -115200 5551234 のように利用できます. tip より cu を使いたい場合, cu の generic エントリを使います: cu115200|Use cu to dial any number at 115200bps:\ :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du: そして &prompt.root; cu 5551234 -s 115200 と実行します. 毎回 bps レートを入力しなければいけませんか? tip1200 や cu1200 用のエントリを記述し, 適切な通信速度を br フィールドに設定します. tip は 1200 bps が正しいデフォルト値であるとみなすので, tip1200 エントリを参照します. もちろん 1200 bps を使わなければならないわけではありません. ターミナルサーバを経由して 複数のホストへアクセスしたいんです. 毎回接続されるのを待って CONNECT <host> と入力する かわりに, tip の cm 機能を使います. 例えば, /etc/remote に次のようなエントリを追加します: pain|pain.deep13.com|Forrester's machine:\ :cm=CONNECT pain\n:tc=deep13: muffin|muffin.deep13.com|Frank's machine:\ :cm=CONNECT muffin\n:tc=deep13: deep13:Gizmonics Institute terminal server:\ :dv=/dev/cuaa2:br#38400:at=hayes:du:pa=none:pn=5551234: これで, tip pain や tip muffin と実行すると pain や muffin のホストに接続することができ, tip deep13 を実行するとターミナルサーバに接続します. tip を使ってそれぞれのサイトの 複数の回線に接続できますか? これは大学に電話回線がいくつかあって 数千人の学生が接続しようとする 場合によくある問題です. あなたの大学のエントリを /etc/remote ファイルに作成して, pn のフィールドには @ を使います: big-university:\ :pn=\@:tc=dialout dialout:\ :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none: そして /etc/phone ファイルに大学の電話番号の一覧を書きます: big-university 5551111 big-university 5551112 big-university 5551113 big-university 5551114 tip は一連の電話番号を試みて, 最終的に接続できなければあきらめます. リトライを続けさせたい場合は, tip を while ループに入れて 実行します. CTRL+P を 1回送るために 2度押す必要があるのはなぜ? CTRL+P は通常 force (強制) 文字であり, tip に次の文字が リテラルデータであることを伝えます. force 文字は 変数の設定 を意味する ~s エスケープによって他の文字にすることができます. ~sforce=single-char と入力して改行します. single-char は, 任意の 1バイト文字です. single-char を省略すると NUL 文字になり, これは CTRL+2 や CTRL+SPACE を押しても入力できます. また, single-char に SHIFT+CTRL+6 を割り当てる方法を使っているターミナルサーバもあります. $HOME/.tiprc に次のように定義することで, 任意の文字を force 文字として利用できます: force=<single-char> 打ち込んだ文字が突然すべて大文字になりました?? CTRL+A を押してしまい, caps-lock キーが壊れている場合のために設計された tip の raise character モードに入ったのでしょう. 既に述べたように ~s を使って, raisechar をより適切な値に 変更してください. もしこれら両方の機能を使用しないのであれば, force 文字と同じ設定にすることもできます. 以下は CTRL+2 や CTRL+A などを頻繁に使う必要のある Emacs ユーザにうってつけの. tiprc ファイルのサンプルです: force=^^ raisechar=^^ ^^ は SHIFT+CTRL+6 です. <command>tip</command> でファイルを転送するには? もし他の Unix のシステムと接続しているなら, ~p(put) や ~t(take) でファイルの送受信ができます. これらのコマンドは 相手のシステムの上で cat や echo を実行することで 送受信をします. 書式は以下のようになります: ~p ローカルのファイル名 リモートのファイル名 ~t リモートのファイル名 ローカルのファイル名 この方法ではエラーチェックをおこないませんので, zmodem などの他のプロトコルを使った方がよいでしょう. <command>tip</command> から zmodem を実行するには? ファイルを受信するには, リモート側で送信プログラムを起動します. そして ~C rz と入力すると, ローカル側へのファイルの受信が 始まります. ファイルを送信するには, リモート側で受信プログラムを起動します. そして ~C sz files と入力すると, リモート側への ファイルの送信が始まります. シリアルコンソールの設定 シリアルコンソール 原作: &a.yokota;, &a.wpaul; この文書はほとんどが &a.wpaul; 氏の /sys/i386/boot/biosboot/README.serial に基づいています. 導入 FreeBSD/i386 オペレーティングシステムは, コンソールとして シリアルポート上のダム端末しか持たないシステムでも起動できます. この様な構成はきっと次のような二種類の人達に便利でしょう. それは, キーボードやモニタのないマシンに FreeBSD をインストールしたいシステム管理者と, カーネルやデバイスドライバをデバッグしたい開発者です. バージョン 3.1 から, FreeBSD/i386 は 3 ステージ構成ののブートストラップ を用いるようになりました. 最初の 2 つのステージは, ブートディスクにある FreeBSD スライスの最初に格納されている, ブートブロックのコードが行います. それからブートブロックは, 第 3 ステージのコードとしてブートローダ (/boot/loader) を読み込み, 実行します. (ブートプロセスの詳細については &man.boot.8; と &man.loader.8; をご覧下さい.) シリアルコンソールを設定するためには, ブートブロックコード, ブートローダコード, カーネルを設定する必要があります. FreeBSD バージョン 3.0 では, ブートローダはないので ブートストラップは 2 ステージです. つまり, ブートブロックが直接 カーネルをメモリに読み込みます. もしあなたが FreeBSD 3.0 を使って いるなら, このセクションでブートローダについて述べている部分は無視してください. それでもシリアルポートをコンソールとして使うのに支障はありません. FreeBSD バージョン 2.X と 3.X のシリアルポートドライバ &man.sio.4 は全く違いますので, 設定も異なった方法で行う必要があります. この章ではバージョン 2.X システム用の設定については扱っていません. もしあなたが古いバージョンの FreeBSD を使っているなら, かわりに /sys/i386/boot/biosboot/README.serial を調べてみてください. シリアルコンソールを設定するための 6 ステップ シリアルケーブルを用意してください. ヌルモデムケーブル ヌルモデムケーブル, もしくは標準シリアルケーブルとヌルモデムアダプタが必要となります. シリアルケーブルについては をご覧下さい. キーボードをはずして下さい. たいていの PC システムは Power-On Self-Test (POST) の間にキーボードを検出し, もし見つからなければエラーと なります. また, キーボードがないことを大きな音で知らせ, キーボードが接続されるまでは起動を中断するようなマシンもあります. コンピュータがエラーを表示していても, とにかく起動するなら特別な対応は必要ありません (Phoneix BIOS を搭載しているマシンには, Keyboard failed と表示されても, 正常に起動するものがあります). あなたのコンピュータがキーボードを接続していない状態で 起動しないようなら, (もし可能ならば) エラーを無視するように BIOS を設定する必要があります. 設定方法の詳細については, マザーボードのマニュアルを調べてください. BIOS の設定でキーボードを Not installed にするということは, キーボードを使えないということを 意味しているわけではありません. これは, BIOS がキーボードがなくても文句を言わないように, 電源投入時には キーボードを探すな, と指示するだけです. このフラグを Not installed にしていてもキーボードを 接続したままにできますし, ちゃんと動作します. あなたのシステムが PS/2 マウスを使っているなら, おそらくマウスもキーボード同様にはずす必要があるでしょう. というのは, PS/2 マウスは部分的にキーボードとハードウェアを 共有しており, マウスを接続したままにしていると, キーボードも存在する, と誤って検出してしまう可能性があるからです. AMI BIOS を持つ Gateway 2000 Pentium 90MHz システム はこれに該当すると言われています. 一般的にこれは問題ではありません. なぜなら, どっちにしても マウスはキーボードなしではたいして役に立たないからです. COM1: (sio0) にダム端末を接続してください. ダム端末がなければ, かわりに古い PC/XT でモデム プログラムを走らせて使ったり, シリアルボートに他の Unix マシンを繋いだりできます. もしも COM1: (sio0) がなければ, 作成してください. 今のところ, COM1: 以外のポートを 選択するためにはブートブロックの再コンパイルが必要です. すでに COM1: を他の装置に 使っていた場合は, 一時的にその装置をはずして いったん FreeBSD がうまく動作してから, 新しいブートブロックとカーネルをインストールしてください. (上記はとにかくファイル/演算/端末サーバの COM1: が利用可能であると仮定して います. あなたが本当に何かのために COM1: が必要 (で, なおかつその何かを COM2: (sio1) に付け替えることができない) ならば, 多分, そもそも 悩んでる場合ではありません.) カーネルコンフィグファイルの COM1: (sio0) に適切なフラグを 設定していることを確認してください. 関連するフラグ: 0x10 このポートのコンソールサポートを有効にします. このフラグが設定されない場合, 他のフラグは無視されます. 現在のところ, 一つのポートしかコンソールサポートを有効に できません. (config ファイルに書かれた順番で) 最初にこのフラグを 指定されたポートが選択されます. なお, このオプションを指定するだけでシリアルポートが コンソールとして使えるわけではありません. このフラグと一緒に, 以下のフラグも指定するかもしくは オプションも使ってください. 0x20 後述される オプション を無視して, (他に優先度の高いコンソールがない限り) このポートをコンソールとして指定します. このフラグは FreeBSD バージョン 2.X の COMCONSOLE オプションに対応するものです. フラグ 0x20 は必ず フラグ と一緒に指定されなければなりません. 0x40 (0x10 と組み合わせることで) このポートを予約し, 通常のアクセスができない ようにします. このフラグは, シリアルコンソールとして使いたいポートに 指定すべきではありません. 唯一の使い道は, ユニットがカーネルのリモートデバッグ用 であることを指定することです. リモートデバッグの詳細については The Developer's Handbook を参照してください. FreeBSD 4.0-CURRENT 以降では, フラグ 0x40 の意味が若干異なり, シリアルポートにリモートデバッグを指定するためには, 別のフラグを使います. 例: device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4 詳細については &man.sio.4; を参照して下さい. もしこれらのフラグがセットされていなければ, (別のコンソールで) UserConfig を実行するか, カーネルを再コンパイルする必要があります. ブートドライブの a パーティションの ルートディレクトリに boot.config を作成してください. このファイルは, ブートブロックコードに対してどのように システムを起動したいかを教えます. シリアルコンソールを活かすためには, 以下のオプションを幾つか dash; 複数の場合も一行で, 設定する必要があります: 内蔵コンソールとシリアルコンソールの切替えを行います. これを使用してコンソールデバイスを変更できます. 例えば, 内蔵 (ビデオ) コンソールからブートした場合, カーネルとブートローダがコンソールデバイスとして シリアルポートを使用するようにするため, を使って指示できます. 反対に, シリアルポートからブートした場合, ブートローダとカーネルがコンソールとして代わりに ビデオディスプレイを使用するようにするため, を使用できます. シングルとデュアルのコンソール設定を切り替えます. シングル設定では, 上記の オプションの状態によって,コンソールは内蔵コンソール (ビデオディスプレイ)かシリアルポートのいずれかになります. デュアルコンソール設定では, ビデオディスプレイと シリアルポートの両方が, オプションの状態によらず, 同時にコンソールになります. しかし, デュアルコンソール設定は, ブートブロックが 実行されている間でしか効果を持ちません. 一旦ブートローダに制御が移ると, オプションによって指定されたコンソールが 唯一のコンソールになります. ブートブロックがキーボードを検出するようにします. キーボードが発見できなかった場合には, と オプションが自動的にセットされます. 現バージョンのブートブロックでは容量の制限により, オプションは拡張キーボードしか 検出できません. キーが 101 個より少ない (そして F11 と F12 がない) キーボードは検出されない可能性があります. この制限から, いくつかのラップトップコンピュータの キーボードは正しく検出されないでしょう. 残念ながら, この問題の回避策はありません. オプションを使ってコンソールを 自動的に選ぶか, オプションを使って シリアルコンソールを有効にしてください. さらに &man.boot.8; で説明されている他のオプションも使う ことができます. 以外のオプションはブートローダ (/boot/loader) に渡されます. ブートローダは, オプションだけの状態を 調べることで内蔵ビデオとシリアルポートのどちらがコンソールに なるのか決めます. つまり, /boot.config の中で オプションを指定して オプションを指定しなかった場合, ブートブロック実行中でのみシリアルポートをコンソールとして 使うことができます. ブートローダは内蔵ビデオディスプレイを コンソールとして使います. マシンを起動する. FreeBSD を起動したとき, ブートブロックは /boot.config の内容をコンソールに表示 します. 例えば, /boot.config: -P Keyboard: no 行の二番目は, /boot.config にオプション が指定してあるときだけ表示され, キーボードが存在するかどうかを表します. これらのメッセージは, シリアルか内蔵のいずれか, あるいはその両方のコンソールに表示されます. どちらに表示されるかは, /boot.config の設定によって変わります. オプション指定 メッセージの表示される場所 なし 内蔵 シリアル シリアルと内蔵の両方 シリアルと内蔵の両方 , キーボードが存在する場合 内蔵 , キーボードが存在しない場合 シリアル このメッセージが表示された後, ブートブロックがブートローダのロードを再開し, 他の全てのメッセージがコンソールに表示されるまで, 若干時間がかかります. 通常の環境では, ブートブロックに 割り込みをかける必要はありませんが, ちゃんとセットアップされているかどうか確かめるために, 割り込みをかけることができるようになっています. ブートプロセスに割り込みをかけるには, コンソールの(Enter/Return キー以外の)キーをたたいて下さい. ブートブロックはその時, 操作を指定するためのプロンプトを表示します. こんな風に表示されるでしょう. >> FreeBSD/i386 BOOT Default: 0:wd(0,a)/boot/loader boot: 上に示したメッセージが, シリアルか内蔵, あるいはその両方といった, /boot.config で指定したとおりのコンソールに表示されることを確認して下さい. メッセージが正しいコンソールに表示されたら, Enter/Return キーを押してブートプロセスを継続してください. もし, シリアルコンソールを利用するように設定しているのに シリアル端末にプロンプトが出てこない場合は, 設定のどこかに間違いがあります. ブートブロック(とブートローダ, カーネル)に対して シリアルポートをコンソールに使うことを伝えるため, 割り込みをかけた時に を入力し, (可能ならば) Enter/Return キーを押して下さい. そして, 一度システムを起動させてから, どこが悪いのかをチェックして下さい. ブートローダがロードされ, ブートプロセスの第三ステージに いる時には, まだ内蔵コンソールとシリアルコンソールを切り替えることができます. それにはブートローダの環境変数を適切に設定すれは良いのですが, 詳細については を参照してください. まとめ このセクションで扱ったさまざまな設定と, 最終的に選択されるコンソールに関するまとめです. Case 1: sio0 の flags に 0x10 をセットした場合 device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4 /boot.config 内のオプション ブートブロック実行中のコンソール ブートローダ実行中のコンソール カーネルのコンソール なし 内蔵 内蔵 内蔵 シリアル シリアル シリアル 内蔵, シリアルの両方 内蔵 内蔵 内蔵, シリアルの両方 シリアル シリアル , キーボードが存在する場合 内蔵 内蔵 内蔵 , キーボードが存在しない場合 内蔵, シリアルの両方 シリアル シリアル Case 2: sio0 の flags に 0x30 をセットした場合 device sio0 at isa? port "IO_COM1" tty flags 0x30 irq 4 /boot.config 内のオプション ブートブロック実行中のコンソール ブートローダ実行中のコンソール カーネルのコンソール なし 内蔵 内蔵 シリアル シリアル シリアル シリアル 内蔵, シリアルの両方 内蔵 シリアル 内蔵, シリアルの両方 シリアル シリアル , キーボートが存在する場合 内蔵 内蔵 シリアル , キーボードが存在しない場合 内蔵, シリアルの両方 シリアル シリアル シリアルコンソールを利用する上で役に立つ情報 シリアルポートの通信速度をもっと速いものに設定するには デフォルトのシリアルポート通信速度は, 9600 ボー, 8 ビット, パリティなし, ストップビット 1 です. 通信速度を変更したい場合には, 少なくとも ブートブロックの再コンパイルが必要になります. /etc/make.conf に次のような行を追加して, 新しくブートブロックをコンパイルして下さい. BOOT_COMCONSOLE_SPEED=19200 もし, シリアルコンソールがブート時の オプション以外の方法で設定されていたり, カーネルが利用するシリアルコンソールが ブートブロック実行中のものと異なる場合には, カーネルコンフィグレーションファイルに次のオプションを追加して, 新しくカーネルをコンパイルしなければなりません. options CONSPEED=19200 <devicename>sio0</devicename> 以外のシリアルポートを コンソールとして使うには sio0 以外のポートをコンソールとして使うには, 再コンパイルが必要です. それがどんな理由であれ, 他のポートを使用する場合には ブートブロック, ブートローダ, カーネルを 次のようにして再コンパイルして下さい. カーネルソースを取得する. /etc/make.conf を編集し, BOOT_COMCONSOLE_PORT に 使用したいポートのアドレス(0x3F8, 0x2F8, 0x3E8 or 0x2E8)を 設定してください. 使用可能なのは sio0 から sio3 (COM1: から COM4:) までで, マルチポートシリアルカードは使えません. また, ここで割り込みの設定をする必要はありません. 設定を変更するために新たなカーネルコンフィグレーションファイルを作成し, 使いたいシリアルポートのフラグを適切に設定します. 例えば, sio1 (COM2:) をコンソールにしたければ, device sio1 at isa? port "IO_COM2" tty flags 0x10 irq 3 または, device sio1 at isa? port "IO_COM2" tty flags 0x30 irq 3 とします. その際, 他のシリアルポートにコンソールフラグをつけてはいけません. ブートブロックを再コンパイルし, インストールする. &prompt.root; cd /sys/boot/i386/boot2 &prompt.root; make &prompt.root; make install ブートローダを再コンパイルし, インストールする. &prompt.root; cd /sys/boot/i386/loader &prompt.root; make &prompt.root; make install カーネルを再構築し, インストールする. &man.disklabel.8; を使ってブートブロックをブートディスクに書き込み, 新しいカーネルから起動する. シリアルポートから DDB デバッガを起動するには シリアルコンソールからカーネルデバッガを起動したい(これは リモートで診断する際に便利ですが, もしおかしな BREAK 信号がシリアルポートに送られるような場合には危険です!) 場合には, 次のオプションを使ってカーネルをコンパイルして下さい. options BREAK_TO_DEBUGGER options DDB シリアルコンソールにログインプロンプトを表示させるには シリアルコンソールからブートメッセージを確認したり, シリアルコンソールを経由してカーネルデバッグセッションに入ることが できるので, これは必要がないかもしれませんが, login プロンプトをシリアルポートに 出力するように設定することもできます. これには, 次のようにします. エディタで /etc/ttys というファイルを開き, 次に示す行に移動して下さい. ttyd0 "/usr/libexec/getty std.9600" unknown off secure ttyd1 "/usr/libexec/getty std.9600" unknown off secure ttyd2 "/usr/libexec/getty std.9600" unknown off secure ttyd3 "/usr/libexec/getty std.9600" unknown off secure ttyd0 から ttyd3 は, COM1 から COM4 に対応しています. 設定したいポートの off を on に変更して下さい. また, もしシリアルポートの通信速度を変更しているなら, std.9600 が実際の通信速度になるように, 例えば std.19200 のように変更して下さい. さらに, 実際のシリアル端末に合わせて, 端末タイプを unknown から変更することも可能です. ファイルの編集が終了したら, 変更を有効化するために kill -HUP 1 を実行しなければなりません. ブートローダからコンソールを変更するには 前セクションは, ブートブロックの設定を変更することでシリアルコンソールを セットアップする方法について解説していました. このセクションでは, ブートローダへのコマンド入力と環境変数設定で コンソールの指定を行なう方法を紹介します. ブートローダがブートブロックの後, ブートプロセスの第三ステージとして呼び出されたとき, ブートローダの設定には, ブートブロックの設定がそのまま使われます. シリアルコンソールをセットアップする ブートローダとカーネルに対して シリアルコンソールを使用するように設定するには, 単に /boot/loader.rc のファイルに, 次のような一行を書くだけで実現できます. set console=comconsole これは, 前セクションで扱ったブートブロックの設定に 全く関係なく機能します. 上に示した行は, /boot/loader.rc の最初の行に書き込まなくてはいけません. これはできるだけ早く, ブートメッセージをシリアルコンソールに 出力させるために必要なことです. 同様にして, 次のように内蔵コンソールを指定することもできます. set console=vidconsole もし, ブートローダの環境変数 console が設定されていない場合, ブートローダ, そしてその次に起動するカーネルは ブートブロックで指定された オプションに 示されたコンソールを使用します. 3.2 以降のバージョンにおいては /boot/loader.rc ではなく, /boot/loader.conf.local や /boot/loader.conf にコンソール指定を書き込みます. その場合, /boot/loader.rc は次のようになっていなければなりません. include /boot/loader.4th start それから, /boot/loader.conf.local を作成して, 次の行をそこに追加して下さい. console=comconsole か, もしくは console=vidconsole です. 詳細については, &man.loader.conf.5; を参照して下さい. その際, ブートローダはオプション指定なし (ブートブロックに オプションが指定されたのと等価)になり, キーボードの存在を調べて 内蔵コンソールとシリアルコンソールを自動的に選択する機能は働きません. <devicename>sio0</devicename> 以外のシリアルポートを コンソールとして使うには sio0 以外のシリアルポートを コンソールとして使うには, ブートローダを再コンパイルする必要があります. それには, に書かれている説明にしたがって下さい. 注意 シリアルコンソールというアイデアは, グラフィック出力用のハードウェアやキーボードが接続されていない 専用サーバのセットアップを可能にするためのものです. (ほとんど?)全てのシステムはキーボードなしで起動できますが, 不幸にも,グラフィックアダプタなしでは起動できないシステムはたくさんあります. AMI BIOS を採用しているマシンでは, CMOS 設定の `graphics adapter' を `Not Installed' にするだけで, グラフィックアダプタがなくとも起動できるように設定することができます. しかしながら, 多くのマシンはこのようなオプションを持っていませんし, ディスプレイハードウェアがシステムに存在しないと起動しないように なっています. そのようなマシンでは, モニタを接続する必要がなかったとしても, 適当なグラフィックカード(モノクロのジャンク品でも構いません)を 挿入したままにしておく必要があるでしょう. また, AMI BIOS をインストールする, という手もあります.