|
 |
Din egen Intranett-server
|
|
Linuxskolen del 5 (LINUXmagasinet 4/2002)
Din egen Intranett-server
Av Kolbjørn Bekkelund,
kolbjorn@arctic-linux.tnett.no Arctic Linux, http://arctic-linux.tnett.no
Oppsettet benyttet i de etterfølgende eksempler er hentet fra Red Hat 7.3 Linux. Jeg forutsetter også at server ip-adresse er 192.168.1.1 og at kobler deg til Internett vha en fungerende oppringt tilkobling eller ved bruk av en ISDN ruter. Ellers må du sette opp en egen ruter/brannmur først. Dette vil bli tatt opp i neste nummer.
Har du stående en halvgammel pc som er litt for gammel til å brukes som arbeidsstasjon, men samtidig smerter det deg å tenke på søppla ? Vel, løsningen er meget enkel. Sett den opp som din egen Intranett-server !
Huff, tenker du sikkert. Du har“puslet” med Linux en stund, men dette var å ta hardt i ! Neida, det er ikke halvparten så vanskelig som du tror. I utgangspunktet er jo en server kun en vanlig datamaskin som er satt til å utføre et antall oppgaver hvor resultatet kan benyttes av mange andre maskiner i nettverket. Ikke trenger du noe supermaskin heller! Jeg benytter selv en eldre Pentium 100 som server i mitt arctic-linux.tnett.no. Den er matet med et brukbart nettverkskort, et eldre skjermkort, to harddisker og 132 MB RAM, men bortsett fra det - ingenting ekstra. Jeg nevnte at jeg benytter et eldre skjermkort. Et gammelt Cirrus 2 MB kort sørger for at jeg kan koble til en skjerm i ny og ned, men til daglig står serveren uten skjerm tilkoblet. All administrasjon foregår fra de andre pcene i huset via secure shell. Dette er en bevisst handling fra min side og begrunnes slik: Serveren skal være hjørnesteinen i nettverket, og det betyr igjen at den må kunne være oppegående til enhver tid. Skal man oppnå dette må den få stå mest mulig i fred slik at den i det stille kan utføre alle de utvalgte oppgavene du har pålagt den. En måte å begrense bruken av serveren på er rett og slett ved å ikke installere X Window i det hele tatt. Dermed slår du to fluer i en smekk; Du får en maskin det ikke er så morsomt å tukle med til daglig, samt at du faktisk sparer en masse RAM som maskinen heller kan utnytte til andre viktigere oppgaver.
NB !!!! IP adresseområde
En viktig sak å ta opp før du setter i gang med konfigurasjonen er at du ikke fritt kan velge hvilket ip-område du skal benytte for nettet ditt. Du har egentlig to valg:
1. Kjøpe deg et eget domene med tilhørende statisk ip.
2. Benytte de frie ip-områdene beregnet for lokalnett uten egne domener. Disse er 10.0.0.0/8, 172.16.0.0/12, og 192.168.0.0/16. Årsaken til at man kan benytte disse uten å lage krøll for andre på Internet er at alle rutere der ute er konfigurerte til IKKE å fremsende ip-pakker som har opphav i slike adresseområder.
Hvilke tjenester har du så behov for på din egen Intranett-server ? I utgangspunktet er det kun noen ytterst få som er helt nødvendige til å begynne med. Jeg tenker da på en webserver, ftp- og secure shell. I tillegg kan det være greit med en egen navnetjener (DNS). Denne vil gjøre deg litt mere uavhengig av din egen internett leverandør ved at du alltid vil kunne gjøre navneoppslag selv om leverandørens DNS er nede. Du vil også kunne sette opp Intranettet litt mere logisk siden du i DNSen kan gi tjenestene dine skikkelige navn som www.arctic-linux.tnett.no, news.arctic-linux.... osv. Dette er spesielt nyttig dersom alle tjenestene har opphav i den samme maskinen. Mitt oppsett er slik. Kun brannmuren er lagt til en annen pc i mitt nettverk da denne andre pcen også fungerer som ruter/gateway. Alternativet til en egen DNS er å benytte kun interne ip-adresser hele tiden. Greit, men ikke særlig opplysende. En mailserver er også en dyd av nødvendighet for håndtering av epost til og fra nettverket. I tillegg er det greit å kunne lese newsgrupper i fred og ro, så en news-server er ikke å forakte. Ei heller en NFS-server som lar deg eksportere og importere filsystemer til og fra maskinene i nettet ditt for derved å utnytte store disker bedre. Les videre og se hvordan disse tjenstene kan installeres uten for mye trøbbel.
Jeg nevnte at jeg benytter en egen ruter/gateway. Denne sørger for all inn/ut kommunikasjon mellom nettets interne maskiner og de eksterne på Internett. Denne har to nettverkskort - ett mot lokalnettet og ett mot Internett. Ved så å sette opp en brannmur på denne maskinen kan du styre hvilke lokale tjenester som skal være tilgjengelige på Internett, hvilke pcer i lokalnettet som inneholder disse tjenestene og hvilke av de lokale pcene som skal kunne benytte ruter/gateway for å koble seg til Internett. Denne maskinen vil også vha brannmuren maskere de andre maskinene i nettet ditt slik at du ut mot verden kun fremviser en ip-adressse. Dette kalles for IP Masquerading og er en funksjon som er inkludert i de fleste Linux-kjerner ved en normal installasjon. Smart ?
La meg si det slik: Har du flere maskiner i nettet ditt som du ønsker skal ha tilgang til Internett, ja da MÅ du benytte en eller annen for for ip-maskering. Enten ved å sette opp en egen maskin som håndterer jobben, eller benytte noen ferdigløsninger. Et slikt eksempel kan være en ISDN hub/ruter dersom du har ISDN-tilkobling mot Internett, eller en komplett ruter/gateway fra leverandør dersom du har god råd. Å sette opp en slik sak selv er imidlertid ikke så vanskelig som du kanskje tror. Vi skal se litt på dette i neste nummer av LinuxMagasinet.
Sendmail
Filer:
sendmail-8.11.6-15 (Selve mailserveren)
sendmail-cf-8.11.6-15 (Konfigurasjonsfiler, samt filer nødvendig ifm kompilering av ny .cf dersom nødvendig)
I de aller fleste tilfeller er det ikke nødvendig med noen kompilering av sendmail.cf for å kunne nytte sendmail i hjemmenettet. Sendmail er et utrolig kompleks program og jeg vil ikke på noen måte påta meg en bred intro her. Jeg benytter selv sendmail på min server selv om jeg er klar over at det finnes andre alternativer som postfix etc. Årsaken til at jeg bruker sendmail er rett og slett at jeg var vant med den før postfix dukket opp. Jeg har også fått justert mitt oppsett av sendmail slik at den gjør det jeg har behov for, og da ser jeg ingen grunn til å bytte bare for byttets skyld.
For å få en fornuftig sendmail opp å gå må du gjøre følgende formadringer i /etc/sendmail.cf:
# my official domain name
# ... define this only if sendmail cannot automatically determine your domain
#Dj$w.arctic-linux.tnett.no
# "Smart" relay host (may be null) Er brukbar dersom du ikke vil la din mailserver stange på mailer som ikke blir sendt grunnet andre mailhoster som er nede.
#Dsmail.your.isp
# who I masquerade as (null for no masquerading) (see also $=M)
DMarctic-linux.tnett.no
I tillegg til /etc/sendmail.cf er det 4 filer til du må redigere og tilpasse til ditt nettverk:
•/etc/mail/local-host-names
arctic-linux.tnett.no
•/etc/sendmail.cw (for hvilke maskiner ønsker vi å motta mail)
localhost
vega.arctic-linux.tnett.no
canopus.arctic-linux.tnett.no
capella.arctic-linux.tnett.no
antares.arctic-linux.tnett.no
•etc/mail/relay_allow (lar de andre maskinene dine bruke serverens sendmail)
canopus.arctic-linux.tnett.no capella.arctic-linux.tnett.no antares.arctic-linux.tnett.no
•/etc/mail/access
localhost.localdomain RELAY
localhost RELAY
127.0.0.1 RELAY
arctic-linux.tnett.no RELAY
Etter at du har laget filen over (som også kan inneholde mange andre settinger) må du opprette /etc/mail/access.db med komandoen:
'makemap hash /etc/mail/access.db ( /etc/mail/access'
For de som vil sikre sendmail enda bedre - sjekk http://www.sendmail.net/000705securitygeneral.shtml.
Etter at du er ferdig med oppsettet restarter du sendmail slik:
'/etc/rc.d/init.d/sendmail restart'
Web server
Filer:
apache-1.3.23-11.i386.rpm og apache-manual-1.3.23-11.i386.rpm
Ønsker du å benytte Red Hat's spesielle konfigurasjonsprogram for Apache installerer du i tillegg apacheconf-0.8.2-2.noarch.rpm. Dette er imidlertid ikke nødvendig !
Dette er nok den mest benyttede delen i et Intranett. Her kan du sette opp dine egne websider med nyttig informasjon som raskt kan aksesseres av flere brukere uten mere arbeide for deg. Det utrolig smarte med websidene er at du KUN oppdaterer ETT eksemplar av slike sider, men vha serveren enkelt fordeler den samme siden til en hel verden ! Det finnes mange slike webservere, men den mest benyttede av dem alle - Apache er garantert en del av Linux-distribusjonen din, og antageligvis er den allerede installert på maskinen. Du kan selvfølgelig velge å oppgradere den medfølgende Apache fra versjon 1.3.x til den nyere 2.x fra www.apache.org, og faktisk vil jeg råde deg til akkurat dette. 2.x inneholder mange nye sikkerhetsforanstaltninger ift de eldre versjonene, og i tillegg er konfigurasjonen enklere. Tidligere benyttet man 3 forskjellige filer for å styre oppførselen til Apache. Disse var httpd.conf, access.conf og srm.conf. I 2.x er alle disse slått sammen til 1 fil - httpd.conf. Det etterfølgende vil imidlertid ta for seg konfigurasjon av 1.3.x siden denne ennå er den mest brukte. For å starte webserveren i en standard Red Hat installasjon er det kun noen få justeringer i oppsettet som må til.
I /etc/httpd/conf/httpd.conf må du forandre følgende:
- ServerAdmin brukernavn@ditt.domene (den epost-adressen som fremvises på server-genererte sider)
- ServerName www.ditt.domene
Dette er faktisk alt. Put alle websidene dine inn i /home/httpd/html. Dersom du ønsker at en side skal komme opp automatisk når folk aksesserer feks. http://www.arctic-linux.tnett.no legger du inn en side som heter index.html i den nevnte katalogen.
Nå gjenstår det bare å starte web-serveren. Dette gjør du slik:
'/etc/rc.d/init.d/httpd start'
For automatisk start ved boot: 'chkconfig --level 235 httpd on'
Siden du ennå ikke har installert noen navnetjener kan du sjekke serveren i feks Netscape med å sette http:/192.168.1.1 i adressefeltet. Jeg satser på at dette gikk bra og at den siden du fikk opp var enten Red Hat's Apache infoside, eller den index.html du hadde lagt inn selv.
FTP server
Filer:
eller wu-ftpd-2.6.2-5.i386.rpm
Dette er en av de tingene du kommer til å ha utrolig nytte av i ditt lokale nettverk. Den blir fort ditt lille “vannhull” hvor du lagrer og henter filer du og familien har samlet sammen etter som tiden går. Når det gjelder ftp-servere må man skille mellom to hovedområder:
–normal tilgang for serverens egne brukere (du og de andre med egen brukerkonto)
–anonym tilgang (tilgang for brukere uten egen konto på serveren)
Det holder lenge, og sparer deg for mye konfigurasjon ved IKKE å installere støtte for anonymous ftp. I Red Hat må du faktisk legge inn en egen pakke for å oppnå denne funksjonaliteten - anonftp-4.0-9.i386.rpm.
Jeg ville benytte vsftpd grunnet bedre sikkerhet enn under wu-ftpd, og det er ikke nødvendig med noen endring av konfigurasjon for å kjøre den. Det eneste du må gjøre er å gjøre en endring i oppsettet til xinetd. Dvs den “superrserveren” som kjører denne og en del andre “daemons” på nyere Linux'er.
I /etc/xinetd.d/vsftp
# default: off
# description: The vsftpd FTP server serves FTP connections. It uses \
# normal, unencrypted usernames and passwords for authentication.
service ftp
{
disable = yes
socket_type = stream
wait = no
user = root
server = /usr/sbin/vsftpd
nice = 10
forandrer du disable = yes til disable = no
Deretter omstarter du xinetd med '/etc/rc.d/init.d/xinetd restart'
Test så med ncftp eller en annen ftp-klient mot 192.168.1.1. Med ncftp gjør du slik:
'ncftp -u brukernavn 192.168.1.1'
Etter at du har oppgitt passord skulle du automatisk ende opp i din eget hjemme-katalog på serveren. Vi er i mål med ftp.
Secure Shell server
Filer:
openssh-server-3.1p1-3.i386.rpm (selve serverdelen)
(dokumentasjon, nøkkelgenerator m.m)
openssh-askpass-3.1p1-3.i386.rpm (oppdatert passord kommunikator)
openssh-clients-3.1p1-3.i386.rpm (ssh klient for bruk fra server mot andre maskiner)
Secure shell er en dyd av nødvendighet. Den er en SIKKER erstatning for telnet som tidligere var den mest benyttede metoden for å logge seg inn i andre datamaskiner via terminaler eller terminal emulatorer som xterm etc. Hovedproblemet med telnet er at brukernavnet og passordet du oppgir under autentiseringen går ukryptert over nettet, mens ved bruk av secure shell foregår denne prosessen kryptert. Dermed er det ikke mulig å ligge med tcp-sniffere (programmer som fanger opp alle data-pakkene som går inn/ut av et nettverkskort og muliggjør utskrift av disse til skjerm) å snappe opp brukernavn og passord for bruk under innbrudd i systemet senere. I tillegg inneholder ssh-klientene mere funksjonalitet med tanke på kjøring av X-programmer over nettet.
Det er ikke nødvendig med noe konfigurasjon av selve ssh-serveren før bruk. Det eneste du behøver å foreta deg er å sørge for at den starter automatisk etter boot med:
'chkconfig --level 235 sshd on'
Test: 'ssh brukernavn@192.168.1.1'
Etter å ha oppgitt paasord skulle du bli automatisk flyttet over i din egen hjemme-katalog. Alt OK med ssh-server.
Navnetjeneren Bind (DNS)
Filer:
bind-9.2.0-8.i386.rpm (caching navnetjener med dokumentasjon)
bind-utils-9.2.0-8.i386.rpm (nødvendige verktøy for test/bruk/oppdatering av dns)
Hva skal du så med egen navnetjener (DNS server) ? Vel, svaret er enkelt: Gjøre nettverket ditt mere fleksibelt, øke funksjonaliteten og gjøre deg mere uavhengig av eksterne kilder. Som sagt i starten av artikkelen kan du da oppgi for eksempel http://www.servernavn.dittdomene i stedet for http://192.168.1.1 osv. I tillegg vil du fortsatt kunne gjøre navneoppslag selv om den DNS-serveren du før benyttet på Internet er nede. Dette øker fleksibiliteten i nettverket og minsker mengden av problemer du måtte komme ut for i den daglige driften.
Bind er en såkallt “caching name server” Med dette menes at det den egentlig gjør er å lagre de ip-adressene du og de andre brukerene på nettet støter på. Første gang du kaller på en ip bind ennå ikke har lagret gjør den et oppslag til en “forwarder”. Denne “forwarderen” må du selv velge blant de tilgjengelig dns'ene på Internett. Den må deretter settes opp i konfigurasjonen til bind. Mere om dette straks. Etter å ha hentet ip'en fra “forwarderen” lagrer bind denne i sitt arkiv til senere bruk. Denne måten å arbeide på minsker belastningen på din server, men gir deg allikevel dns-funkjsonalitet.
Oppsettet er slik:
I /var/named/
–/var/named/127.0.0 (default zone file)
Ingen forandring nødvendig.
########################################################
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
1 ; serial
28800 ; refresh
7200 ; retry
604800 ; expire
86400 ; default_ttl
)
@ IN NS ns.linux.bogus.
1 IN PTR localhost.
########################################################
–/var/named/root.hints (liste over alle root-servere på Internett)
Du kan starte med denne, men den bør oppdateres straks alt virker som det skal !!
###############################################################
; (()) DiG 8.3 (()) @e.root-servers.net . ns
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; -))HEADER((- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
;; QUERY SECTION:
;; ., type = NS, class = IN
;; ANSWER SECTION:
. 6D IN NS L.ROOT-SERVERS.NET.
. 6D IN NS M.ROOT-SERVERS.NET.
. 6D IN NS I.ROOT-SERVERS.NET.
. 6D IN NS E.ROOT-SERVERS.NET.
. 6D IN NS D.ROOT-SERVERS.NET.
. 6D IN NS A.ROOT-SERVERS.NET.
. 6D IN NS H.ROOT-SERVERS.NET.
. 6D IN NS C.ROOT-SERVERS.NET.
. 6D IN NS G.ROOT-SERVERS.NET.
. 6D IN NS F.ROOT-SERVERS.NET.
. 6D IN NS B.ROOT-SERVERS.NET.
. 6D IN NS J.ROOT-SERVERS.NET.
. 6D IN NS K.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12
M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33
I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17
E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10
D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90
A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4
H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53
C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12
G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4
F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241
B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107
J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10
K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129
;; Total query time: 325 msec
;; FROM: vega to SERVER: e.root-servers.net 192.203.230.10
;; WHEN: Fri May 31 22:28:19 2002
;; MSG SIZE sent: 17 rcvd: 436
###############################################################
–/var/named/ditt.domene (din egen zone file)
Under ser dere min zone-fil. Denne kan dere benytte som mal for deres eget oppsett.
###############################################################
;
; Zone file for arctic-linux.net
; /var/named/arctic-linux.tnett.no
;
; The full zone file
;
@ IN SOA ns.arctic-linux.tnett.no. hostmaster.arctic-linux.tnett.no. (
20010405143 ; serial, todays date + todays #
8H ; refresh, seconds
2H ; retry, seconds
1W ; expire, seconds
1D ) ; minimum, seconds
;
TXT "arctic-linux.tnett.no, your DNS consultants"
NS ns ; Inet Address of name server
MX 10 mail ; Primary Mail Exchanger
localhost A 127.0.0.1
ns A 192.168.1.1
MX 10 mail
MX 20 mail.arctic-linux.tnett.no.
HINFO "P 100" "Red Hat 7.3"
www CNAME ns
mail A 192.168.1.1
MX 10 mail
HINFO "P 100" "Red Hat 7.3"
ftp A 192.168.1.1
MX 10 mail
HINFO "P 100" "Red Hat 7.3"
news A 192.168.1.1
MX 10 mail
HINFO "P 100" "Red Hat 7.3"
antares A 192.168.1.3
MX 10 mail
HINFO "PIII 1.0 GHz" "Red Hat 7.3"
capella A 192.168.1.4
MX 10 mail
HINFO "PIII 600" "Red Hat 7.3”
canopus A 192.168.1.2
MX 10 mail
HINFO "P 230" "Red Hat 7.3"
vega A 192.168.1.1
MX 10 mail
HINFO "P 100" "Red Hat 7.3"
###############################################################
–/etc/named.conf (grunnleggende oppsett av bind)
Under finner dere min versjon av denne filen. Bruk den som mal og rediger de innføringene som peker til mitt domene og evt de ip'ene jeg benytter som forwarders.
##########################################
options {
directory "/var/named";
query-source port 53;
forwarders{
193.212.1.10;
193.212.1.11;
};
};
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.in-addr.arpa"{
type master;
file "127.0.0";
};
zone "arctic-linux.tnett.no" {
type master;
file "/var/named/arctic-linux.tnett.no";
};
###########################################
Etter å ha gjort de nødvendige forandringer skulle du nå være klar til å teste utfallet av en start av bind. Ta opp to terminaler og logg inn som root i begge. I den ene kjører du følgende kommando:
'tail -f /var/log/messages'
Dette lar deg se alle meldinger som går inn i loggen etterhvert som de kommer inn. Flott for debugging !!
I den andre terminalen kjører du:
'/usr/sbin/rndc start'
Dersom alt fungerer greit burde du se noe slikt i den andre terminalen:
Jul 26 13:15:37 vega named[1479]: USAGE 970917337 970917014 CPU=0.02u/0.03s CHILDCPU=0u/0s
Oct 7 13:15:37 vega named[1510]: starting. named 8.2.2-P5 Tue Jun 6 17:28:11 CEST 2000 ^:/usr/src/src/bin/named
Jul 26 13:15:37 vega named[1510]: hint zone "" (IN) loaded (serial 0) Jul 26 13:15:37 vega named[1510]: Zone "0.0.127.in-addr.arpa" (file 127.0.0): No default TTL set using SOA minimum instead
Jul 26 13:15:37 vega named[1510]: master zone "0.0.127.in-addr.arpa" (IN) loaded (serial 1)
Jul 26 13:15:37 vega named[1510]: Zone "arcitc-linux.tnett.no" (file arcitc-linux.tnett.no): No default TTL set using SOA minimum instead
Jul 26 13:15:37 vega named[1510]: master zone "arcitc-linux.tnett.no" (IN) loaded (serial 2441575514)
Jul 26 13:15:37 vega named[1510]: listening on [127.0.0.1].53 (lo)
Jul 26 13:15:37 vega named[1510]: listening on [192.168.1.1].53 (eth0)
Jul 26 13:15:37 vega named[1510]: Forwarding source address is [0.0.0.0].1081
Jul 26 13:15:37 vega named[1511]: Ready to answer queries.
Før vi gjør en skikkelig test med navneoppslag må vi fortelle serveren at den skal bruke bind som dns-server. Dette gjør vi ved å redigere filen /etc/resolv.conf. Min ser slik ut:
#########################
domain arctic-linux.tnett.no
search arctic-linux.tnett.no
nameserver 127.0.0.1
#########################
For alle de andre maskinene i nettet ser /etc/resolv.conf slik ut:
#########################
domain arctic-linux.tnett.no
search arctic-linux.tnett.no
nameserver 192.168.1.1
#########################
Så er vi klare for en test av navneoppslag:
Kjør 'dnslookup' (et av programmene i utiliti-pakken), og sett inn feks home.online.no. Utgangen på dette burde bli som vist under:
[kolbekk@vega kolbekk]$ nslookup Default Server: localhost Address: 127.0.0.1 )home.online.no
Server: localhost
Address: 127.0.0.1
Name: home.online.no
Address: 148.122.161.133
Dersom du ser et resultat som over er du i mål !
For automatisk oppstart etter boot:
'chkconfig --level 235 named on'
Som jeg sa tidligere burde du oppdatere /var/named/root.hints så snart du var sikker på at alt fungerte greit. Det du gjør ifm en slik oppdatering er at du forteller bind om evt nye eller bortfalne root-servere på Internett. Denne prosessen kan du automatisere vha et script som settes opp som en cron-jobb. Scriptet jeg benytter finner du nedenfor.
/usr/local/bin/root.hints-update
##############################################################
#!/bin/sh
#
# Update the nameserver cache information file once per month.
# This is run automatically by a cron entry.
#
# Original by Al Longyear
# Updated for BIND 8 by Nicolai Langfeldt
# Miscelanious error-conditions reported by David A. Ranch
# Ping test suggested by Martin Foster
# named up-test suggested by Erik Bryer.
# Adapted to arctic-linux.tnett.no by Kolbjorn Bekkelund
#
(
echo "To: hostmaster (kolbjorn)"
echo "From: system (root)"
# Is named up? Check the status of named.
case `ndc status 2)&1` in
*'cannot connect to command channel'*)
echo "named is DOWN. root.hints was NOT updated"
echo
exit 0
;;
esac
PATH=/sbin:/usr/sbin:/bin:/usr/bin:
export PATH
# NOTE: /var/named must be writable only by trusted users or this script
# will cause root compromise/denial of service opportunities.
cd /var/named 2)/dev/null || {
echo "Subject: Cannot cd to /var/named, error $?"
echo
echo "The subject says it all"
exit 1
}
# Are we online? Ping a server at your ISP
case `ping -qnc 1 some.machine.net 2)&1` in
*'100% packet loss'*)
echo "Subject: root.hints NOT updated. The network is DOWN."
echo
echo "The subject says it all"
exit 1
;;
esac
dig @e.root-servers.net . ns )root.hints.new 2) errors
case `cat root.hints.new` in
*NOERROR*)
# It worked
:;;
*)
echo "Subject: The root.hints file update has FAILED."
echo
echo "The root.hints update has failed"
echo "This is the dig output reported:"
echo
cat root.hints.new errors
exit 1
;;
esac
echo "Subject: The root.hints file has been updated"
echo
echo "The root.hints file has been updated to contain the following
information:"
echo
cat root.hints.new
chown root.root root.hints.new
chmod 444 root.hints.new
rm -f root.hints.old errors
mv root.hints root.hints.old
mv root.hints.new root.hints
ndc restart
echo
echo "The nameserver has been restarted to ensure that the update is complete."
echo "The previous root.hints file is now called
/var/named/root.hints.old."
) 2)&1 | /usr/lib/sendmail -t
exit 0
####################################################################
Forandre hostmaster navnet oppe i fila til det du ønsker og legg inn kjøring av scriptet i root's crontab. En gang pr. Måned skulle være ok.
NFS server
Filer:
nfs-utils-0.3.3-5.i386.rpm
I et fullverdig Linux-nett er en NFS-server et skikkelig nyttig hjelpemiddel når det gjelder å dele ut filer i nettet. Enten det er fra serveren og til de andre maskinene, eller motsatt. Har du liten plass på en harddisk på en maskin kan du enkelt gjøre dette plass-problemet til en sagablott ved å lage en ny katalog på en maskin med nfs gående, dele ut denne katalogen, og deretter mounte denne på den maskinen med dårlig plass. Oppsettet er enkelt, men betinger at kjernen på nfs-server maskinen støtter nfs. Dette gjør Red Hat's kjerner automatisk, men dersom du har kompilert din egen etter installasjonen av Red Hat kan du ha utelatt denne funkjsonaliteten. I såfall slipper du ikke utenom en rekompilering. Legg til nfs-støtte under “File systems ) Network file systems”
Det eneste du behøver å gjøre er å legge inn ønskede kataloger for utdeling i filen /etc/exports. Et eksempel er vist nedenfor:
###########################################################
/home/kolbjorn antares(rw) capella(rw)
/home/httpd/html antares(rw)
/home/ftp/pub canopus(ro) antares(rw)
###########################################################
I den første linjen eksporterer jeg en hjemme-katalog til 3 forskjellige maskiner med lese- og skriverettigheter. Denne setningen vil kun virke sammen med NIS. NIS lar deg sette opp en felles maskin for innlogging på nettet ditt. Dette gjør i sin tur at du slipper unna med å bestyre brukere på en maskin istedet for på alle. I korte trekk virker det slik:
På server:
1.Du setter opp serveren din som NIS-server.
2.Du exporterer alle hjemme-katalogene til de maskinene som skal benytte dem.
På klientene:
1. Du lager hjemmeområder under /home for alle brukerene som skal benytte maskinen.
2.Du mounter de områdene du eksporterte fra server ved boot av maskinen.
3.Du setter opp maskinen til å bruke NIS for innlogging og angir din server som NIS-server.
Når brukerene logger seg inn på klientmaskinene vil de hele tiden få opp hjemmeområdet sitt fra serveren. Dette vil være likt for alle klientmaskinene, og du har fått et utrolig fleksibelt nettverk hvor alle endringer i hjemmeområdene skjer på samme maskin (server) selv om det jobbes på forskjellige i løpet av dagen.
I andre linje eksporterer jeg serverens websider til den maskinen jeg benytter mest som arbeidshest, mens jeg i den tredje varianten eksporterer public-området på husets ftp-server til to maskiner. En med lese- og skrivetilgang, mens den andre bare kan lese.
Etter at du har editert /etc/exports kjører du kommandoen:
'exportfs -a' for å fortelle kernel om de områdene du ønsker eksportert. Detter starter du nfs-server med
/etc/rc.d/init.d/nfs start
For å teste serveren kan du for eksempel gjøre slik: Lag deg en katalog /mnt/webserver. Kjør så denne kommandoen:
'mount -t nfs 192.168.1.1:/home/httpd/html /mnt/webserver'
Uten feilmeldinger, og med websidene dine i /mnt/webserver skulle du være i mål. Bare husk å unmounte /mnt/webserver før du evt tar ned nfs-serveren. Glemmer du dette vil klientmaskinen henge lenge ifm shutdown.
For automatisk oppstart etter boot:
'chkconfig --level 235 nfs on'
News server
Filer:
leafnode-1.9.18-1.i386.rpm (En enkel, men flott news-server for hjemmenettet)
Hvorfor kjøre en egen news-server ? Jo, igjen for fleksibilitetens skyld. Du kan stå opp om morgenen og lese news i fred og ro til kaffen. Vel vitende om at den ble oppdatert mot ønsket server i løpet av natten da båndbredden var best. Videre er et godt argument at du lærer enda mere om server oppsett dersom du setter opp tjenester selv istedet for å hente dem fra andre. Leafnode er dessuten en smart sak. Den beholder og oppdaterer kun grupper som blir benyttet av brukerene. Blir en newsgruppe stående ulest i lengre tid slutter den å oppdatere akkurat denne inntil noen abonnerer på den igjen. Oppsettet er meget enkelt:
Etter installasjon av rpm'en (eller fra kildekode) redigerer du /etc/leafnode/config og bytter ut server med den news-serveren som er tilgjengelig fra din Internett leverandør. Deretter kjører du kommandoen:
'/usr/sbin/fetchnews -vv'
Leafnode vil nå oppdatere listen med tilgjengelige newsgrupper fra den valgte serveren. Dette tar litt tid første gangen, men senere vil dette være gjort i en fei. Etter at oppdateringen er over kan du sette opp en newsleser som knews, pan eller slrn med 192.168.1.1 (eller news.mitt-domene dersom Bind er satt opp) som news-server. Videre må oppdatering av leafnode automatiseres slik at fetchnews henter news på natten, samt at texpire fjerner gamle artikler til faste tider. Dette står godt beskrevet i leafnode's dokumentasjon. Sjekk http://www.leafnode.org for mere informasjon.
Vel, dette skulle være tilstrekkelig for denne gangen. I neste nummer av LINUXmagasinet ser vi på oppsett av en IP-tables basert brannmur som gir deg kontrollen over nettet ut mot Internett, samt at den fungerer som en grei ruter mellom internt og eksternt nettverk. Vi skal også se på oppsett av Squid proxy-server og squidGuard. SquidGuard er et filtreringsverktøy som arbeider sammen med Squid. Sammen gjør de websurfingen litt sikrere for de små Internett-brukerene. Følg med !
|
 |
|
