OpenBSD Journal

Notes on how I set up my OpenBSD 3.5 server.

Contributed by sean on from the another-perspective-is-better-than-none dept.

Richard Kelsall writes:
For any beginners to setting up an OpenBSD server (and for myself
next time I have to do this) I have written a few notes here

http://www.millstream.com/server.html

that detail how I configured my little OpenBSD 3.5 ADSL
connected server.

I (sean) would just like to suggest people to use rc.conf.local instead of making changes to rc.conf. As well it would probably be a good practice to backup the original configuration files before you change them (ie. cp /etc/foo /etc/foo.original). Save yourself a headache.

(Comments are closed)

Comments

  1. By Anonymous Coward (65.167.23.134) on

    I (sean) would just like to suggest people to use rc.conf.local instead of making changes to rc.conf. As well it would probably be a good practice to backup the original configuration files before you change them (ie. cp /etc/foo /etc/foo.original). Save yourself a headache.

    Or use RCS. It's much easier than keeping track of all the rc.conf.whatever files. And most of the changes are YES/NO or something similar, usually easy to keep track of.

    Comments

    1. By Anonymous Coward (140.99.30.236) on

      hmm. setup rcs, or plop two files in siteXX.tgz ...

      Comments

      1. By Anonymous Coward (65.167.23.134) on

        This article is about installing a single server, not one hundred. You still have to edit the files before you can make a siteXX.tgz anyway, so you'r argument is invalid. Furthermore, RCS does not need to be set up. You mkdir RCS and it's done.

    2. By Anonymous Coward (66.80.107.196) on

      Or if you have the source, you can always view the original config files. Check out /usr/src/etc and you'll see the originals.

  2. By Anonymous Coward (142.179.156.134) on

    argh. rc.conf.local is a stupid idea.Why would I want two files, one saying "PF=no" and one saying "PF=yes"?

    Put EVERYTHING in rc.conf. Then there's no ambiguity whatsoever.

    Seriously. Do you see an /etc/daily.local, /etc/inetd.local /etc/pf.conf.local?

    bleah.

    Comments

    1. By krh (141.211.62.118) on

      I like having a record of the defaults. This is important when I screw things up. With something like pf.conf, this is not so important, because the default will probably not do me much good. With rc.conf, this can be very important.

      Additionally, rc.conf changes between releases. It's easier to keep your changes in rc.conf.local, because then you can overwrite rc.conf, knowing that your site-specific configuration will be preserved.

      Comments

      1. By FSCKER (213.51.48.55) on

        You want a record of the defaults? 'cp rc.conf rc.conf.bak' my 2 cents.

    2. By thom (62.167.73.79) on

      Of course there is a daily.conf.local. See what daily.conf says right at the top:

      if [ -f /etc/daily.local ]; then        echo ""        echo "Running daily.local:"        . /etc/daily.localfi

      It is much better to fiddle with *.local files than the original. Just think about updating.

    3. By Juanjo (84.120.176.33) on http://blackshell.usebox.net/

      FreeBSD has /etc/default/rc.conf for defaults and /etc/rc.conf for local changes, and OpenBSD has /etc/rc.conf for defaults and /etc/rc.conf.local for local changes.

      I don't know what about NetBSD... but just think when you update your system... your local conf is safe, thus you can install safely the new rc.conf of the new system release.

    4. By Paddy Newman (195.8.70.200) on

      I think you should read rc.conf. The correct place for local changes is rc.conf.local. The manpages in -current have been changed so that this is clear.

      If you were to update your /etc directory as part of an upgrade you would overide any changes made to your /etc/rc.conf.

      The other advarntage is that by leaving your /etc/rc.conf untouched you have a reference of all the available options and their default values.

      -paddy

      Comments

      1. By Richard Kelsall (81.2.66.14) r.kelsall@millstream.com on

        Hi guys,
        Thanks for the feedback. I've added a bit to the systrace
        section about backing up these files and how you should use
        the rc.conf.local file for upgrade reasons.
        Richard.

      2. By jtorin (217.215.193.248) spmkll1 <on> myrealbox <spot> com on

        You ofcourse use mergemaster for merging in changes to your local files. Because there isn't a '.local' for every configuration file in /etc...

        I use rc.conf.local nonetheless.

  3. By mark (13.16.137.10) on

    Shame there is no info on the ADSL setup :-(

    Comments

    1. By Richard Kelsall (81.2.66.14) r.kelsall@millstream.com on

      Hi Mark,
      I've documented all the bits I did. I guess the ADSL stuff
      you're interested in must be inside the ready configured router
      I bought from my ISP. Maybe I'll get an internal ADSL card
      sometime and do this bit too. But you may have to wait some time
      for my write-up :-)
      Richard.

    2. By Anonymous Coward (196.30.79.198) on

      This may suit your needs... https://skanky.homeunix.net/openbsd_stuff/adsl_pppoe.php

      Comments

      1. By Mark (13.16.137.10) on

        Cheers for this link - Mark

  4. By Anonymous Coward (216.162.215.208) on

    Why is there a separate reverse-mapping file for each internal host? It seems like it would be easier to put all the PTR records into one file. Am I missing something?

    Comments

    1. By Richard Kelsall (81.2.66.14) r.kelsall@millstream.com on

      I tried to put them all in one file but got in a muddle and
      gave up. I don't even understand why there are PTR resource
      records as distinct from ordinary domain names. Why isn't reverse
      DNS the same as forward DNS but a different domain name?
      (I did read the RFCs.) Maybe someone clever can explain.
      Richard.

      Comments

      1. By Anonymous Coward (216.162.215.208) on

        You're right, on the surface it seems like PTR could be just like A records. I don't know the technical reasons they're different. I think the following should work for you. Note that violet does need its own zone and file since it's in a different class C address. Maybe you could basically make the zone be a class B address space and bring them under one roof. File named.conf- zone "66.2.81.in-addr.arpa" { type master; file "db.81.2.66"; }; File db.81.2.66 -- @ IN SOA millstream.com. r\.kelsall.millstream.com. (45 1D 6H 40D 1D) IN NS millstream.com. IN NS secondary-dns.co.uk. 8.66.2.81.in-addr-arpa. IN PTR black.millerstream.com. 9.66.2.81.in-addr-arpa. IN PTR white.millerstream.com. ...

        Comments

        1. By Anonymous Coward (216.162.215.208) on

          Let's try that again, with some more readable formatting--

          You're right, on the surface it seems like PTR could be just like A records. I don't know the technical reasons they're different.

          I think the following should work for you. Note that violet does need its own zone and file since it's in a different class C address. Maybe you could basically make the zone be a class B address space and bring them under one roof.

          File named.conf-

          zone "66.2.81.in-addr.arpa" {   
  type master;   
  file "db.81.2.66"; 
};

          File db.81.2.66 -- 

          @ IN SOA millstream.com. r\.kelsall.millstream.com. (45 1D 6H 40D 1D) 
IN NS millstream.com. 
IN NS secondary-dns.co.uk. 
8.66.2.81.in-addr-arpa. IN PTR black.millerstream.com. 
9.66.2.81.in-addr-arpa. IN PTR white.millerstream.com.
...

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]