OpenBSD Journal

OpenBSD 4.1 Approaches!

Contributed by deanna on from the deja-vu dept.

The first sign of an impending release, ports tree soft lock, is upon us. If you've found any bugs in OpenBSD-current, ports or system, please report them ASAP! Remember that documentation errors are also bugs, and some excellent instructions for filing PR's are located here.

For a peek at what will be in 4.1, take a look at plus.html.

(Comments are closed)

Comments

  1. By tmib (tmib) t m i b AT x s 4 a l l DOT n l on

    ...who cares about the changes! I only want to know what design the new T-shirt will have! Not to mention the release artwork and the song! :-D

    Comments

    1. By Otto Moerbeek (otto) otto@drijf.net on http://www.drijf.net

      > ...who cares about the changes! I only want to know what design the new T-shirt will have! Not to mention the release artwork and the song! :-D

      OK, next release we just re-release an old release with new artwork and a new song. Seems to work well in other cases (books, music, films). ;-)

      Now I only have to find a way to fill all my spare time I will have with this change. What's more, deal with he detox effects in some way. Working on OpenBSD is very addictive...

      Comments

      1. By Jeff S. (213.84.231.103) on

        > > ...who cares about the changes! I only want to know what design the new T-shirt will have! Not to mention the release artwork and the song! :-D
        >
        > OK, next release we just re-release an old release with new artwork and a new song. Seems to work well in other cases (books, music, films). ;-)
        >
        > Now I only have to find a way to fill all my spare time I will have with this change. What's more, deal with he detox effects in some way. Working on OpenBSD is very addictive...
        >
        So is using it, I can assure you : ).

        Comments

        1. By Anonymous Coward (75.72.176.15) on

          XFCE needs to be updated to 4.4, 4.4 is a signifigant milestone that adds a lot of new features, including the Thunar file manager (which is the best file manager for *nix I've ever seen).

          Please somebody sneak in and update xfce4 to 4.4!

          Comments

          1. By Anonymous Coward (24.37.236.100) on

            > XFCE needs to be updated to 4.4, 4.4 is a signifigant milestone that adds a lot of new features, including the Thunar file manager (which is the best file manager for *nix I've ever seen).
            >
            > Please somebody sneak in and update xfce4 to 4.4!

            XFCE 4.4, would be awesome to have!

          2. By Anonymous Coward (64.233.199.212) on

            > XFCE needs to be updated to 4.4, 4.4 is a signifigant milestone that adds a lot of new features, including the Thunar file manager (which is the best file manager for *nix I've ever seen).
            >
            > Please somebody sneak in and update xfce4 to 4.4!

            Include the latest release of ratpoison 1.4.1 :) http://ratpoison.nongnu.org/


          3. By Sqwakin' Richard Dawkins (128.171.90.200) on

            > XFCE needs to be updated to 4.4, 4.4 is a signifigant milestone that adds a lot of new features, including the Thunar file manager (which is the best file manager for *nix I've ever seen).
            >
            > Please somebody sneak in and update xfce4 to 4.4!

            no way, you shall you fvwm, the way God meant it to be !

      2. By Bret Lambert (tbert) on

        > OK, next release we just re-release an old release with new artwork and a new song. Seems to work well in other cases (books, music, films). ;-)
        >

        OpenBSD: Special Collector's Limited Widescreen Remastered Edition Gold

        Available only for a limited time!

  2. By Iain (142.179.199.194) on

    Beyond 4.1, is there any desire or intentions for making OpenBSD i386 or AMD64 be a Supervisor OS to Hardware Virtualization?

    This could initially be done by setting up Virtualization tests to protect the OS from Hardware Virtualization Rootkits.

    Comments

  3. By Anonymous Coward (64.129.81.169) on



    Something very interesting is

    "In pfctl(8), implement "-T expire", so you can expire all entries in a given table that are older than a certain number of seconds."

    Jumping to the lastest smtp-vilter on stable obsd4.0 I
    found out that while the stable port of smtp-vilter had
    code to remove entries from pf tables, that has been removed
    in current now that pfctl will support expiration of entries.

    So expect config file changes! :)

    Comments

    1. By pf noobie (86.91.41.86) on

      Where would that come in handy then ?

      >
      >
      > Something very interesting is
      >
      > "In pfctl(8), implement "-T expire", so you can expire all entries in a given table that are older than a certain number of seconds."
      >
      > Jumping to the lastest smtp-vilter on stable obsd4.0 I
      > found out that while the stable port of smtp-vilter had
      > code to remove entries from pf tables, that has been removed
      > in current now that pfctl will support expiration of entries.
      >
      > So expect config file changes! :)
      >
      >

      Comments

      1. By Mathias (m_mathias) on

        > Where would that come in handy then ?

        Consider blacklisting ssh brute force attempts and so on.

        Comments

        1. By Anonymous Coward (87.118.110.163) on

          > > Where would that come in handy then ?
          >
          > Consider blacklisting ssh brute force attempts and so on.

          But for ssh-bruteforce or any other BF you wont have any "expire"-Flag...
          Normaly those boxes got owned or infected to using pf+overload is already all you`ll need.

          Comments

          1. By Mathias (m_mathias) on

            > But for ssh-bruteforce or any other BF you wont have any "expire"-Flag...
            > Normaly those boxes got owned or infected to using pf+overload is already all you`ll need.

            A lot of these systems are on some ADSL/whatever connection, and get a new IP every time they connect.

      2. By Matt Van Mater (69.255.1.181) on

        > Where would that come in handy then ?

        Also, you could use this kind of control to dynamically place hosts that are 'top talkers' with high packet rates into a lower priority queue. That way if someone is running a P2P app on any non standard port you can put their traffic at a lower priority, but on a non-permanent basis.

  4. By Anonymous Coward (128.237.249.126) on

    Since Sun isn't supposed to open source Java until next month, and the Ports tree is being frozen now, does that mean we'll have to wait for OpenBSD 4.2 before a pre-compiled binary JDK is included in Packages?

    Comments

    1. By phessler (69.12.168.115) on

      > Since Sun isn't supposed to open source Java until next month, and the Ports tree is being frozen now, does that mean we'll have to wait for OpenBSD 4.2 before a pre-compiled binary JDK is included in Packages?

      Yes. Changing JDK immediately before shipping is asking for trouble. Yes, it stinks you'll have to compile it on your own. But would you rather a broken JDK?

      Comments

      1. By Anonymous Coward (87.118.110.163) on

        > > Since Sun isn't supposed to open source Java until next month, and the Ports tree is being frozen now, does that mean we'll have to wait for OpenBSD 4.2 before a pre-compiled binary JDK is included in Packages?
        >
        > Yes. Changing JDK immediately before shipping is asking for trouble. Yes, it stinks you'll have to compile it on your own. But would you rather a broken JDK?

        What`s about the new ClamAV wich should get released very soon (~1-2 days).

      2. By Henrik Kramshøj (89.150.138.122) hlk@kramse.dk on www.kramse.dk

        Building JDK on OpenBSD nowadays is really simple.

        Yes, you have to download the source files from Sun.com but compiling is a breeze and when you have the JDK installed upgrading does not take long.
        First compile will use Kaffe for generating the files for building Sun JDK - but next compile uses the Sun JDK for building.

        It takes about 2 hours in total on AMD64 2GHz 512MB mem, YMMV.

        I have used JAVA on OpenBSD "in production" for Tomcat+Apache Lenya for some years.

        Comments

        1. By Anonymous Coward (128.237.249.44) on

          > Building JDK on OpenBSD nowadays is really simple.
          >

          No, it is not. Problems with JDK compilation are the source of many questions at misc@openbsd.org

          http://marc.theaimsgroup.com/?t=116831039500003
          http://marc.theaimsgroup.com/?t=116440425200002
          http://marc.theaimsgroup.com/?t=116365681400001
          http://marc.theaimsgroup.com/?t=92118258700001
          http://marc.theaimsgroup.com/?l=openbsd-misc&m=116272760512757
          http://marc.theaimsgroup.com/?t=116162180600008
          http://marc.theaimsgroup.com/?t=115734964700001

          and the list goes on and on, since those are just the questions in the last 6 months...

          Finally having a prebuilt binary JDK will be a godsend.

          Comments

          1. By Nate (Nate) on

            > Finally having a prebuilt binary JDK will be a godsend.

            I'd say not supporting Java at all would be better, there would be less stupid questions on the mailing lists.

  5. By Anonymous CD buyer (67.190.138.215) on

    One thing I just noticed, #fping -f somefile will use just the first 3 characters in each line, and thusly most will show up as unresolved.

    I know this isn't a bug report, sorry, but I'll get our office to buy another several CDs of 4.1, as well as buy one myself.

    Comments

    1. By Altadel (129.128.2.93) on

      > One thing I just noticed, #fping -f somefile will use just the first 3 characters in each line, and thusly most will show up as unresolved.

      I cannot reproduce this on Open-4.0 Release and fping-2.2b1 from packages on i386. It works properly here on a ThinkPad X31.

      Comments

      1. By Anonymous Coward (71.33.200.41) on

        > > One thing I just noticed, #fping -f somefile will use just the first 3 characters in each line, and thusly most will show up as unresolved.
        >
        > I cannot reproduce this on Open-4.0 Release and fping-2.2b1 from packages on i386. It works properly here on a ThinkPad X31.
        >

        I tried it on two different snapshots, one from November, one from February both i386 on Dell platforms:
        $cat hosts2check
        foghat
        ns1
        ns2
        ns33333
        leafy
        warthog
        www.apppppppppple.com

        #/usr/local/sbin/fping -f hosts2check
        fog address not found
        lea address not found
        war address not found
        ns1 is alive
        ns2 is alive
        ns3 is alive
        www is alive

        #/usr/local/sbin/fping foghat
        foghat is alive

        #/usr/local/sbin/fping ns3333
        ns3333 address not found

        #/usr/local/sbin/fping warthog
        warthog is alive

        #pkg_info | grep fping
        fping-2.4b2 quickly ping N hosts w/o flooding the network

        #sysctl kern.version
        kern.version=OpenBSD 4.0-current (GENERIC) #1209: Sun Nov 12 22:37:02 MST 2006
        deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC


        On a different machine:

        #cat hosts2check
        foghat
        ns1
        ns2
        ns33333
        leafy
        warthog
        www.apppppppppple.com

        #/usr/local/sbin/fping -f hosts2check
        fog address not found
        lea address not found
        war address not found
        ns1 is alive
        ns2 is alive
        ns3 is alive
        www is alive

        #/usr/local/sbin/fping foghat
        foghat is alive

        #/usr/local/sbin/fping leafy
        leafy is alive

        #/usr/local/sbin/fping warthog
        warthog is alive

        #/usr/local/sbin/fping ns3333
        ns3333 address not found

        #pkg_info | grep fping
        fping-2.4b2p0 quickly ping N hosts w/o flooding the network

        #sysctl kern.version
        kern.version=OpenBSD 4.0-current (GENERIC) #1360: Tue Feb 6 17:40:22 MST 2007
        pvalchev@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC

        Ports shows it being added on 2006-10-12 02:22:37, so I don't know if it worked back that far.

        Comments
        1. Comments

          1. By sthen (85.158.44.149) on

            > I just noticed that this breaks smokeping so I definitely want it fixed (-:

            ah no, reinstalling fping and not making it setuid breaks smokeping... well, it still needs fixing :)

      2. By Richard Toohey (121.72.6.74) richardtoohey@hotmail.com on

        Same here - 4.0 Release CD, fping-2.2.b1 from packages on i386 (Dell Precision 410).

        # fping -f hosts2check
        www.thecaryard.co.nz is alive
        www.openbsd.org is alive
        www.microsoft.com is unreachable
        # ping www.microsoft.com
        PING www.microsoft.com (207.46.19.30): 56 data bytes
        --- www.microsoft.com ping statistics ---
        133 packets transmitted, 0 packets received, 100.0% packet loss

        hosts2check:

        www.microsoft.com
        www.thecaryard.co.nz
        www.openbsd.org

        Comments

        1. By Richard Toohey (121.72.6.74) richardtoohey@hotmail.com on

          Same here = it works for me as is - no bugs.

          Comments

          1. By Kris (24.9.25.161) on

            > Same here = it works for me as is - no bugs.

            I think the post above shows it doesn't work for -current as of February, I'm glad it works for your 4.0-release. I see some strangeness in the fping -d 192.168.1.100 action, in that it chops off the answer.

            Comments

            1. By Richard Toohey (121.72.14.185) richardtoohey@hotmail.com on

              > I think the post above shows it doesn't work for -current as of February, I'm glad it works for your 4.0-release. I see some strangeness in the fping -d 192.168.1.100 action, in that it chops off the answer.

              Yes, thanks - right after I posted those comments I re-read the thread and realised that I wasn't adding much that had not already been said - ie something has changed between 4.0 release and current.

              Sorry for the noise.

  6. By Nate (Nate) Evil on

    Maybe this release there could be an Ozzy Osborn theme, the OS-man cometh as it were. It'd be great to see Puffy pimped out like Oz, biting the head off a penguin.

    Comments

    1. By Anonymous Coward (207.106.86.6) on

      > Maybe this release there could be an Ozzy Osborn theme, the OS-man cometh as it were. It'd be great to see Puffy pimped out like Oz, biting the head off a penguin.

      Awesome.

      Comments

      1. By Honz (142.179.216.141) on

        > > Maybe this release there could be an Ozzy Osborn theme, the OS-man cometh as it were. It'd be great to see Puffy pimped out like Oz, biting the head off a penguin.
        >
        > Awesome.

        That's truly the 'Gold' Edition... heh, love it

  7. By Anonymous Coward (75.118.14.188) on

    acpi still doesn't work on my notebook, could it have anything to do with trying to run OpenBSD/i386 on amd64 hardware, to boot I must -c and disable pcibios0 because it says unrecognized/unconfigured PCI ICU interrupt controller and it hangs. even with enable acpi, but acpi doesn't work, I don't have hw.setperf or anything

    Comments

    1. By Marco Peereboom (67.64.89.177) on

      > acpi still doesn't work on my notebook, could it have anything to do with trying to run OpenBSD/i386 on amd64 hardware, to boot I must -c and disable pcibios0 because it says unrecognized/unconfigured PCI ICU interrupt controller and it hangs. even with enable acpi, but acpi doesn't work, I don't have hw.setperf or anything

      Care to send a proper acpi bug report?

  8. By mk (130.225.243.67) on

    To all you people who are asking for updated versions of certain software: This would have had a better chance of happening if you did some of the work, i.e. had sent diffs during the past months. A lot of those updates will definitely not make it, alas.

    Now, as Peter says in his mail, help make the next release a good one, because this is something we all will benefit from. Test the packages and provide good bug reports for when something fails. For good bug reports, search the archives. This will make the porters' jobs a whole lot easier, and a lot more bugs will get shaken out.

    While the porters are really, really good at what they do, they're not many and can not do the same extensive testing that our combined user base can do. At least make sure the applications you use are working -now-, because then they're more likely to work -after- the release.

    Thanks in advance,
    Michael.

    Comments

    1. By Anonymous Coward (208.53.131.75) on

      > To all you people who are asking for updated versions of certain software: This would have had a better chance of happening if you did some of the work, i.e. had sent diffs during the past months. A lot of those updates will definitely not make it, alas.
      >
      > Now, as Peter says in his mail, help make the next release a good one, because this is something we all will benefit from. Test the packages and provide good bug reports for when something fails. For good bug reports, search the archives. This will make the porters' jobs a whole lot easier, and a lot more bugs will get shaken out.
      >
      > While the porters are really, really good at what they do, they're not many and can not do the same extensive testing that our combined user base can do. At least make sure the applications you use are working -now-, because then they're more likely to work -after- the release.
      >
      > Thanks in advance,
      > Michael.

      How should I´ve send diffs for the new clamav if it`s not released....
      But for the rest: You`re right.

      Comments

      1. By mk (130.225.243.67) on

        > How should I´ve send diffs for the new clamav if it`s not released....
        > But for the rest: You`re right.

        If things are released too late in the process, they obviously can't go in the release. If they are crucial, updates will be committed to the -stable branch after release after which a packet will also be available.

  9. By Anonymous Coward (213.118.134.55) on

    Maybe I'm jumping the gun here, but are there any big plans/long term goals for the next couple of releases?

    Comments

    1. By Nate (Nate) on

      > Maybe I'm jumping the gun here, but are there any big plans/long term goals for the next couple of releases?

      Replacing X, looks like Old World ROM support on macppcs, probably updating the linux_compat to more than just fedora core 4, complete replacement of GNU CVS with OpenCVS, maybe getting rthreads in as an alternative threading system... Those are the ones I've seen being discussed/worked on/loudly pondered.

      Comments

      1. By Anonymous Coward (24.37.236.100) on

        > > Maybe I'm jumping the gun here, but are there any big plans/long term goals for the next couple of releases?
        >
        > Replacing X, looks like Old World ROM support on macppcs, probably updating the linux_compat to more than just fedora core 4, complete replacement of GNU CVS with OpenCVS, maybe getting rthreads in as an alternative threading system... Those are the ones I've seen being discussed/worked on/loudly pondered.

        Replacing X with what?

        Comments

        1. By Anonymous Coward (129.127.96.27) on

          > Replacing X with what?

          X11R6 => Xorg7.2

          Comments

          1. By Brad (brad) on

            > > Replacing X with what?
            >
            > X11R6 => Xorg7.2

            You mean X.Org 6.9 -> X.Org 7.2. X.Org is being upgraded, not replaced.

            Comments

            1. By Nate (Nate) on

              > > > Replacing X with what?
              > >
              > > X11R6 => Xorg7.2
              >
              > You mean X.Org 6.9 -> X.Org 7.2. X.Org is being upgraded, not replaced.

              Well, it's replacing the old-school X with the modular one, for some opinions vary on if that is an upgrade or simply a change.

              Comments

              1. By Anonymous Coward (69.207.171.114) on

                > Well, it's replacing the old-school X with the modular one, for some opinions vary on if that is an upgrade or simply a change.

                Uhhh.. I would say upgrade. Just because they've replaced imake with GNU-style configure scripts doesn't mean it's not still X.org. In fact, my guess is that from a user's perspective it's pretty much identical.

                Now, AFAIK the newer Xorg might have some other cool features. But I'm not sure the drivers are quite there yet to take advantage of them.

                I don't know, it's been said before that OpenBSD's upgrades are evolutionary rather than evolutionary, and an Xorg update really seems more like the former than the latter.

                Comments

                1. By Nate (Nate) on

                  > I don't know, it's been said before that OpenBSD's upgrades are evolutionary rather than evolutionary, and an Xorg update really seems more like the former than the latter.

                  I think you meant, "evolutionary rather than revolutionary," and not evolutionary twice, yes, generally OpenBSD does evolve while Linux revolts. The X.org choice to become progressively more GNUish and prone to Linuxisms makes me uneasy about it.

                  That isn't to say OpenBSD hasn't revolted from time to time, pf being a prime example.

                  Comments

                  1. By Anonymous Coward (128.171.90.200) on

                    > Yes, generally OpenBSD does evolve while Linux revolts.

                    I've always found Linux fairly revolting

                  2. By Anonymous Coward (69.207.171.114) on

                    > I think you meant, "evolutionary rather than revolutionary," and not evolutionary twice,

                    Yeah. I wonder if my R key is broken :-)

                    > The X.org choice to become progressively more GNUish and prone to Linuxisms makes me uneasy about it.

                    I'm not sure it's too bad, as long as it keeps the GNUisms strictly to the configure scripts. It'll still be the same Xorg, right?

                    Comments

                    1. By Nate (Nate) on

                      > > I think you meant, "evolutionary rather than revolutionary," and not evolutionary twice,
                      >
                      > Yeah. I wonder if my R key is broken :-)
                      >
                      > > The X.org choice to become progressively more GNUish and prone to Linuxisms makes me uneasy about it.
                      >
                      > I'm not sure it's too bad, as long as it keeps the GNUisms strictly to the configure scripts. It'll still be the same Xorg, right?

                      But is it? To require such components in one part of X quickly makes it okey to have it in others. In my head it starts to look like freedom of speech, once it's not okey to say one thing because it may cause offense, it's no longer okey to say anything, because anything could cause offense.

                      Regardless, it's not mine to say where the line is drawn, Theo's already stated it's the inclusion of any GPL inside X.org itself.

  10. By Anonymous Coward (88.211.161.88) on

    After a clean install of OpenBSD 4.0 on my sparc I did:
    chflags -R schg /bin/* /sbin/*

    On the sparc architecture I get a strange response for several files in the bin directory:
    chflags: chmod: Operation not permitted
    chflags: md5: Operation not permitted
    chflags: mt: Operation not permitted
    chflags: pax: Operation not permitted
    chflags: rksh: Operation not permitted
    chflags: rmd160: Operation not permitted
    chflags: sh: Operation not permitted
    chflags: sha1: Operation not permitted
    chflags: sum: Operation not permitted
    chflags: tar: Operation not permitted
    chflags: test: Operation not permitted

    And files in the /sbin:
    chflags: chown: Operation not permitted
    chflags: mknod: Operation not permitted
    chflags: ncheck_ffs: Operation not permitted
    chflags: newfs: Operation not permitted
    chflags: rdump: Operation not permitted
    chflags: reboot: Operation not permitted
    chflags: rrestore: Operation not permitted
    chflags: swapon: Operation not permitted

    To check that no files flags were set on a clean install, I did a clean install again and checked the file flags of these files. And indeed no file flags are set. But after the chflags -R schg /bin/*, the flags are set, and for the above mentioned file the error message "Operation not permitted" is printed

    Strange ??

    Comments

    1. By Otto Moerbeek (otto) otto@drijf.net on http://www.drijf.net

      > Strange ??

      No. Do a ls -li on those dirs and check the link count and inode numbers. Also, remember chflags operates on inodes.

      BTW, IMO, a better place to post this kind of question is misc@.



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.]