Re: Microsoft's war on plain text email in open source

[Constantine A. Murenin]

On 2020-W35-3 08:28 +, Frank Beuth wrote:

"Linux kernel development  which is driven by plain-text email
discussion  needs better or alternative collaborative tooling "to
bring in new contributors and maintain and sustain Linux in the
future," says Sarah Novotny, Microsoft's representative on the Linux
Foundation board.

Said tooling could be "a text-based, email-based patch system that
can then also be represented in a way that developers who have grown
up in the last five or ten years are more familiar with," she added.

...

Should it migrate toward something more like, say, issues and pull
requests on the Microsoft-owned GitHub? ???I???m not saying that
there will be a move in any time that I can see  my crystal ball???s
broken  but I do think there needs to be expansions in the way
people can enter that workflow,??? said Novotny.

???It is a fairly specific workflow that is a challenge for some
newer developers to engage with. As an example, my partner submitted
a patch to OpenBSD a few weeks ago, and he had to set up an entirely
new mail client which didn???t mangle his email message to HTML-ise
or do other things to it, so he could even make that one patch.
That???s a barrier to entry that???s pretty high for somebody who
may want to be a first-time contributor.???"

https://www.theregister.com/2020/08/25/linux_kernel_email/


OMG, LOL!

Why OpenBSD is to blame when Gmail -- after so many years -- still 
doesn't have proper support for sending text-based attachments 
the right way?


Or the ability to include patches in message body, 
without tabs being mangled into spaces?


Or maybe we now have to switch from tabs to spaces in style(9) 
and all our code, because buggy software written in the last 
Z years cannot support tabs properly?


My prof at the uni used to say:  Chemistry Saves Lives.  The joke 
goes is that it's a mandatory requirement for the nursing major, so, 
seeding out those incapable of comprehension is not a bad thing. (TM)


Hey, guess what?!  I, too, had to learn how to send mail in a way 
to not have the patches mangled.  It's not rocket science.  
It's kind of the basic knowledge when kernel hacking is at stake.


Maybe if there were minimum qualifications to be a software 
developer nowadays, we wouldn't have dataloss incidents like 
the Adobe Lightroom iOS App Update deleting all the photos 
from your phone, without you the end user having any recourse.


C.

Re: openbsd.org - certain https URLs downgraded to http in redirection

[Constantine A. Murenin]

What you say makes no sense for one simple reason: man.cgi (and cvsweb)
moved out of www.openbsd.org ages ago, prior to there being any https on
www.openbsd.org (correct me if I'm wrong here), so, there should not be any
legitimate organic links that would be linking to https towards
www.openbsd.org/cgi-bin/ in the first place; as such, there's little reason
to change anything here.

C.

On Tue, 31 Mar 2020 at 08:00, Aham Brahmasmi  wrote:

> Namaste misc,
>
> Apologies for the reincarnation of this mail trail.
>
> > Sent: Tuesday, February 25, 2020 at 10:40 PM
> > From: "Constantine A. Murenin" 
> > To: "Vincenzo Nicosia" 
> > Cc: "Stuart Henderson" , "misc@openbsd.org" <
> misc@openbsd.org>
> > Subject: Re: openbsd.org - certain https URLs downgraded to http in
> redirection
> >
> > On Tue, 25 Feb 2020 at 04:35, Vincenzo Nicosia 
> wrote:
> >
> > > On Tue, Feb 25, 2020 at 07:57:24AM -, Stuart Henderson wrote:
> > >
> > > [cut]
> > >
> > > > > Want https? great. use it.  There are times when it's handy to NOT
> > > > > be obsessed with https (i.e., clock is hosed on your computer).
> > > > >
> > > > > So ... unless some developer I really respect (which is just about
> > > > > all of them1) tells me to change this, I'm not planning on
> > > > > changing the behavior of the machines.
> > > >
> > > > I did object to http->https redirects in the past, but now the web is
> > > > unusable without working https anyway and the "INSECURE openbsd.org"
> > > > shown on some browsers *is* a bit of an eyesore ...
> > > >
> > >
> > > IMHO, the fact that corporates (Google) want to dictate what is secure
> > > and what is not, is not sufficient to force everybody on https, at all
> > > times. I personally don't give a toss of what Chrome thinks of a
> > > website and its security (maybe because I have never used Chrome or
> > > because I quit google searches more than 10 years ago...).
> > >
> > > There are many cases where the overhead introduced by https is really
> > > not worth the extra bit of confidentiality you get. And we are talking
> > > here of manpages (that are installed in your system anyway) and of
> > > system sources (that are available for download at any time, even from
> > > an HTTPS mirror)...
> > >
> > > Sorry for the rant, but if I type "http://bring.me.there"; I don't want
> > > to find myself at "https://we.brought.you.somewhere.else";. I am not a
> > > chimp. I know what I type in my URL box. I know what I expect. And I
> > > want to be able to serve content via HTTP/1.0 if I need so.
> > >
> >
> > Exactly.
> >
> > Folks often forget, or are blissfully unaware, that Google Search itself
> > still does work over both HTTP (without the S) as well as over the legacy
> > TLSv1.0 HTTPS, so, the propaganda efforts and the destructive webmaster
> > advice given by the Google Chrome and Mozilla teams to suppress the
> > minorities from being able to access the websites is hypocritical, to say
> > the least.  /Do as I say, not as I do./
> >
> > The HTTP and TLSv1.0 traffic is mostly bots, some folks say?  Surprise —
> > many bots are still controlled by good people, used to do various useful
> > things, so, you're still blocking actual people from a minority class
> from
> > having access to your website.  Not to mention the older phones and
> tablets
> > with hundreds of megabytes of RAM and gigabytes of storage space that
> were
> > abandoned by their creators and don't support TLSv1.2 and/or all the
> newest
> > ciphers that are deemed to be the best practice today.  The sad part is
> > that the non-profits of today (e.g., Mozilla and Wikipedia) are
> effectively
> > brokering the planned obsolescence of all these devices on behalf of the
> > respective vendors.
> >
> > C.
> >
>
> Current situation:
>
> https://www.openbsd.org/cgi-bin/man.cgi* ->
> http://man.openbsd.org/cgi-bin/man.cgi*
> https://www.openbsd.org/cgi-bin/cvsweb ->
> http://cvsweb.openbsd.org/cgi-bin/cvsweb
>
> http://www.openbsd.org/cgi-bin/man.cgi* ->
> http://man.openbsd.org/cgi-bin/man.cgi*
> http://www.openbsd.org/cgi-bin/cvsweb ->
> http://cvsweb.openbsd.org/cgi-bin/cvsweb
>
> What volks here thought I was asking for:
>
> https://www.openbsd.org/cgi-bin/man.cgi* ->
> https://man.

Re: openbsd.org - certain https URLs downgraded to http in redirection

[Constantine A. Murenin]

On Tue, 25 Feb 2020 at 04:35, Vincenzo Nicosia  wrote:

> On Tue, Feb 25, 2020 at 07:57:24AM -, Stuart Henderson wrote:
>
> [cut]
>
> > > Want https? great. use it.  There are times when it's handy to NOT
> > > be obsessed with https (i.e., clock is hosed on your computer).
> > >
> > > So ... unless some developer I really respect (which is just about
> > > all of them1) tells me to change this, I'm not planning on
> > > changing the behavior of the machines.
> >
> > I did object to http->https redirects in the past, but now the web is
> > unusable without working https anyway and the "INSECURE openbsd.org"
> > shown on some browsers *is* a bit of an eyesore ...
> >
>
> IMHO, the fact that corporates (Google) want to dictate what is secure
> and what is not, is not sufficient to force everybody on https, at all
> times. I personally don't give a toss of what Chrome thinks of a
> website and its security (maybe because I have never used Chrome or
> because I quit google searches more than 10 years ago...).
>
> There are many cases where the overhead introduced by https is really
> not worth the extra bit of confidentiality you get. And we are talking
> here of manpages (that are installed in your system anyway) and of
> system sources (that are available for download at any time, even from
> an HTTPS mirror)...
>
> Sorry for the rant, but if I type "http://bring.me.there"; I don't want
> to find myself at "https://we.brought.you.somewhere.else";. I am not a
> chimp. I know what I type in my URL box. I know what I expect. And I
> want to be able to serve content via HTTP/1.0 if I need so.
>

Exactly.

Folks often forget, or are blissfully unaware, that Google Search itself
still does work over both HTTP (without the S) as well as over the legacy
TLSv1.0 HTTPS, so, the propaganda efforts and the destructive webmaster
advice given by the Google Chrome and Mozilla teams to suppress the
minorities from being able to access the websites is hypocritical, to say
the least.  /Do as I say, not as I do./

The HTTP and TLSv1.0 traffic is mostly bots, some folks say?  Surprise —
many bots are still controlled by good people, used to do various useful
things, so, you're still blocking actual people from a minority class from
having access to your website.  Not to mention the older phones and tablets
with hundreds of megabytes of RAM and gigabytes of storage space that were
abandoned by their creators and don't support TLSv1.2 and/or all the newest
ciphers that are deemed to be the best practice today.  The sad part is
that the non-profits of today (e.g., Mozilla and Wikipedia) are effectively
brokering the planned obsolescence of all these devices on behalf of the
respective vendors.

C.

softraid(4) RAID1 tools or experimental patches for consistency checking

[Constantine A. Murenin]

Dear misc@,

I'm curious if anyone has any sort of tools / patches to verify the consistency 
of softraid(4) RAID1 volumes?


If one adds a new disc (i.e. chunk) to a volume with the RAID1 discipline, the 
resilvering process of softraid(4) will read data from one of the existing 
discs, and write it back to all the discs, ridding you of the artefacts that 
could potentially be used to reconstruct the flipped bits correctly.

Additionally, this resilvering process is also really slow.  Per my notes from 
a few years ago, softraid has a fixed block size of 64KB (MAXPHYS); if we're 
talking about spindle-based HDDs, they only support like 80 random IOPS at 7,2k 
RPM, half of which we gotta use for reads, half for writes; this means it'll 
take (1TB/64KB/(80/s/2)) = 4,5 days to resilver each 1TB of an average 7,2k RPM 
HDD; compare this with sequential resilvering, which will take (1TB/120MB/s) = 
2,3 hours; the reality may vary from these imprecise calculations, but these 
numbers do seem representative of the experience.

The above behaviour is defined here:

http://bxr.su/o/sys/dev/softraid_raid1.c#sr_raid1_rw

369} else {
370/* writes go on all working disks */
371chunk = i;
372scp = sd->sd_vol.sv_chunks[chunk];
373switch (scp->src_meta.scm_status) {
374case BIOC_SDONLINE:
375case BIOC_SDSCRUB:
376case BIOC_SDREBUILD:
377break;
378
379case BIOC_SDHOTSPARE: /* should never happen */
380case BIOC_SDOFFLINE:
381continue;
382
383default:
384goto bad;
385}
386}


What we could do is something like the following, to pretend that any online 
volume is not available for writes when the wu (Work Unit) we're handling is 
part of the rebuild process from http://bxr.su/o/sys/dev/softraid.c#sr_rebuild, 
mimicking the BIOC_SDOFFLINE behaviour for BIOC_SDONLINE chunks (discs) when 
the SR_WUF_REBUILD flag is set for the workunit:

switch (scp->src_meta.scm_status) {
case BIOC_SDONLINE:
+   if (wu->swu_flags & SR_WUF_REBUILD)
+   continue;   /* must be same as 
BIOC_SDOFFLINE case */
+   /* FALLTHROUGH */
case BIOC_SDSCRUB:
case BIOC_SDREBUILD:


Obviously, there's both pros and cons to such an approach; I've tested a 
variation of the above in production (not a fan weeks-long random-read/write 
rebuilds); but use this at your own risk, obviously.

...

But back to the original problem, this consistency check would have to be 
file-system-specific, because we gotta know which blocks of softraid have and 
have not been used by the filesystem, as softraid itself is 
filesystem-agnostic.  I'd imagine it'll be somewhat similar in concept to the 
fstrim(8) utility on GNU/Linux -- 
http://man7.org/linux/man-pages/man8/fstrim.8.html -- and would also open the 
door for the cron-based TRIM support as well (it would also have to know the 
softraid format itself, too).  Any pointers or hints where to get started, or 
whether anyone has worked on this in the past?


Cheers,
Constantine.http://cm.su/

Re: But there is Fossil...

[Constantine A. Murenin]

The problem with Fossil is lack of a driving force.

GitHub is so successful because it is non-trivial to get Git working.  Now
that Git is a standard, there's a lot of copycats for GitHub itself,
because every developer knows Git.*

Fossil seems to be pretty easy to use all by itself, hence there's no
service similar to GitHub, because the added value would be considerably
smaller, plus you'll be going up against the giants like Git and GitHub; in
fact, Bitbucket has already abandoned Mercurial support recently, embracing
the monoculture of Git.

If anyone's more interested in Fossil, http://fossil-scm.org/ website
itself runs on Fossil (yes, it's self-hosted, and, yes, Fossil itself comes
with a CMS, as well as a bug-tracking system), but there's also
https://src.fossil.netbsd.org/ — the timeline interface is claimed to be
the best feature of Fossil, it provides great visual representation of
commits on all the branches as they happen; e.g.,
https://src.fossil.netbsd.org/timeline?n=50&b=2020-01-02+15:42:26 (in case
there's nothing on branches on this link, see http://archive.is/dmKxZ , or
http://web.archive.org/web/20200107001225/https://src.fossil.netbsd.org/timeline?n=50&b=2020-01-02+15:42:26
, which shows exactly which release branches were updated at what time and
in what order).  The other key difference of Fossil compared to Git is that
the whole history of work is permanent, not transient like in Git's branch
and squash-merge model, e.g., you don't just remove things (like branches)
from the repository that were there yesterday, like in Git, and unlike in
CVS or many other systems.

Does it mean OpenBSD and/or NetBSD should switch to Fossil?  No, that's not
what I said.

Cheers,
Constantine.  http://cm.su/

Re: Hyperbola Gnu Linux changing to Bsd

[Constantine A. Murenin]

>> https://notabug.org/jadedctrl/libertybsd-scripts-mirror/issues/5

On Mon, 30 Dec 2019 at 19:57, Nick Holland  wrote:
> most of them are stupid words.  I just spot checked one of the
> "license problems" they think they spotted in the OpenBSD tree.
>
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/arch/landisk/include/endian.h?rev=1.2
>
> What exactly are they planning on licensing in that?

Seriously?  Did they somehow miss all of our Makefiles?  None of which
have an appropriate licence header, either?

I think they're toast!

C.

Re: Hyperbola Gnu Linux changing to Bsd

[Constantine A. Murenin]

On Mon, 30 Dec 2019 at 15:24, Ian Darwin  wrote:
>
> On 12/30/19 15:02, Peter Nicolai Mathias Hansteen wrote:
> > The TL;DR version is that taking code or any other body of work that is 
> > offered to you under a permissive license and making your changes to it 
> > available only under a more restrictive one may be legal in some or all 
> > jurisdictions, but it is most certainly a sign of an almost total lack of 
> > respect for the people who did the original work.
>
> Not to mention: putting code under a more restrictive license than
> previously, while calling it "more free", is hypocrisy, pure and simple.
> Nothing gnu here, folks.


Has anything ever came out of these Linux-libre projects that fork
purely for GPL reasons?  I thought they usually work simply by
removing the things out without having the expertise to ever write any
suitable replacements; e.g., they'll probably first remove
fw_update(1) to break your wireless, then after a few years, they'll
find a little bit of freely redistributable microcode in various
Ethernet drivers of OpenBSD, and will break those drivers as well,
without ever providing any replacements, either, of course.


Theo has previously addressed this whole question of
freely-redistributable proprietary microcode/firmware in OpenBSD,
urging the (GNU) people to stop loading the OpenBSD devs with more
tasks:


* http://web.archive.org/web/20060603230017/http://kerneltrap.org/node/6550

* http://archive.is/CARbI



:Jeremy Andrews: Each OpenBSD release includes a theme song that
goes along with the release's artwork. OpenBSD 3.9's theme song is
titled "Blob!". Can you explain what binary blobs are and why they're
a problem?
:
:Theo de Raadt: Vendors often try to hand off two kinds of binary
code to us, which they expect we will happily incorporate into our
system (and then, hopefully, we will shut up).
:
:The first kind to mention is firmwares. Firmwares (like for
instance on a Intel wireless card, or a such) are binary pieces of
code that will run on the little processor that is on the wireless
card. As an operating system, we need to load the code out to the
card. To include a firmware in OpenBSD, we simply need a nice
copyright statement from the vendor that lets us distribute the
firmware. Some vendors won't even go that far, though.
:
:The second kind of binary data vendors feed us are blobs. This is
code that is expected to be linked against the operating system and
run on the host processor. There are many problems with this. First
off, can we trust the code to do what it should do? I don't think so.
If there is a bug, can we fix it? No, as developers our hands are
tied, and if our user community runs into bugs it just makes us look
bad. Therefore when faced with the choice of supporting a device very
poorly (as the blob would force us to) we instead choose to wait until
we (or someone else) can reverse engineer it or.
:
:Jeremy Andrews: What is it about binary firmware that you're
willing to ship it, versus binary blobs? How can you trust the
firmware binary to do what it should do? And what if the firmware has
a bug?
:
:Theo de Raadt: Quite honestly I prefer chips which have no
firmware, and instead use correctly designed hardware logic, which our
driver must then drive. Note that most ethernet chipsets do not use a
processor, but many scsi chipsets do. Most IDE chipsets do not, but
for wireless devices ... it is about half and half. This clearly has
to do with the complexity of the data flow problem being dealt with.
:
:But in the end, if we wish to support any such devices, we must
be practical. We must accept the risk that there is a flaw in the
firmware. (Is that not what many of us have been coping with for years
now with Prism wireless chipsets and their firmware update tools?) But
the legal climate is a real problem for us -- that is why we must get
copyright permission to distribute the firmware images. Once they are
distributed... at least the device works.
:
:Of course, also note that we don't want to become Hermes (the
architecture of the Lucent/Prism/Symbol chip) assembly language
programmers... we have more than enough to do. Just a specific
example. Please, people, don't load us up with more tasks ;)
:
:Jeremy Andrews: Blobs seem especially common with wireless
ethernet cards and graphics cards, why is that?
:
:Theo de Raadt: Graphics cards have gotten to this point because
of their complexity. But these blobs also cope with lots of bugs in
the devices. These bugs are because graphics cards are devloped very
quickly now, and the hope is that software would work around the
hardware bugs.
:
:I don't know why any wireless cards use blobs. In fact, very few
do. They should just document their chips. There's a lot of hogwash
flying around about FCC rules, but if that was a concern of theirs
they should just design their chips to lock the channels in hardware.
But of course, noone in Taiwan does. So did the U

Re: cloudflare.cdn.openbsd.org Certificate expired.

[Constantine A. Murenin]

This is pretty hilarious!

Apparently, even the CDNs cannot keep the HTTPS certificates
up-to-date.  Yet your blog with cat photos MUST have HTTPS, and the
cost of having HTTPS is estimated at zero by the leading industry
experts at Google Chrome, Mozilla and Cloudflare (isn't it ironic
now?!).

Clearly it's zero.  Every major browser vendor confirms administrative
costs are zero and/or negligible; and HTTP/2 (as implemented in the
browsers) requires HTTPS, because why would you NOT use HTTPS?!  And
if it's not zero, folks wouldn't use HTTPS everywhere, now would
they?!

Hurray to HTTPS Everywhere!  Let's Encrypt!

/sarcasm

On Sat, 20 Oct 2018 at 11:49, Paco Esteban  wrote:
>
> Hi misc@
>
> You're probably aware of this but just in case:
>
> https://cloudflare.cdn.openbsd.org/pub/OpenBSD/6.4/packages-stable/i386/:
> ftp: SSL write error: certificate verification failed: certificate has expired
> https://cloudflare.cdn.openbsd.org/pub/OpenBSD/6.4/packages/i386/:
> ftp: SSL write error: certificate verification failed: certificate has expired
> https://cloudflare.cdn.openbsd.org/pub/OpenBSD/6.4/packages/i386/:
> empty
>
> Cheers,
> Paco.
>
> p.s.: Big thanks for 6.4 to all the people involved !
>
> --
> Paco Esteban
> https://onna.be/gpgkey.asc

Re: SSH extremely quickly dropped from T-Mobile phone hotspot

[Constantine A. Murenin]

On 16 September 2018 at 00:45, Chris Bennett
 wrote:
> I get the same internal NAT'ed IP4 address every time, but my public IP4
> address differs over time.
>
> I don't like the idea at all of keeping an open ssh session going on
> without having my equipment on and me nearby.

I don't think you understand how ssh works (unless you have a belief
that the underlying cryptography is insecure, at which point, it's
unclear how any of this is then relevant to T-Mobile US).

It's irrelevant what IPv4 addresses you have, since it all has to pass
through NAT on your device as well as CGNAT at the carrier level, with
the state of the established connections expiring within minutes of
disuse.

The reason your SSH connections break is because the underlying TCP
connections must be kept alive for the CGNAT to work on a keep-state
basis; this can only be accomplished by either sending more packets
all the time to make sure the state never expires whilst you're still
using your session (e.g., the `ssh -oServerAliveInterval=240 …` and
such), or by getting rid of all types of keep-state NAT and ensuring
there's no stateful firewall in place (and, for this, I've already
confirmed that it works just fine over T-Mobile US IPv6 with TCP
connections remaining open for 1h and more, whereas the IPv4
connections indeed expire after only a few minutes due to the
state-based NAT).

C.

Re: SSH extremely quickly dropped from T-Mobile phone hotspot

[Constantine A. Murenin]

On 15 September 2018 at 09:50, Chris Bennett <
cpb_m...@bennettconstruction.us> wrote:

> I am using my phone's hotspot, which may or may not be secure, but is
> not censoring my choice of sites to visit. Public WiFi in the USA does
> so all over the place. Worse, when I lived in Washington State, I was
> next to a Naval Air Station, which certainly eavesdrops, not OK, but
> this is the land of the free? Now I am living in the Capital of Texas,
> Austin which also leaves public WiFi under the same problems
> (legislature meets here).
>
> I cannot maintain an SSH connection unattended long enough to go to the
> bathroom and get a cup of coffee without the connection being dropped
> halfway through reading my email.
>
> Is autossh the right choice or is there a better way?
> The flow of data seems to be the problem. A static page disconnects.
>
> Thanks,
> Chris Bennett
>

I also have T-Mobile US, and I cannot reproduce your problem.

In fact, because my laptop gets a public IPv6 address from T-Mobile US — a
standard feature in Android 7.1.1, where you get at least a whole /64 from
the carrier — I can put it to sleep, disable AndroidAP, go get coffee,
lunch, dinner, or attend a meetup, or all of the above, come back home,
turn AndroidAP back on, turn my laptop on, and my vanilla ssh connection
will come back to live after a single keystroke (provided the phone was
never turned off and didn't itself lose network connectivity, e.g., still
has the same /64 assigned to itself).

I did have to configure my laptop to `sysctl -w
net.inet6.ip6.prefer_tempaddr=0`, and also make sure I'm not running
something that'd be constantly refreshing the screen of the terminal I'm
accessing through ssh, e.g., you definitely do have to disconnect tmux with
the timestamp before you attempt this, and doing socks proxying would
obviously interfere with it as well if any connections remain open when you
attempt to turns things off like that, and — viola, problem solved.

So, my suggestion — move to IPv6 for the killer features, and stop worrying
about the disconnects.

But if you don't have a public IP address on your laptop and do get your
internet through NAT/CGNAT and/or a stateful firewall, then you might have
to play with `-oServerAliveInterval=480` or some such, as per
http://mdoc.su/o/ssh_config.5, but, otherwise, this option is actually not
only unnecessary, but is, in fact, harmful, as it may "detect" brief
periods of connectivity loss that you don't necessarily care about.

P.S. Another option, if you don't necessarily care about scrolling, and/or
already use tmux within your ssh, is to use http://ports.su/net/mosh.
Personally, I prefer straight ssh through IPv6 to mosh, although sometimes
it does cause me to use my AndroidAP even in venues where the public
internet is available.

Cheers,
Constantine.SU.

Re: OpenBSD logo on my private hompage. It is allowed?

[Constantine A. Murenin]

On 7 June 2018 at 17:36, Johannes Krottmayer  wrote:
> Can I use the OpenBSD logo on my homepage? It is allowed?
> I can't find any information about this plan.

http://www.openbsd.org/art1.html has all the details.

C.

Re: opensmtpd: limit mta for mx

[Constantine A. Murenin]

On 4 March 2018 at 23:11, Nick  wrote:
> In smtpd.conf, the "limit mta" line can be qualified like this:
>
> limit mta for domain gmail.com inet4
>
> which I did because I recently started getting bounces from google saying
>
> 550-5.7.1 [2001:19f0:5001:2f5:5400:ff:fe77:861d] Our system has detected that 
> this message does not meet IPv6 sending guidelines regarding PTR records and 
> authentication. Please review  
> https://support.google.com/mail/?p=IPv6AuthError for more information . 
> d63si3145626edc.222 - gsmtp

Whilst this is a valid question for OpenSMTPD, from the sysadmin side,
the solution is much simpler.

Your reverse name is fake, as it does not resolve forward:

% host 2001:19f0:5001:2f5:5400:ff:fe77:861d
d.1.6.8.7.7.e.f.f.f.0.0.0.0.4.5.5.f.2.0.1.0.0.5.0.f.9.1.1.0.0.2.ip6.arpa
domain name pointer comms.kousu.ca.
% host comms.kousu.ca.
comms.kousu.ca has address 108.61.165.176
%

I'm surprised you don't get other hosts rejecting your mail, too; I
suspect it may have to do simply with gmail being the monoculture of
mail nowadays.

My suggestion would be to fix the forward name, else, fix the reverse
name to point to something like IPv6.example.org, which you should
ensure exists and points back.  Sometime ago, making the reverse point
back to itself (e.g., a PTR with the value of the IPv6 address itself)
also made gmail happy to accept the mail as well, but I'm not too sure
if that's still the case.

Cheers,
Constantine.
http://cm.su/

Re: UNIX Stackexchange - Community Promotion Ads - 2018

[Constantine A. Murenin]

On 25 February 2018 at 12:48, Ingo Schwarze  wrote:
> Hi Martin,
>
> Martin Schroeder wrote on Sun, Feb 25, 2018 at 08:00:34PM +0100:
>> 2018-02-25 18:29 GMT+01:00 Ingo Schwarze :
>
>>> And no, i'm not going to create an account on some
>>> random site just for such a petty thing.
>
>> Stackoverflow is "some random website". :-)
>
> You can say that again, I'm dead serious.
>
> I have literally spent years working on documentation, and i shall
> be giving my seventh presentation on that topic during an international
> BSD conference at BSDCan in Ottawa, June 8 or 9 this year, so i
> kind of know what i'm talking about.
>
> Stackoverflow is definitely not among the things you should consider
> or look at when you want to understand how stuff works, when you
> are trying to solve a problem, or when you want to help people to
> use software more efficiently.

Unfortunately, StackOverflow is a very difficult-to-avoid site
nowadays, unless you can easily live without using Google for your
tech-related questions, either.

However, I completely agree with the sentiment that the site is quite
toxic, and I have 10k+ on StackOverflow and 30k+ on the whole
StackExchange network, so I know a thing or two about it.

The StackOverflow company routinely deletes your comments, questions
and answers, often for very superficial reasons (including
automatically based on metrics) and without any regard to the
individual quality thereof, and effectively without you having any
control over the explicitly human-generated textual data that you
entrust them with.  (Most folks don't even know this, until they're
already hooked and their questions/comments/answers are gone and
unfetchable.)

Who likes their own well-articulated notes randomly deleted for
superficial reasons behind their backs?  Why not let you see what got
deleted, so you can decide whether it's worth reposting in another
venue?

I recently got 10k on StackOverflow, which is the minimum reputation
required to see not just any deleted stuff, but even your own deleted
questions and answers; and the sheer volume of my own questions and
answers that got deleted (some of which was done automatically based
on rather arbitrary "metrics" without any human intervention) is
simply mind boggling — `deleted:1` returns 36 results (questions
and/or answers), which at 259 A + 105 Q in my profile, represents
nearly 10% of my Qs and As!  I've used the site for years, and knew
some of my stuff was gone, but I was nonetheless totally surprised and
shocked to see just how much of it was deleted and hidden from me
until 10k!

Effectively, every 10th answer or question just gets wiped out without
a trace (until/unless you're a mod or have 10k+ rep), does that sound
OK to you?!  And since they keep the scoring and feature activation
separate for each of their sites, some of my own Qs and As on the
other StackExchange sites in the network are still unavailable to me
even at this stage.  (Meanwhile, various throwaway, bogus, incomplete
and duplicate questions and spam answers from years ago still remain
on their sites; and flagging any of these is basically a gamble and
often results in absolutely no action.)

So, I completely agree with Ingo that noone should be promoting
StackOverflow and StackExchange et al, especially in the open-source
communities, at least until the above model where withholding your own
contributions from your own self is the modus operandi at
StackExchange/StackOverflow company.  Personally, even though I still
participate in SO/SE, I 100% boycotted their new "documentation"
effort, not contributing a single article to it, IIRC (LOL, I just
checked, and they did shut it down — apparently, I must have been not
the only one who didn't like the idea).

Cheers,
Constantine.
http://cm.su/

>
> Yours,
>   Ingo
>
>> Thanks. YMMD.

Re: ordering

[Constantine A. Murenin]

On 15/04/2017, Friedrich Locke  wrote:
> Hi folks,
>
> i would like to order obsd 6.1, butfrom the openbsd store i cannot see it
> available for ordering.
> May you help me ?

http://www.openbsd.org/lyrics.html#60f

Notice that the 61.html page no longer has any ISBN numbers, BTW.

C.

Re: vxlan paper from AsiaBSDCon 2014

[Constantine A. Murenin]

On 28 April 2016 at 13:36, lists  wrote:
> Hello misc,
>
> I was looking for the slides of the presentation done by reyk@.
>
> I have checked http://www.openbsd.org/papers/index.html
>
> Thanks,
> Jim

Not sure about the slides, but the proceedings of the conference are
available from http://2014.asiabsdcon.org/papers/, more specifically,
https://2014.asiabsdcon.org/papers/abc2014-proc-all.pdf, and the vxlan
paper is included in said proceedings (pages 91 to 95).

Cheers,
Constantine.SU.

Re: OT: Looking for email host with qmail like minus-addressing for custom domain

[Constantine A. Murenin]

On 2 March 2016 at 14:19, Claus Niesen  wrote:
> Sorry for the off topic question but I'm hoping that maybe some of your
> know of or work for an email hosting provider that provides minus/hyphen
> ("-") addressing with custom domain.  All I can find are provider that
> offer plus addressing, which makes it hard for a smooth transition since
> I'm using minus addressing extensively.
>
> I used to run my own at home mailserver (openbsd + qmail) .  Since I no
> longer have a static IP, I switched to an email provider that supports
> minus addressing but operates in the dark ages, especially in regards to
> security updates.  Needless to say I need a better host.  I'd rather not
> host my own mailserver but so far haven't been able to find an
> alternative.
>
> Your suggestions are greatly appreciated.  Feel free to contact me off
> list.
> Thanks,
> Claus
>
> Specific requirements:
> - allows usage of custom domain
> - allows multiple email accounts
> - qmail style '-' addressing
> - some kind of spam filtering (gray-listing & bayes filter)
> - alias
> - imap
> - reliable and secure

So, how much are you willing to pay for this service?

Static IP costs on a residential connection usually start at 5 USD/mo
in the US.  Presumably, that's also how much you'd be willing to pay
for a "reliable and secure"  email service with a custom domain and
qmail-style addressing.  (That's not even considering any extra you'd
have to pay for a provider specifically targeting the niche of serving
it OpenBSD-style.)

At this price, nowadays you might as well get a whole virtual or even
a dedicated bare metal server to play with, from Hetzner, Online,
OVH/Kimsufi et al (I maintain a list at http://dedi.su/ ), and run an
actual qmail on it, or even OpenSMTPD, as you see fit.  (OpenBSD works
great on most of these hosts, even if it's not specifically advertised
as supported.)

Otherwise, what is it that we are missing from your requirements that
makes this a worthwhile discussion for misc@openbsd.org?

C.

Re: OT: Looking for email host with qmail like minus-addressing for custom domain

[Constantine A. Murenin]

On 3 March 2016 at 14:39, Andy Bradford  wrote:
> Thus said Gilles Chehade on Thu, 03 Mar 2016 10:14:48 +0100:
>
>> Who should get mail for foo-bar@ ?
>
> The MTA will decide who will get foo-bar@.

How?  A /dev/mind RPC? :-)

>> This just doesn't happen with + because:
>
> It also doesn't happen with an MTA that can figure these things out.

So, how would it figure it out?

And what happens if a "conflicting" user gets created after a mail was
sent, but before it was delivered?  "This behaviour is undefined"?

C.

Re: OpenBSD softraid can do scrub, hotspare, hotswap? How do rebuild + those 3 really done? (Absence of docs and howtos - ultimate Q!)

[Constantine A. Murenin]

On 20 February 2016 at 14:29, Tinker  wrote:
[..]
> On 2016-02-21 04:39, Constantine A. Murenin wrote:
[..]
>> When you do http://mdoc.su/o/newfs.8, it does not write to every
>> sector of the underlying partition; thus you cannot expect all sectors
>> to be the same.
>
>
> Ah right, so at least to prepare for a RAID1C rebuild to work, at raid setup
> time before disklabel/newfs, one should initialize by doing "dd if=/dev/zero
> of=thelogicalraiddevice".

This would make the logical view from within softraid_raid1 appear the
same (e.g., an `sd3` regardless of which chunk it is being read from),
but the underlying `sd{0,1,2}a` chunks that would be backing it up
would still be different, because metadata
(http://bxr.su/o/sys/dev/softraidvar.h#sr_metadata).

C.

Re: OpenBSD softraid can do scrub, hotspare, hotswap? How do rebuild + those 3 really done? (Absence of docs and howtos - ultimate Q!)

[Constantine A. Murenin]

On 20 February 2016 at 12:23, Tinker  wrote:
>
> On 2016-02-21 01:29, Karel Gardas wrote:
>>
>> scrub is IIRC not supported by any softraid yet.
>
>
> But there's "patrol"!
>
> "bioctl -t start mysoftraid"

[...]

> On 2016-02-21 02:44, Constantine A. Murenin wrote:
>>
>> On 20 February 2016 at 10:29, Karel Gardas  wrote:
>>>
>>> scrub is IIRC not supported by any softraid yet. Rebuild by all which
>>> support redundancy. Marcus recommendation to read man pages can just
>>> be highlighted here. Otherwise just read the code for ultimate
>>> reference of what is or is not done.
>>
>>
>> Scrub cannot possibly be supported due to the design of the softraid:
>>
>> http://mdoc.su/o/softraid.4
>>
>>>>>> The RAID 1 discipline does not initialize the mirror upon creation.
>>>>>> This is by design because all sectors that are read are written first. 
>>>>>> There
>>>>>> is no point in wasting a lot of time syncing random data.
>>
>>
>> IIRC, other raid disciplines are not that much different, either.
>>
>> E.g., a scrub implementation would have to be implemented on top of
>> the filesystem, and would have to be able to temporarily force the
>> reads to be done from a certain chunk only.
>>
>> Long-term, it'll probably be easier to re-do the logic to actually
>> zero-out all the unused sectors, if scrub support is deemed important.
>> Which is why things like ZFS are superior due to having the awareness
>> of the underlying storage blocks.
>
>
> Wait, I don't see the philosophical problem that you seem to be highlighting
> here ("sectors are .. written first" and "on top of the filesystem" and
> "forcing reads to be done from a certain chunk only"), what am I
> missing/what is it that I don't understand?

When you do http://mdoc.su/o/newfs.8, it does not write to every
sector of the underlying partition; thus you cannot expect all sectors
to be the same.

>
>
> Also, so you mean that "patrol" even if it's in the manual is not supported
> for RAID1 nor for RAID1C nor for RAID5 or any other raid discipline. Looking
> forward to see what Marcus says & test myself & read code.

Heh, I didn't even know about this "patrol"; learn something new every day!

A BXR.SU for "patrol" has a few MFI(4) hits across the BSDs, and
ultimately reveals the `bioc_patrol` symbol (well, a struct, really,
http://bxr.su/o/sys/dev/biovar.h#bioc_patrol), a search of which
reveals that http://bxr.su/o/sys/dev/ic/mfi.c#mfi_ioctl_patrol is the
only driver reference for this symbol.

So, I don't think you'll be getting any patrol from softraid(4); it
was added very recently by uebayasi@ on 2015-05-29, based on mfiutil
from FreeBSD (http://mdoc.su/f/mfiutil.8), and only for mfi(4).

C.

Re: OpenBSD softraid can do scrub, hotspare, hotswap? How do rebuild + those 3 really done? (Absence of docs and howtos - ultimate Q!)

[Constantine A. Murenin]

On 20 February 2016 at 10:29, Karel Gardas  wrote:
> scrub is IIRC not supported by any softraid yet. Rebuild by all which
> support redundancy. Marcus recommendation to read man pages can just
> be highlighted here. Otherwise just read the code for ultimate
> reference of what is or is not done.

Scrub cannot possibly be supported due to the design of the softraid:

http://mdoc.su/o/softraid.4

 The RAID 1 discipline does not initialize the mirror upon creation. This 
 is by design because all sectors that are read are written first. There is 
 no point in wasting a lot of time syncing random data.

IIRC, other raid disciplines are not that much different, either.

E.g., a scrub implementation would have to be implemented on top of
the filesystem, and would have to be able to temporarily force the
reads to be done from a certain chunk only.

Long-term, it'll probably be easier to re-do the logic to actually
zero-out all the unused sectors, if scrub support is deemed important.
Which is why things like ZFS are superior due to having the awareness
of the underlying storage blocks.

C.

Re: Will Softraid RAID1 read from the fastest mirror/-s / supports user-specified device read priority order, nowadays? Takes broken disk out of use?

[Constantine A. Murenin]

On 13 February 2016 at 08:50, Tinker  wrote:
> Hi,
>
> 1)
> http://www.openbsd.org/papers/asiabsdcon2010_softraid/softraid.pdf page 3
> "2.2 RAID 1" says that it reads "on a round-robin basis from all active
> chunks", i.e. read operations are spread evenly across disks.

Yes, that's still the case today:

http://bxr.su/o/sys/dev/softraid_raid1.c#sr_raid1_rw

345rt = 0;
346ragain:
347/* interleave reads */
348chunk = sd->mds.mdd_raid1.sr1_counter++ %
349sd->sd_meta->ssdi.ssd_chunk_no;
350scp = sd->sd_vol.sv_chunks[chunk];
351switch (scp->src_meta.scm_status) {

356case BIOC_SDOFFLINE:

359if (rt++ < sd->sd_meta->ssdi.ssd_chunk_no)
360goto ragain;

There are presently no optimisations in-tree, but the softraid
policies are so simple that it's really easy to hack it up to do
something else that you may want.

>
> Since then did anyone implement selective reading based on experienced read
> operation time, or a user-specified device read priority order?

That would make the code less readable!  :-)

>
>
> That would allow Softraid RAID1 based on 1 SSD mirror + 1 SSD mirror + 1 HDD
> mirror, which would give the best combination of IO performance and data
> security OpenBSD would offer today.

Not sure what'd be the practical point of such a setup.  Your writes
will still be limited by the slowest component, and IOPS specs are
vastly different between SSDs and HDDs.  (And modern SSDs are no
longer considered nearly as unreliable as they once were.)

>
> 2)
> Also if there's a read/write failure (or excessive time consumption for a
> single operation, say 15 seconds), will Softraid RAID1 learn to take the
> broken disk out of use?

A failure in a softraid1 chunk will result in the chunk being taken
offline.  (What constitutes a failure is most likely outside of
softraid's control.)

C.

Re: Buffer cache made to use >32bit mem addresses (i.e. >~3GB support for the buffer cache) nowadays or planned soon?

[Constantine A. Murenin]

On 14 February 2016 at 10:29, Karel Gardas  wrote:
> On Sat, Feb 13, 2016 at 9:39 PM, Stuart Henderson  
> wrote:
>> There was this commit, I don't *think* it got reverted.
>>
>>
>>
>> CVSROOT:/cvs
>> Module name:src
>> Changes by: b...@cvs.openbsd.org2013/06/11 13:01:20
>>
>> Modified files:
>> sys/kern   : kern_sysctl.c spec_vnops.c vfs_bio.c
>>  vfs_biomem.c vfs_vops.c
>> sys/sys: buf.h mount.h
>> sys/uvm: uvm_extern.h uvm_page.c
>> usr.bin/systat : iostat.c
>>
>> Log message:
>> High memory page flipping for the buffer cache.
>>
>> This change splits the buffer cache free lists into lists of dma reachable
>> buffers and high memory buffers based on the ranges returned by pmemrange.
>> Buffers move from dma to high memory as they age, but are flipped to dma
>> reachable memory if IO is needed to/from and high mem buffer. The total
>> amount of buffers  allocated is now bufcachepercent of both the dma and
>> the high memory region.
>>
>> This change allows the use of large buffer caches on amd64 using more than
>> 4 GB of memory
>>
>> ok tedu@ krw@ - testing by many.
>
> I think it got reverted by:
>
> commit ac77fb26761065b7f6031098e6a182cacfaf7437
> Author: beck 
> Date:   Tue Jul 9 15:37:43 2013 +
>
> back out the cache flipper temporarily to work out of tree.
> will come back soon.
> ok deraadt@
>
>
> but I'm not an expert so would wait on confirmation by Bob Beck.


Yes, I think you are correct, and it was indeed reverted.


Some parts have since been reimplemented and brought back by
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/vfs_bio.c#rev1.170
on 2015/07/19:

http://marc.info/?l=openbsd-cvs&m=143732292523715&w=2

> CVSROOT:/cvs
> Module name:src
> Changes by:b...@cvs.openbsd.org2015/07/19 10:21:11
>
> Modified files:
> sys/kern   : vfs_bio.c vfs_vops.c
> sys/sys: buf.h
>
> Log message:
> Use two 2q caches for the buffer cache, moving previously warm buffers from 
> the
> first queue to the second.
> Mark the first queue as DMA in preparation for being able to use more memory
> by flipping. Flipper code currently only sets and clears the flag.
> ok tedu@ guenther@


But it looks like the functions that were introduced in the above
commit are still WIP and don't actually flip anything yet:

http://bxr.su/o/sys/kern/vfs_bio.c#buf_flip_high

307buf_flip_high(struct buf *bp)
308{
309KASSERT(ISSET(bp->b_flags, B_BC));
310KASSERT(ISSET(bp->b_flags, B_DMA));
311KASSERT(bp->cache == DMA_CACHE);
312CLR(bp->b_flags, B_DMA);
313/* XXX does nothing to buffer for now */
314}

http://bxr.su/o/sys/kern/vfs_bio.c#buf_flip_dma

317buf_flip_dma(struct buf *bp)
318{
319KASSERT(ISSET(bp->b_flags, B_BC));
320KASSERT(ISSET(bp->b_flags, B_BUSY));
321if (!ISSET(bp->b_flags, B_DMA)) {
322KASSERT(bp->cache > DMA_CACHE);
323KASSERT(bp->cache < NUM_CACHES);
324/* XXX does not flip buffer for now */

Cheers,
Constantine.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Constantine A. Murenin]

On 11 December 2015 at 03:58, Kamil Cholewiński  wrote:
>> The official CD set contains the signify keys for that release and the
>> next one.  Once you have a known good copy of one set, you can always
obtain
>> future ones securely.
>>
>> You don't even need to use the CD set to install, just as a way of
obtaining
>> the signify keys with a high degree of confidence.
>
> This is the real thing bothering me. I don't even have a CD drive
> available, and I was about to ask if it would be possible to get the
> signify keys via paper mail in exchange for a donation. But both paper
> and CDs can be intercepted and tampered with (with some effort).
>
>> I currently just assume they are correct because it'd be enormously
>> complex to spoof the entire OpenBSD distribution, but I souldn't have
>> to rely on "security through effort involved".
>
> Exactly, and this is a problem with the CDs too. There's currently no
> way to securely bootstrap the chain of trust. HTTPS is a way to do that.

LOL.  Maybe you should read this:

http://marc.info/?l=openbsd-bugs&m=138445221329747&w=2

Or take a look at the full list of CAs in your browser.

>
> Yes, we would have to rely on third parties (CAs). It can be optional
> (so that a text browser from an ancient unsupported release can still

Thing is, in https land, a "downgrade" is considered a serious attack,
not a backwards-compatibility feature.

If the browser fails to load https://example.org/, it will not even
suggest you go to the http://example.org/ version.

And what happens when someone gets their web-site onto https?  People
start linking to the https version, so, legacy devices/releases may no
longer be capable of just following the web of links.  (So much for
World Wide Web!)

> access plain HTTP version fine). It can be just a single page like
> keys.openbsd.org so that there are few extra computing resources used.
> It doesn't have to be Let's Encrypt - heck, I'm willing to go to
> RapidSSL or whoever and pay for it myself if someone can give me a CSR
> and assist with domain validation.

Yes, and once you give in to https once, you're hooked and have to
keep paying someone every year, and have to keep changing the cert
every year.

C.

>
> K.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Constantine A. Murenin]

On 11 December 2015 at 02:58, Thijs van Dijk  wrote:
> On 11 December 2015 at 05:51, Andy Bradford 
> wrote:
>
>> If one wants privacy on a website then more is required than just HTTPS.
>>
>
> Right. *I* just want a reasonable (256-bit) guarantee that the signify keys
> on my screen are the ones the OpenBSD authors intended me to see.
>
> I currently just assume they are correct because it'd be enormously complex
> to spoof the entire OpenBSD distribution, but I souldn't have to rely on
> "security through effort involved".
>
> Remember the guy who tried to securely download PuTTY? He couldn't
> 

And I couldn't access his web-site from an OpenBSD box:

% lynx -dump 
https://noncombatant.org/2014/03/03/downloading-software-safely-is-nearly-impossible/

Looking up noncombatant.org
Making HTTPS connection to noncombatant.org
SSL callback:unable to get local issuer certificate, preverify_ok=0, ssl_okay=0
Retrying connection without TLS.
Looking up noncombatant.org
Making HTTPS connection to noncombatant.org
Alert!: Unable to make secure connection to remote host.

lynx: Can't access startfile
https://noncombatant.org/2014/03/03/downloading-software-safely-is-nearly-impossible/
%

C.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Constantine A. Murenin]

On 11 December 2015 at 05:37, Anthony J. Bentley  wrote:
> "Constantine A. Murenin" writes:
>> On 8 December 2015 at 19:26, Anthony J. Bentley  wrote:
>> > Giancarlo Razzolini writes:
>> >> One of the main benefits of the TLS wouldn't only be to render
>> >> impossible for anyone to know which pages you're accessing on the site,
>> >> but also the fact that we would get a little more security getting the
>> >> SSH fingerprints for the anoncvs servers. Having them in clear text as
>> >> they are today, isn't very secure.
>> >
>> > Another attack currently possible against www.openbsd.org is changing
>> > the https://openbsdstore.com links to http://openbsdstore.com, and
>> > running sslstrip on that. Or the PayPal links...
>>
>> For real!  And yet another attack currently possible against
>> www.openbsd.org is being able to view the web-site from any OpenBSD
>> release, even the early ones that did include lynx in base
>> (http://mdoc.su/OpenBSD-2.3/lynx.1), yet are surely missing not only
>> TLSv1.2 (if not OpenSSL in the first place!), but the requisite CA
>> entries in their corresponding cert.pem file as well (that is, if such
>> file was even present).
>
> Why even bring up OpenBSD 2.3? Anyone running that 19 years after its
> release has much bigger problems than not being able to connect to
> www.openbsd.org.

Not really.  It just works.  And there's always time to upgrade to a
newer OpenBSD release, since those continue to be served through http
without any issues.

>
>> And if you're in Kazakhstan, it's also possible to view
>> www.openbsd.org without any issues or security warnings, and will
>> continue being so even after 2016-01-01 when the new telecommunication
>> directive takes force.  (Or was the feature to ignore invalid
>> certificates already added to lynx nowadays?)
>
> I can't tell if you're saying it's a *good* thing that http provides no
> notice that your connection is compromised. Are you serious?

But http connections aren't compromised.  They're just monitored
passively.  (And it's all public data, and, as mentioned, even with
https, the hostnames would still have leaked.)

Since it's impossible to do the same with https, they have to be MitM'ed.

>
> Look, the whole CA model comes with a lot of baggage. Let's Encrypt has
> elements of a new approach but is still tied to that way of thinking.
> Talking on misc@ won't make www.openbsd.org more secure.
>
> But you're defending telnet in 2015.

No.  If you look closely at what Theo has said, especially around
pledge(2), telnet has more problems that just lack of encryption.
Kinda like HTTPS has few-too-many downfalls and bad policies other
than the availability of encryption.

C.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Constantine A. Murenin]

On 8 December 2015 at 19:26, Anthony J. Bentley  wrote:
> Giancarlo Razzolini writes:
>> One of the main benefits of the TLS wouldn't only be to render
>> impossible for anyone to know which pages you're accessing on the site,
>> but also the fact that we would get a little more security getting the
>> SSH fingerprints for the anoncvs servers. Having them in clear text as
>> they are today, isn't very secure.
>
> Another attack currently possible against www.openbsd.org is changing
> the https://openbsdstore.com links to http://openbsdstore.com, and
> running sslstrip on that. Or the PayPal links...

For real!  And yet another attack currently possible against
www.openbsd.org is being able to view the web-site from any OpenBSD
release, even the early ones that did include lynx in base
(http://mdoc.su/OpenBSD-2.3/lynx.1), yet are surely missing not only
TLSv1.2 (if not OpenSSL in the first place!), but the requisite CA
entries in their corresponding cert.pem file as well (that is, if such
file was even present).

And if you're in Kazakhstan, it's also possible to view
www.openbsd.org without any issues or security warnings, and will
continue being so even after 2016-01-01 when the new telecommunication
directive takes force.  (Or was the feature to ignore invalid
certificates already added to lynx nowadays?)

And another one is a global web-site defacing if the certificate
signing request infrastructure, with a client that is designed to run
on your web-server with the web-server privileges by LetsEncrypt, and
must execute at least once every 3 months (if not more often, as their
plan is to decrease cert validity to be even shorter than 3 months)
turns out to contain an exploitable vulnerability.  Wait, that's one
not possible!  (At least not yet!)

C.

OpenBSD.org gets SANCTIONED .RU

[Constantine A. Murenin]

Dear misc and advocacy,

It has come to my attention that OpenBSD.org has been sanctioned today.

It has been sanctioned in the category of best desktop OS.

Some other sites sanctioned together with OpenBSD.org are 
FreeBSD.org for serving, 
NetBSD.org for powering toasters and 
nginx.org for an engine with an X (not sure what that means, anyone?).


http://We.Are.Sanctioned.RU/

Everyone, thanks for all the fish, and keep up the good work!

And feel free to nominate other web-sites with #SanctionedRU.  
I'm thinking perhaps lobste.rs is next!


Cheers,
Constantine.

Re: Please help advertise DigitalOcean on OpenBSD Misc (again)

[Constantine A. Murenin]

On 20 January 2015 at 18:12, Steve Shockley  wrote:
> On 1/19/2015 9:06 AM, openda...@hushmail.com wrote:
>>
>> So please stop by and give us your upvotes.
>
>
> So, is this advertising or SEO?

DigitalOcean is a shady provider with a lack of documentation, who
doesn't even give you IPv6 address space across their fleet, or in
those few locations they do, they do it in violation of all known RFCs
and the best practices -- I've heard a rumour that they only give out
16 IPv6 addresses.  Why a rumour?  Because, as already mentioned, they
completely lack the documentation!

I don't know why you would want to run OpenBSD on it.  If you're just
in it for the "OpenBSD" part, just go with real hardware like
online.net -- they start at 5,99 EUR/mo, there's not much reason to
have to rent a virtual server if dedi is that cheap.

Lots of other dedi options at http://lowendcore.com/.

With dedi prices that low, virtual hosting for OpenBSD is kinda dead, IMHO.

C.

Re: OpenBSD projects

[Constantine A. Murenin]

On 27 December 2014 at 16:32, Predrag Punosevac  wrote:
> OpenBSD has its own sensorsd which is pure gold and unlike other BSDs

Yes, and sensorsd(8) / sensor_attach(9) stuff has also been imported
into DragonFly BSD (and also briefly into FreeBSD, too).

http://mdoc.su/d/sensor_attach.9

http://BXR.SU/DragonFly/search?q=sensor_attach

Plus pretty much more than half of the wireless device drivers
available all across BSDs (and even OpenSolaris, RIP) have originated
in OpenBSD:


http://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers#OpenBSD

http://bxr.su/f,n,d/s?q=%22Damien+Bergamini%22+OR+damien@openbsd

Lots of misc stuff from OpenBSD in the other 3 BSDs, too:

http://bxr.su/f,n,d/search?q=$OpenBSD+OR+openbsd.org

C.

Re: NSA spy catalog (was: Re: apologies for the noise (interesting article)!)

[Constantine A. Murenin]

On 1 January 2014 08:13, Christian Weisgerber  wrote:
> mufurcz  wrote:
>
>> http://www.itnews.com.au/News/368564,server-vendors-named-in-nsa-spying-toolkit.aspx
>
> That's just a summary article about Applebaum's 30C3 talk.  I don't

Yes, might just go to it directly:

http://www.youtube.com/watch?v=b0w36GAyZIA

> know if any part of the English-language press has picked up on
> this in equivalent detail, but Der Spiegel has published part of
> the NSA's actual 2008 spy gear catalog that makes for interesting
> reading, including such tidbits as unit cost and development status:
>
> http://www.spiegel.de/netzwelt/netzpolitik/interaktive-grafik-hier-sitzen-die-spaeh-werkzeuge-der-nsa-a-941030.html
>
> Just click on the marked spots on the image map to pop up individual
> galleries.  Don't miss the right part of the map.  You can ignore
> the German text, which is just explanations for people who don't
> know computers or English.

There's an English version of this Interactive Graphic page, too:

http://www.spiegel.de/international/world/a-941262.html

Also, a complete set of all the pages from the alleged catalogue is
available on a single page, via
http://mailman.nanog.org/pipermail/nanog/2013-December/063182.html:


http://leaksource.wordpress.com/2013/12/30/nsas-ant-division-catalog-of-exploits-for-nearly-every-major-software-hardware-firmware/

C.

Re: 5.4 on a ThinkPad 760EL

[Constantine A. Murenin]

On 22 December 2013 14:45, Chris Bee  wrote:
> On Sun, Dec 22, 2013 at 06:40:28PM +, Miod Vallat wrote:
>> > I'm trying to install 5.4 on an old ThinkPad 760EL and running into some
>> > trouble, probably due to how little RAM it has - 16 MB.
>> [...]
>> > I have read INSTALL.i386 and
>> > it says that I need at least 32 MB of RAM for 5.4.
>> [...]
>> >   Apologies if there is something obvious I should be doing.
>>
>> The obvious thing you should do is to add more memory to this system.
>> The 5.4 i386 GENERIC kernel is huge and eats more than half the physical
>> memory, and then the data structures it creates aren't free. There is
>> basically no free memory for userland to run, and your system is
>> swap-bound, hence horribly slow, as you have noticed.
>>
>> Your available options are:
>> - run an old release, which fits in 16MB. I doubt anything >= 4.5 will
>>   fit in 16MB, so you'd use a 5+ years old, unsupported, release.
>> - build a stripped-down kernel on another 5.4 system and run it on your
>>   ThinkPad. This ought to work, but your kernel will not be supported,
>>   so if it breaks, you get to keep both pieces.
>> - add more memory to your system. Really. It will help. Can't you see
>>   your laptop looking at you with puppy dog eyes?
>> - get a beefier laptop. Anything with more memory will do.
>>
>> Miod
>
> I have installed 4.0 and while it does work, even such an old release is
> barely usable. I'm not too keen on the idea of using such unsupported,
> possibly unstable software on my laptop, anyway. I suppose the only
> option is to buy a newer laptop, like you said. There are plenty of good
> suggestions floating around, most of which can be had for tens of
> dollars on eBay. OpenBSD is getting so bloated these days, it requires
> so much RAM :)

There's an old tool called `dmassage` (in ports since 3.9) that may
offer some help in building a smaller kernel for your situation.

http://ports.su/sysutils/dmassage

Cheers,
Constantine.

Re: Patch to remove "adult" content from spamd(8) man page

[Constantine A. Murenin]

On 22 November 2013 10:06, J. Lewis Muir  wrote:
> On 11/22/13 11:17 AM, Giancarlo Razzolini wrote:
>> If it's offensive for you, compile your own spamd man page with
>> the diff you so happily provided, and live the rest of your life
>> happy. Remember to always take this pill again on 1st of May, and 1st
>> of November, every year.
>
> Hi, Giancarlo.
>
> Well, no one wants to maintain a patch forever.  I'd maintain it for a
> while if there was a good chance it would get accepted at some point,
> but if there's no chance, then I wouldn't bother.
>
> I'm a little puzzled over the whole resistance to the patch.  If I
> wrote a man page for some software I wrote, and if an example in it was
> considered off-color by someone, and that someone submitted a patch to
> me to change it slightly to no longer be off-color to them, and they
> asked in a kind way, and the patch didn't hurt the clarity of the man
> page in any way, I would likely accept the patch.  How am I hurt by it?
> I may not agree with the person, but why would I insist on keeping an
> example that seems off-color to them?  If it's somehow offensive to them
> and can be changed in a small way not to be, then I would accept the
> patch to change it.  Everybody wins--no big deal.
>
> Lewis

Yet, (0), you're not the one who wrote this software, or, in fact, any
other *BSD software that I could find, so I'm not sure you're
empirically qualified to make the claim about authorship that you're
now making, and, (1), what makes you think that your patch doesn't
hurt the clarity of the man-page in any way?

C.

Re: Is Soekris OpenBSD friendly?

[Constantine A. Murenin]

On 15 November 2013 16:03, SmithS  wrote:
> Greetings misc@.  After coming across a link[1] to make an OpenBSD
> router using a "Soekris" device, I think I will make one.  Does anyone
> else have this hardware and can verify all the components work?
> I think Intel NICs are good, but everything else?  I have never heard
> of this brand before so I want to be safe before buying.  The model
> number[2] is "6501-30"
>
> [1] http://www.bsdnow.tv/tutorials/openbsd-router
> [2] https://soekris.com/products/net6501/net6501-30-board-case.html
>
> greetz,
> SmithS

Soekris has been used with OpenBSD for a very long time throughout
many releases, so, if you like what you see, that's exactly what
you're going to get.  Their brand is actually very well known.

However, their hardware is not particularly competitive in the price
department, and, incidentally, is also quite known for being an
excellent tool to fine-tune overall OpenBSD performance under very
stressful network scenarios, which don't take much effort to generate
(especially on their pre-GigE hardware, but a 600MHz Atom is probably
not that much different).

If you only need two NICs, there are many alternatives that are priced
considerably lower than Soekris, and provide a better value; some are
still fanless and already have two GigE NICs on board.

The "net6501-30-board-case" above, w/ 600 MHz Intel Atom and soldered
0.5GB of DDR2 RAM, is 310 USD, plus "psu-12v-3-0a-world" is 20 USD
extra, for a total of 330 USD + tax/shipping/handling.  Plus you'll
need some storage device.

A quick search today reveals Shuttle DS47 -- fanless, dual GigE, two
COM ports, lots of USB 3.0, accepts up to 16GB of DDR3, probably
supported by the latest OpenBSD release, especially if you only need
it for a router (might have to use 5.4-current due to
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/re.c#rev1.145).
220 USD, with a choice of multiple retailers to buy from, plus a
little extra for a lot more DDR3 than the soldered 0.5GB of the
Soekris.

http://global.shuttle.com/main/productsDetail?productId=1718
http://www.newegg.com/Product/Product.aspx?Item=N82E16856101145

http://www.amazon.com/SHUTTLE-DS47-Celeron-1-1GHz-Barebone/dp/B00DK06L6O?keywords=%222x+RJ45%22+barebone

Foxconn also makes nice barebones -- they're even cheaper than Shuttle.

However, if you don't require solid GigE performance, and are looking
for just 100Mbps routing throughput for a home-router project, my
advice is to buy a netbook -- they go for 200 to 250 USD nowadays,
plus an external USB Gigabit Ethernet adapter is 10 to 20 USD.  Most
cheap USB Ethernet adapters are supported nowadays, especially on
OpenBSD.

With a netbook-based OpenBSD router, you'll have a complementary UPS,
plus a diagnostic display w/ keyboard (alas with no serial), plus a
fast SSD or HDD that's also included.  And the price is the same as,
or even lower than, any of the alternatives that would not have any
such features.

You really can't beat the value by going with a netbook, unless you do
require 4x 1Gbps, x2, which you aren't going to get with a 600MHz
Atom-based Soekris, either.

C.

Re: Does softraid RAID1 evenly distribute the read load?

[Constantine A. Murenin]

On 7 November 2013 03:56, Federico Giannici  wrote:
> For a decision I have to do, I have to know if the RAID1 implementation in
> softraid evenly distributes the "read" load through all the disks.

Yes, it does exactly that.

Take a look yourself:

http://bxr.su/o/dev/softraid_raid1.c#sr_raid1_rw


> So, for example: with a two identical disks RAID1 implementation, can we
> roughly assume that write speed is almost the same speed of a single disk
> while the read speed is almost the double?

With RAID1, write speed would be the speed of the slowest disc.  If
you have many discs, even if they're supposedly identical, you might
want to individually test their speeds, and make sure to create
separate RAID1 arrays that group discs of the same performance tiers
together, to get higher overall performance from the system.

Random access read capacity should indeed be roughly the sum of the
average of all discs, yes.  I understand that OpenBSD's softraid raid1
differs from other softraid solutions, where others frequently use
only one disc for sequential reads from a single thread or so; OpenBSD
always interleaves reads, evenly distributing «the "read" load through
all the disks», exactly as you seem to require.

> I know that reality is not so simple, but it's only to have an "ideal"
> situation to understand the working of the system.

Only way is to look at the code! :-)

C.

Re: DNS Hosting & Managed DNS

[Constantine A. Murenin]

On 24 October 2013 07:35, Predrag Punosevac  wrote:
> Hi Misc,
>
> This is not an OpenBSD specific question but since the list is full of
> security and network professionals I would like to solicit your
> opinion.
>
> Are there any strong opinions on DNS Hosting & Managed DNS providers. We
> are small Lab currently using ZoneEdit. I believe ZoneEdit  was chosen
> at the time they were free. We are looking to move to something little
> bit more secure with DNSSEC support out of box. We have one domain name,
> small web server and a mail server.

Do you run it all out of a single network?

If so, then running a third-party DNS is not recommended:
http://cr.yp.to/djbdns/third-party.html

OTOH, named and nsd in base work great.

BTW, if you start adding DNS servers in far away places around the
world, and with bad connectivity from your target audience, then the
time it takes to resolve your domain for your target audience will
suffer overall, not improve.

Yes, these ideas are basically exactly the opposite of what the
marketing would lead you to believe.

C.

announcing mdoc.su, short manual page URLs

[Constantine A. Murenin]

Dear misc, www,

I would like to announce and introduce http://mdoc.su/>, 
a deterministic URL shortener for BSD manual pages, 
written entirely in nginx.conf.


It supports several addressing schemes, for example:

 http://mdoc.su/o/pf
 http://mdoc.su/o/pf.4
 http://mdoc.su/o/4/pf
 http://mdoc.su/openbsd/pf
 http://mdoc.su/OpenBSD/pf

 http://mdoc.su/f/pf
 http://mdoc.su/n/pf
 http://mdoc.su/d/pf

 http://mdoc.su/o/sort.3p

 http://mdoc.su/o/intro.4.macppc
 http://mdoc.su/openbsd/macppc/4/intro

Source code for the whole mdoc.su.nginx.conf is available at:

 https://github.com/cnst/mdoc.su
 https://bitbucket.org/cnst/mdoc.su

Specifically, the following currently controls OpenBSD rewriting:

location /OpenBSD { rewrite ^/OpenBSD(/.*)?$/o$1;   }
location /o {
set $ob "http://www.openbsd.org/cgi-bin/man.cgi?query=";;
set $os "&sektion=";
rewrite ^/openbsd(/.*)?$/.$1;
rewrite ^/./([a-z]+[0-9]*[k]?)/([1-9]|3p)/([^/]+)$  
$ob$3$os$2&arch=$1  redirect;
rewrite ^/./([^/.]+)/([^/]+)$   $ob$2$os$1  
redirect;
rewrite ^/./([^/]+)\.([1-9]|3p)\.([a-z]+[0-9]*[k]?)$
$ob$1$os$2&arch=$3  redirect;
rewrite ^/./([^/]+)\.([1-9]|3p)$$ob$1$os$2  
redirect;
rewrite ^/./([^/]+)$$ob$1$os
redirect;
rewrite ^/./?$  /   last;
return  404;
}

Translation: "/OpenBSD" and "/openbsd" get rewritten to "/o" internally, 
without any extra replies to the user, and then the rest of the URI is 
analysed, and a "302 Found" redirect is finally issued to the user.  
(If you haven't yet noticed nginx in the base tree, here's your chance!)


Pages like http://mdoc.su/o/ redirect to the main "/" page internally, 
without affecting the URL that's visible to the user, making it easier 
to keep a starting page specifically for one BSD.


Questions, comments and suggestions are welcome.  
Available through IPv4 and IPv6.  
Enjoy!


Cheers,
Constantine.

mfs / mount_mfs(8) memory usage never shrinks?

[Constantine A. Murenin]

Hello misc@,

On OpenBSD 5.2 amd64, I'm storing 1.4GB of source code files and about
8x 150MB indices on an mfs partition, plus a gig or two of other
automatically-generated files.

If I run mount_mfs to load all this stuff from a regular drive, then
the amount of memory used by mount_mfs(8) is about the same as the
amount of Used disc space as reported by df(1).

However, if I re-run index generation on an mfs, then after it's all
done, memory usage by mount_mfs(8) noticeably exceeds Used disc space.
 As a workaround, I found that it's possible to copy all the files
over to a new mount_mfs(8) process, after the indices have been
re-generated, and the new process will at first have a much better
memory usage, but this seems a little inconvenient and would also
require a temporary burst of extra RAM to accomplish.

Should I worry that on a 6GB partition that is only 4GB full,
mount_mfs uses 5GB of memory after about 3GB of data gets mingled?  Is
mount_mfs swappable?  If I end up being short on memory, would that
extra 1GB from mount_mfs(8) be swapped out without affecting the
performance?  Or is there a way to run some kind of garbage collector
or otherwise improve on an mfs memory use?

% df -hi | fgrep -e Used -e mfs ; mount | fgrep mfs ; ps aux | fgrep
-e USER -e mfs
Filesystem SizeUsed   Avail Capacity iused   ifree  %iused  Mounted on
mfs:18610  5.9G4.1G1.5G73%  439864  35770255%   /grok/mfs
mfs:18610 on /grok/mfs type mfs (asynchronous, local, nodev, nosuid,
size=12582912 512-blocks)
USER   PID %CPU %MEM   VSZ   RSS TT  STAT  STARTED   TIME COMMAND
root 18610  0.0 40.2 6291936 5048352 ??  IsSun07PM0:22.56
/sbin/mount_mfs -o rw -s6G -f2048


Cheers,
Constantine.

Re: Unused swap

[Constantine A. Murenin]

http://www.openbsd.org/cgi-bin/cvsweb/src/etc/login.conf.in
http://www.openbsd.org/cgi-bin/cvsweb/src/etc/mklogin.conf
http://www.openbsd.org/cgi-bin/man.cgi?query=login.conf&sektion=5

plus, last i checked, firefox was not even 64-bit friendly anyways

C.

On 11 January 2013 15:28, Lars von den Driesch
 wrote:
> Hi
> I just discovered another strangeness on my installation. Firefox
> keeps seg-faulting on me when I have a lot of tabs open with webpages
> that draw a lot of memory. This is easy to reproduce - I just open
> engadget.com more often and open subsites by clicking randomly on that
> page.
> When I start firefox from xterm it gives me an "out of memory" error
> after a while and writes a core file to disk. This led me looking to
> my swap partition when I discovered that swap seems to be unused on
> this system although it exists and the system seems to know about it.
> It just isn't filled when needed.
> This is a snapshot on amd64 from 7 Jan. The partitions  were created
> during initial install. So this might have been a problem from the
> beginning but I discovered it now because I am using the system more
> often lately.
> I have found an ancient bugreport from 1999 for sparc/1007 reporting
> exactly this but this is basically the only thing I found about this
> topic. So I believe I am missing something obvious again that only me
> would be able to fall over ;-)
>
> Thanks
> Lars
>
> -swapctl -l this display never changes
> Device  512-blocks UsedAvail Capacity  Priority
> /dev/sd0b  93740810  9374081 0%0
>
>
> -systat swap gives me this but this display never ever changes
> 5 usersLoad 0.13 0.16 0.47 Sat Jan 12 00:03:07 2013
> DISK 512-blocks   USED  10\ 20\ 30\
> 40\ 50\ 60\ 70\ 80\ 90\100\
> sd0b9374081  0
>
> -disklabel /dev/sd0c
> #size   offset  fstype [fsize bsize  cpg]
>   a:615763200   64  4.2BSD   4096 327681 # /
>   b:  9374081615763264swap   # none
>
> -fstab
> c6dfab3c9cca1a9c.b none swap sw
> c6dfab3c9cca1a9c.a / ffs rw 1 1
>
> -dmesg
> OpenBSD 5.2-current (GENERIC.MP) #12: Mon Jan  7 07:59:56 MST 2013
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4157472768 (3964MB)
> avail mem = 4024295424 (3837MB)
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (57 entries)
> bios0: vendor Award Software International, Inc. version "F11" date 09/16/2009
> bios0: Gigabyte Technology Co., Ltd. GA-MA78GM-S2H
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT HPET MCFG APIC
> acpi0: wakeup devices USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3)
> USB5(S3) USB6(S3) SBAZ(S4) P2P_(S5) PCE2(S4) PCE3(S4) PCE4(S4)
> PCE5(S4) PCE6(S4) PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4)
> PS2M(S5) PS2K(S5) PCI0(S5)
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpihpet0 at acpi0: 14318180 Hz
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD Athlon(tm) Dual Core Processor 4850e, 2511.77 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
> 64b/line 16-way L2 cache
> cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu0: apic clock running at 200MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD Athlon(tm) Dual Core Processor 4850e, 2511.44 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
> cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
> 64b/line 16-way L2 cache
> cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
> ioapic0: misconfigured as apic 0, remapped to apid 2
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 3 (P2P_)
> acpiprt2 at acpi0: bus -1 (PCE2)
> acpiprt3 at acpi0: bus -1 (PCE3)
> acpiprt4 at acpi0: bus -1 (PCE4)
> acpiprt5 at acpi0: bus -1 (PCE5)
> acpiprt6 at acpi0: bus -1 (PCE6)
> acpiprt7 at acpi0: bus -1 (PCE7)
> acpiprt8 at acpi0: bus -1 (PCE9)
> acpiprt9 at acpi0: bus 2 (PCEA)
> acpiprt10 at acpi0: bus -1 (PCEB)
> acpiprt11 at acpi0: bus -1 (PCEC)
> acpiprt12 at acpi0: bus 1 (AGP_)
> acpicpu0 at acpi0: PSS
> acpicpu1 at acpi0: PSS
> acpibtn0 at acpi0: PWRB
> cpu0: PowerNow! K8 2511 MHz: speeds: 2500

Re: qemu -nographic

[Constantine A. Murenin]

On 11 January 2011 11:18,   wrote:
> The trick with /etc/boot.conf does work; this should transform the
> cd48.iso install cd into a 'serial' one:
>
> $ echo 'set tty com0' > /tmp/boot.conf
> $ growisofs -M cd48.iso -l -graft-points /etc/boot.conf=/tmp/boot.conf
>
> Then:
> $ qemu -nographic -cdrom cd48.iso
>>> OpenBSD/i386 CDBOOT 3.15
> boot>
> booting cd0a:/4.8/i386/bsd.rd: 5900404

I've tried this on a Linux, and it worked for getting OpenBSD
installer to boot through a serial console.

However, I was using install52.iso, which includes the filesets, and I
was not able to install any filesets from a CD that was altered by
growisofs on Linux as above.  Looking at /mnt2 during the install,
I've noticed that all filenames were in CAPS, and "/mnt2/TRANS.TBL"
was missing (however, all appropriate "/mnt2/*/TRANS.TBL" and
"/mnt2/*/*/TRANS.TBL" were still present and correct).

I worked around by adding the original CD as a regular drive, and
selecting "disk" and "wd0" for installing the filesets.  The ISO
filesystem was mounted from wd0 automatically and with no problems or
hoops.

apt-get install  dvd+rw-tools
echo 'set tty com0' > boot.conf
cp -p install52.iso install52.iso.origFromFTP
growisofs -M install52.iso -l -graft-points /etc/boot.conf=boot.conf
kvm -m 6144 -smp 4 -drive file=/dev/sda,if=scsi \
-drive file=/dev/sdb,if=scsi -drive file=/dev/sdc,if=scsi \
-drive file=install52.iso.origFromFTP -cdrom install52.iso -boot d
-nographic

`dpkg --list` :
ii  dvd+rw-tools 7.1-6DVD+-RW/R tools
ii  qemu-kvm 0.12.5+dfsg-5+squeeze9   Full
virtualization on x86 hardware

Also, the version of qemu as above has another useful option that
allows you to bypass VNC and X -- "-curses".

Apparently, you must either choose "-nographic" and enable serial on
the media, or choose "-curses" and have VGA emulation with no usable
log of the session.  It'd be nice to have "-nographic" work with VGA
emulation, too, and not be a serial-only option.

C.

Re: OpenBSD Cloud Offerings

[Constantine A. Murenin]

On 27 November 2012 08:47, Research  wrote:
> Hello,
>
> I was wondering if anyone had any experience with reputable cloud providers 
> that currently offer OpenBSD 5.2.
>
> I was able to find out some information based on the OpenBSD Journal posting 
> from Sunday, February 13, 2011 titled "OpenBSD Private Cloud Computing".  The 
> two vendors mentioned included ARP Networks and RootBSD.
>
> Since this time period (preferably over 2012), has anyone used any other 
> cloud service offerings hosting OpenBSD ?  I am hoping to hear some positive 
> reviews for a provider I can go with.
>
> Stipulations
>
> - Preferable a North American provider for geography
> - OpenBSD 5.2
>
> Thanks

To run OpenBSD in the cloud, you can go with pretty much any provider
that offers VPS solutions based on Linux-KVM, Xen HVM or VMware --
with all of these three technologies, you can run the regular
unmodified i386 and amd64 kernels.  Avoid Xen PV (it requires guest OS
to be modified to specifically support Xen, i.e. a DomU kernel etc),
and, obviously, also avoid OpenVZ, VDSmanager-FreeBSD etc.

Don't necessarily look at the OpenBSD version numbers that are
offered, or whether OpenBSD is specifically supported; at least with
KVM and Xen HVM, it's almost always possible to get console-based
access and install whichever version of OpenBSD you please.  Some
providers offer ssh-based serial console access; some offer VNC-based
access; installing OpenBSD yourself is a breeze!

For "reputable" providers with nodes in the US, arpnetworks.com,
vr.org, ramhost.us, nqhost.com and edis.at are just some of the
options to consider; and, before you ask, linode.com won't work (it's
strictly Xen PV, which would require a modified Xen DomU kernel from
your Guest OS).  IMHO, RootBSD.net pricing is always out of line from
the realm of the market.

If you're looking for something extra cheap and not necessarily one
bit reliable/secure/dependable, then you might also find some other
interesting offers from come-and-go providers at sites like
LowEndBox.com (they have tags for KVM and VMware, plus most "Xen"
providers over there either already offer Xen HVM or are flexible
enough to provide either Xen PV or Xen HVM).

Cheers,
Constantine.

Re: spammers getting less stupid?

[Constantine A. Murenin]

On 1 November 2012 12:49, Jan Stary  wrote:
> Here is a typical host:
> WHITE|2.139.201.210|||1351517497|1351518564|1354630766|2|1
> which is 210.red-2-139-201.staticip.rima-tde.net.
> It tried to connect at Mon Oct 29 14:31:37 CET 2012,
> and got WHITE at Mon Oct 29 14:49:24 CET 2012.
>
> It is obviously a spammer:
>
>  Oct 29 15:19:26 biblio smtpd[26924]: b4f049e1: from=<@>,
>  relay=210.red-2-139-201.staticip.rima-tde.net [2.139.201.210],
>  stat=LocalError (530 5.0.0 Recipient rejected: 7e8a5...@stare.cz)
>
> Strangely, the only occurence of 2.139.201.210 in the last month's
> maillog is just this; that's half an hour after it got WHITE.
> What happend at Mon Oct 29 14:49:24 CET 2012 that made it WHITE?

The spammer must have successfully passed the greylisting with spamd
on Mon Oct 29 14:49:24 CET 2012.

The spamd setup requires at least two connections to spamd, prior to
the connections being permitted to the real smtp server.

This is different from the MTA-based greylisting, where mail can be
delivered as soon as the second attempt.  With spamd, at least three
attempts are required for the initial delivery of mail, since spamd
cannot hand-over an existing connection to the real smtp server when
the greylisting requirements are satisfied.

C.

Re: Why anyone in their right mind would like to use NAT64

[Constantine A. Murenin]

Daniel,

I think you're confused between NAT66 and NAT64. [0]

T-Mobile USA optionally supports IPv6 connectivity in some limited
number of new phones (Galaxy Nexus etc) [1], and when the IPv6 option
is manually activated by the user^w beta-tester on their phone, then
no IPv4 support is provided, and access to IPv4-only resources is
available through NAT64 [2] and DNS64 [3].  No dual-stacking is
provided; in their slides from [0], T-Mobile USA claims that IPv6-only
with NAT64/DNS64 is cheaper than dual-stack with NAT44.

Frankly, dual-stacking (with the plain old NAT44) would seem like a
better approach for an end-user; I would guesstimate that less than 1%
of Galaxy Nexus users on T-Mobile USA have actually enabled IPv6 (and
left it enabled after simply testing it), precisely because
dual-stacking is not an option, and T-Mo's NAT64/DNS64 must be
consumed (instead of NAT44), breaking all those crappy apps that
hardcode IPv4 addresses outside of the DNS and such.

C.

[0] https://sites.google.com/site/ipv6implementors/2010/agenda
[1] https://sites.google.com/site/tmoipv6/lg-mytouch
[2] http://tools.ietf.org/html/rfc6146
[3] http://tools.ietf.org/html/rfc6147

On 24 October 2012 09:43, Daniel Ouellet  wrote:
> Hi,
>
> Just saw a few questions and patch for NAT64 on misc and tech@ and I am
> really questioning the reason to be fore NAT64 and why anyone in their right
> mind would actually want to use this?
>
> NAT always makes connectivity less efficient anyway and was really designed
> to alleviated the lack of IPv4 address years ago and was sadly used as a
> firewall setup by what I would call lazy admin instead if a properly
> configure one.
>
> Call me stupid and I will accept it, but regardless of this why?
>
> NAT was sadly a quick way to setup security and over time become even more
> sadly what some security suppose to be expect call the defacto way to do
> security.
>
> NAT needs to process every packets, changed the header both in incoming and
> outgoing traffic and as bandwidth keep increasing only make the totally not
> optimize NAT table getting bigger as more traffic is present and increase
> jitter, latency, etc. Much more powerful router needs to be used and many of
> the sadly loved firewall appliance by some admin like the SonicWall and the
> like running out of power on intensive UDP traffic and do not allow the end
> users to actually get the benefit of their increase line capacity that are
> more common these days!
>
> There is even more then this above, but I will spare the list with more as
> my question is really why NAT64?
>
> IN IPv6, the smallest assigned to remote site is so big anyway and based on
> the RFC recommendation to provide a /48 to remote site and even a /56 to a
> single house, how could anyone possibly think he/she would even run of IP's
> and need NAT64?
>
> Isn't it just a side effect of a sadly miss guided use of NAT in IPv4 as a
> firewall carry over to a IPv6 world instead of starting to do proper setup
> now that IP's will be plentiful anyway?
>
> Anyone have any possible explication that would actually justify the use of
> NAT64 that I obviously overlooked?
>
> Why us it other then for lazy firewall setup these day?
>
> I would appreciate a different point of view that I obviously appear to have
> overlooked as I really don't see why it even exists.
>
> Best,
>
> Daniel

Re: Does cvsync let ancient patches escape from the attic?

[Constantine A. Murenin]

On 09/02/2012, Brett  wrote:
>> > Somehow patch-apps_unix_ximage_c has gotten in there, even though
>> > (according to
>> > http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/Attic/
>> > ) it was moved to the attic over 2 years ago.
>>
>> $ cvs status patch-apps_unix_ximage_c
>>
>> see if there is sticky tag there. If so, then do:
>>
>> $ cvs up -dPA
>>
>> --patrick
>>
>
> # cvs -d/usr/cvsync status
> /usr/ports/textproc/mupdf/patches/patch-apps_unix_ximage_c
> ===
> File: patch-apps_unix_ximage_c  Status: Up-to-date
>
>Working revision:1.1 Fri Feb 10 00:17:20 2012
>Repository revision: 1.1
> /usr/cvsync/ports/textproc/mupdf/patches/patch-apps_unix_ximage_c,v
>Sticky Tag:  (none)
>Sticky Date: (none)
>Sticky Options:  (none)
>
> I ran the $ cvs up -dPA command anyway but patch-apps_unix_ximage_c did not
> return to the attic.
>
> The hostname in my cvsync config file is cvsync.allbsd.org if that would
> make any difference.
>
> Brett.

Looks like cvsync.allbsd.org is in trouble -- patch-apps_unix_ximage_c
is present both outside Attic at rev1.1, and within Attic at rev1.2.

http://cvsweb.allbsd.org/cvsweb.cgi/ports/textproc/mupdf/patches/?cvsroot=openbsd
http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/

Perhaps Hiroki can clarify how this could have happened.

C.

Re: DST cancellation for Russia

[Constantine A. Murenin]

On 30 October 2011 02:39, Dmitry Tigrov  wrote:
> Russia has cancelled the move to DST for 2011.
> Is cancellation DST for Russia added to 5.0 version? Is any patch to
> cancellation for 4.9 version?

http://www.openbsd.org/cgi-bin/cvsweb/src/share/zoneinfo/datfiles/europe#rev1.42

A total mess, if you ask me.  Whilst the DST riddance (or, well, a
permanent DST) is a welcome move, the way in which it is done is quite
absurd.  And due to the momentum, and, perhaps, the implicit
inconvenience to the neighbour states, Belarus and Ukraine also
decided to abandon DST, even giving a correspondingly shorter notice!
Blah.

C.

Re: Bad behavior of sensorsd on laptop

[Constantine A. Murenin]

On 6 March 2010 08:26, Tomas Bodzar  wrote:
> Hi all,
>
> I set sensorsd and sensorsd.conf this way :
>
> # $OpenBSD: sensorsd.conf,v 1.8 2007/08/14 19:02:02 cnst Exp $
>
> #
> # Sample sensorsd.conf file. See sensorsd.conf(5) for details.
> #
>
> # +5 voltage (volts)
> #hw.sensors.lm0.volt3:low=4.8V:high=5.2V
>
> # +12 voltage (volts)
> #hw.sensors.lm0.volt4:low=11.5V:high=12.5V
>
> # Monitor laptop battery for remaining capacity
> hw.sensors.acpibat0.watthour3:low=1.40Wh:command=/etc/sensorsd/switchoff
>
> # Chipset temperature (degrees Celsius)
> #hw.sensors.lm0.temp0:high=50C
> hw.sensors.acpitz0.temp0:high=60C:command=/etc/sensorsd/switchoff
> hw.sensors.acpitz1.temp0:high=60C:command=/etc/sensorsd/switchoff
>
> # CPU temperature (degrees Celsius)
> #hw.sensors.lm0.temp1:high=60C
> hw.sensors.cpu0.temp0:high=65C:command=/etc/sensorsd/switchoff
>
> # CPU fan (RPM)
> #hw.sensors.lm0.fan1:low=3000
> hw.sensors.acpithinkpad0.fan0:low=2500:command=/etc/sensorsd/switchoff
>
> # ignore certain indicators on ipmi(4)
> #hw.sensors.ipmi0.indicator1:istatus
>
> # Warn if any temperature sensor is over 70 degC.
> # This entry will match only those temperature sensors
> # that don't have their own entry.
> #temp:high=70C
>
>
> # By default, sensorsd(8) reports status changes of all sensors that
> # keep their state. Uncomment the following lines if you want to
> # suppress reports about status changes of specific sensor types.
>
> #temp:istatus
> #fan:istatus
> #volt:istatus
> #acvolt:istatus
> #resistance:istatus
> #power:istatus
> #current:istatus
> #watthour:istatus
> #amphour:istatus
> #indicator:istatus
> #raw:istatus
> #percentage:istatus
> #illuminance:istatus
> #drive:istatus
> #timedelta:istatus
>
> Command is simple :
>
> #!/bin/sh
> shutdown -h now "Shutdown caused by sensor"
>
> It's running from point of view that computer is turned off in case of
> low battery or high battery on some of sensor which has command
> assigned. Problem starts if your battery is empy and computer turned
> off. So you plug AC and start laptop. If you are below limit for
> hw.sensors.acpibat0.watthour3 then your laptop is turned off after
> login again. It's quite understandable, but if you're above limit
> behavior is still same. Is it problem this part from man page for
> sensorsd.conf?
>
>  If the limits are crossed or if the status provided by the driver
> changes, sensorsd(8)'s alert functionality is triggered and a command,
if
> specified, is executed.
>
> Battery status trough this sensor is changing because battery was
> empty and now laptop is in AC and charging. Does it really mean that
> it will turn off my computer after every change of battery status
> untill my battery is fully recharged?


core:constant {6432} man sensorsd.conf | fgrep -C5 shutdown
CAVEATS
 Alert functionality is triggered every time there is a change in sensor
 state; for example, when sensorsd(8) is started, the status of each
moni-
 tored sensor changes from undefined to whatever it is.  One must keep
 this in mind when using commands that may unconditionally perform
adverse
 actions (e.g. shutdown(8)), as they will be executed even when all sen-
 sors perform to specification.  If this is undesirable, then a wrapper
 shell script should be used instead.

OpenBSD 4.6 March 15, 2008
2
core:constant {6433}


Try using the %l token in your scripts for conditional shutdown.

C.

Re: make OpenBSD beep at start

[Constantine A. Murenin]

On 23/01/2010, joshua stein  wrote:
> > Can someone give a hin on how to make the speaker to beep for example with
>  > a command or a C program ?
>
>
> echo
>
>  (that's control+v, then control+g)

or

  /usr/bin/printf "\a"

or

  putchar('\a');

C.

lisa(4): accelerometer on HP 2133

[Constantine A. Murenin]

Hi, 

I'm looking for test reports of the lisa(4) driver.  Based on the dmesgs
I have found so far, it is expected to work on all HP 2133 Mini-Note PCs.

Also, I'm looking for dmesgs for HP 2140, and perhaps other HP laptops that 
feature HP 3D DriveGuard.  (It's not yet known if lisa(4) would support 2140.)
Please send the `dmesg`, `sysctl hw` and `acpidump` as text/plain to c...@.
If you can include dmesg before and after the patch, such that we can 
see the actual iic dump, so the better.

As always, your dmesgs in general are very welcome in dm...@openbsd.org, 
which forms a vital part of our quality assurance and development process.  
Please include the `sysctl hw` output, too -- we like to see the sensors. :)
Take note that if noone would have sent any dmesgs for HP 2133, then 
there wouldn't be a lisa(4) driver today, so thanks to everyone who 
contributed to the archives!

Anyhow, if you have "iic0: addr 0x1d 0f=3b" in your dmesg, followed by 
the rest of the iic dump, then the lisa(4) driver is expected to work, 
after you enable it in GENERIC:


Index: arch/amd64/conf/GENERIC
===
RCS file: /share/OpenBSD/cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.270
diff -u -d -p -4 -r1.270 GENERIC
--- arch/amd64/conf/GENERIC 23 Jul 2009 03:58:22 -  1.270
+++ arch/amd64/conf/GENERIC 12 Aug 2009 15:09:47 -
@@ -120,8 +120,9 @@ admcts* at iic? # Analog Devices ADM10
 admtmp*at iic? # Analog Devices ADM1030
 admtt* at iic? # Analog Devices ADM1031
 adt*   at iic? # Analog Devices ADT7460
 andl*  at iic? # Andigilog aSC7611
+lisa*  at iic? # STMicroelectronics LIS331DL motion sensor
 lm*at iic? # National Semiconductor LM78/79
 lmenv* at iic? # National Semiconductor LM87
 lmtemp*at iic? # National Semiconductor LM75/LM77
 lmn*   at iic? # National Semiconductor LM93
Index: arch/i386/conf/GENERIC
===
RCS file: /share/OpenBSD/cvs/src/sys/arch/i386/conf/GENERIC,v
retrieving revision 1.667
diff -u -d -p -4 -r1.667 GENERIC
--- arch/i386/conf/GENERIC  23 Jul 2009 03:58:22 -  1.667
+++ arch/i386/conf/GENERIC  12 Aug 2009 15:09:47 -
@@ -161,8 +161,9 @@ admcts* at iic? # Analog 
Devices ADM1
 admtm* at iic? # Analog Devices ADM1025
 admtmp*at iic? # Analog Devices ADM1030
 admtt* at iic? # Analog Devices ADM1031
 adt*   at iic? # Analog Devices ADT7460
+lisa*  at iic? # STMicroelectronics LIS331DL motion
 lm*at iic? # National Semiconductor LM78/79
 lmenv* at iic? # National Semiconductor LM87
 lmtemp*at iic? # National Semiconductor 
LM75/LM77
 lmn*   at iic? # National Semiconductor LM93


You can see how the sensors change with 
systat sensors 1
or 
sh -c "while(true)do sysctl -n hw.sensors.lisa0|xargs;sleep 1;done"
.  Please send the latter test, too. :)

Cheers,
Constantine.

Re: sensorsd strange tokens values

[Constantine A. Murenin]

On 27/07/2009, Federico Giannici  wrote:
> I'm using for the first time sensorsd to monitor RAID controller status and
> motherboard temperature. A script of mine is called that sends me an email.
> System is OpenBSD 4.4 amd64.
>
>  The problem is the value of the %2 %3 and %4 tokens passed as arguments to
> the command. I thought that they should be (in the same order): current
> temperature, low limit and high limit as set in the sensorsd.conf file.
>
>  Indeed here are the values I get:
>
>  %2: 46.00
>  %3: degC
>  %4: 9223372036581.62
>
>  The command I use is "command=/path/scriptname %x %n %l %2 %3 %4".
>
>  Is there some bug or I'm missing something?

%2 can never return "46.00" alone, what it must be returning is "46.00
degC".  Same goes for the rest of the tokens.

So perhaps the invocation of the script has to have some quotes around these.

C.

Re: Cannot Boot with Intel D201GLY Motherboard

[Constantine A. Murenin]

2009/7/5 Hendrickson, Kenneth :
>> However, the best option would be to simply acquire an
>> old beige box and install OpenBSD and back up the files
>> to another system on your network.
>
> Unfortunately, this seems to be my only option.  It is not good that
OpenBSD
> will not boot on the D201GLY motherboard.  :-(

You are using i386?  Have you tried amd64?  I have D201GLY2, and IIRC,
with OpenBSD 4.5, the i386 kernel seemed to have been resetting the
box right during the boot process, whereas the amd64 kernel worked
(and still works) without a single problem.

C.

Re: No man pages on new 5.0 install from CD?

[Constantine A. Murenin]

it doesn't make any sense to not include the man pages by default, of
course they are included in the default installation!

i honestly don't think the policy will change for 5.0, either. :)

C.

On 13/06/2009, Eric d'Alibut  wrote:
> On Sat, Jun 13, 2009 at 7:44 PM, Jeremy C. Reed wrote:
>
>  > B The minimal installation just selects a kernel (GENERIC
>  > B on most platforms), the base set, and the etc set.
>  > B Note that the minimal choice does not include manual pages.
>
>  Bingo. That was it.
>
>  I guess I don't thnk of man pages as non-minial! 
>
>  Thanks (and also those who responded off-list)
>
>  Good luck on the book!! I can't think of a better guy to write it.
>
>  Best,
>
>
>  --
>  No no no, my fish's name is Eric, Eric the fish. He's an halibut. I am
>  not a looney! Why should I be tarred with the epithet looney merely
>  because I have a pet halibut?
>
>


--
w. w. pUTIN O SOWER[ENSTWE, 24 DEKABRQ 2000 GODA: eSLI ^ELOWEKA WSE
USTRAIWAET, TO ON POLNYJ IDIOT. zDOROWOGO ^ELOWEKA W NORMALXNOJ PAMQTI
NE MOVET WSEGDA I WS# USTRAIWATX.

Re: Lost my Sensors (or should be senses!) with 4.2

[Constantine A. Murenin]

fixed, lm87.c#rev1.20. :)

The bug was caused by an ininitialised value, such that fan sensors in
certain chips (lm81, adm9240 and ds1780) might have pseudo-randomly
never appeared. Just to make it clear -- this was not a regression in
4.2, the fact that it was missing from 4.2 is simply a pseudo-random
occurrence. :)

In any case, the bug should be gone for good, thanks to LLVM/Clang
Static Analyser.

br,
cnst.su.

On 09/11/2007, Simon Slaytor <[EMAIL PROTECTED]> wrote:
> Hi Folks,
>
>  I've just been upgrading some of our old war horses (Nokia IP440) to 4.2.
> They run Intel made BX PIII chipset motherboards, dmesg below.
>
>  Whilst not extensive the boards do have some sensor data that we grab to
> check on the health of the old girls. After a fresh install of 4.2 I noticed
> we had lost the FAN readout from the list of sensors, see output below
> (taken from different boxes but I've confirmed the loss using the same box
> switching between 4.1 and 4.2).
>
>  Whilst this isn't critical for us on these units whatever is causing the
> omission may have bigger problems for other people so I thought I'd bring it
> to the lists attention.
>
>  Many thanks to all the developers for yet another excellence release in
> 4.2, the bulk CD order is going through soon!
>
>  Sensor Output from 4.1 i386 (sysctl -a hw)
>
>  hw.machine=i386
>  hw.model=Intel Pentium III ("GenuineIntel" 686-class)
>  hw.ncpu=1
>  hw.byteorder=1234
>  hw.physmem=267993088
>  hw.usermem=267988992
>  hw.pagesize=4096
>  hw.disknames=wd0,cd0,fd0
>  hw.diskcount=3
>  hw.sensors.lmenv0.temp1=23.00 degC (Internal)
>  *hw.sensors.lmenv0.fan0=2647 RPM *** MISSING ***
>  hw.sensors.lmenv0.fan1=3970 RPM * MISSING 
>  hw.sensors.lmenv0.volt0=1.52 VDC (+2.5Vin)
>  hw.sensors.lmenv0.volt1=1.66 VDC (Vccp)
>  hw.sensors.lmenv0.volt2=3.30 VDC (+Vcc)
>  hw.sensors.lmenv0.volt3=5.08 VDC (+5Vin/Vcc)
>  hw.sensors.lmenv0.volt4=12.38 VDC (+12Vin)
>  hw.sensors.lmenv0.volt5=2.43 VDC (Vccp)
>  hw.cpuspeed=599
>  hw.vendor=Intel Corporation
>  hw.product=SE440BX-2
>  hw.uuid=ebf758f0-b47b-11d4-af0d-0030d3006ea4
>
>  Sensor Output from 4.2 i386 (sysctl -a hw)
>
>  hw.machine=i386
>  hw.model=Intel Pentium III ("GenuineIntel" 686-class)
>  hw.ncpu=1
>  hw.byteorder=1234
>  hw.physmem=267993088
>  hw.usermem=267984896
>  hw.pagesize=4096
>  hw.disknames=wd0,cd0,fd0
>  hw.diskcount=3
>  hw.sensors.lmenv0.temp1=28.00 degC (Internal)
>  hw.sensors.lmenv0.volt0=1.50 VDC (+2.5Vin)
>  hw.sensors.lmenv0.volt1=1.69 VDC (Vccp)
>  hw.sensors.lmenv0.volt2=3.27 VDC (+Vcc)
>  hw.sensors.lmenv0.volt3=5.05 VDC (+5Vin/Vcc)
>  hw.sensors.lmenv0.volt4=12.00 VDC (+12Vin)
>  hw.sensors.lmenv0.volt5=2.40 VDC (Vccp)
>  hw.sensors.lmenv0.volt6=2.48 VDC (AIN1)
>  hw.sensors.lmenv0.volt7=1.66 VDC (AIN2)
>  hw.cpuspeed=599
>  hw.vendor=Intel Corporation
>  hw.product=SE440BX-2
>  hw.uuid=82947f19-b652-11d4-b074-0030d3001e5e
>
>  DMESG's
>
>  OpenBSD 4.1 (GENERIC) #1435: Sat Mar 10 19:07:45 MST 2007
>
> [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
>  cpu0: Intel Pentium III ("GenuineIntel" 686-class) 599 MHz
>  cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,SER,MMX,FXSR,SSE
>  real mem  = 267993088 (261712K)
>  avail mem = 236847104 (231296K)
>  using 3302 buffers containing 13524992 bytes (13208K) of memory
>  mainbus0 (root)
>  bios0 at mainbus0: AT/286+ BIOS, date 02/23/00, BIOS32 rev. 0 @ 0xfd7a0,
> SMBIOS rev. 2.1 @ 0xefbe0 (42 entries)
>  bios0: Intel Corporation SE440BX-2
>  pcibios0 at bios0: rev 2.1 @ 0xfd7a0/0x860
>  pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf30/176 (9 entries)
>  pcibios0: PCI Interrupt Router at 000:07:0 ("Intel 82371FB ISA" rev 0x00)
>  pcibios0: PCI bus #2 is the last bus
>  bios0: ROM list: 0xc/0x8000 0xe/0x4000! 0xe4000/0xc000
>  acpi at mainbus0 not configured
>  cpu0 at mainbus0
>  pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
>  pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x03
>  ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x03
>  pci1 at ppb0 bus 1
>  vga1 at pci1 dev 0 function 0 "ATI Mach64 GM" rev 0x27
>  wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
>  wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
>  pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x02
>  pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel
> 0 wired to compatibility, channel 1 wired to compatibility
>  wd0 at pciide0 channel 0 drive 0: 
>  wd0: 16-sector PIO, LBA, 19623MB, 40188960 sectors
>  wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
>  atapiscsi0 at pciide0 channel 1 drive 0
>  scsibus0 at atapiscsi0: 2 targets
>  cd0 at scsibus0 targ 0 lun 0:  SCSI0 5/cdrom removable
>  cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
>  uhci0 at pci0 dev 7 function 2 "Intel 82371AB USB" rev 0x01: irq 9
>  usb0 at uhci0: USB revision 1.0
>  uhub0 at usb0
>  uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1
>  uhub0: 2 port

Re: Random crashes with Intel D945GCLF2

[Constantine A. Murenin]

On 09/10/2008, SJP Lists <[EMAIL PROTECTED]> wrote:
> 2008/10/10 Damian Gerow <[EMAIL PROTECTED]>:
>
> > Mark Kettenis wrote:
>  >> Boy, those Intel-branded boards have shitty BIOSes...
>  >
>  > And support.  They've basically said that OpenBSD is not a supported OS, so
>  > they won't help me.  Neither do they support diagnostics from third-party
>  > programs or companies.
>  >
>  > I think I've learned my lesson here.
>
>
> I thought it odd being an Intel board not using an Intel NIC.  Not
>  really their board?

Have you seen the specifications for the D201GLY family? :)

C.

Re: Incorrect kate(4) tempatures

[Constantine A. Murenin]

The G revision chips don't provide correct readings for some reason.
It's interesting to note that only the last two K8 revisions, F and G,
are documented by AMD to have temperature sensors, however, most G
chips appear to report invalid data, whilst F chips and most
undocumented pre-F chips are working just fine.

br,
cnst.su.

On 07/08/2008, Wade, Daniel <[EMAIL PROTECTED]> wrote:
> The acpitz and lm readings look correct.  But the kate isn't even close.
>
>  hw.sensors.acpitz0.temp0=31.05 degC (zone temperature)
>  hw.sensors.kate0.temp0=-1.25 degC
>  hw.sensors.kate0.temp1=-8.00 degC
>  hw.sensors.kate0.temp2=0.25 degC
>  hw.sensors.kate0.temp3=7.50 degC
>  hw.sensors.lm1.temp0=35.00 degC
>  hw.sensors.lm1.temp1=31.50 degC
>  hw.sensors.lm1.temp2=41.00 degC
>
>  OpenBSD 4.4 (GENERIC.MP) #1808: Wed Aug  6 00:19:35 MDT 2008
> [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>  real mem = 2132963328 (2034MB)
>  avail mem = 2071121920 (1975MB)
>  mainbus0 at root
>  bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf (41 entries)
>  bios0: vendor Phoenix Technologies, LTD version "6.00 PG" date 11/19/2007
>  bios0: Unknow Unknow
>  acpi0 at bios0: rev 0
>  acpi0: tables DSDT FACP SSDT HPET MCFG APIC
>  acpi0: wakeup devices HUB0(S5) XVR0(S5) XVR1(S5) XVR2(S5) XVR3(S5) UAR1(S5)
>  USB0(S3) USB2(S3) AZAD(S5) MMAC(S5)
>  acpitimer0 at acpi0: 3579545 Hz, 24 bits
>  acpihpet0 at acpi0: 2500 Hz
>  acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
>  cpu0 at mainbus0: apid 0 (boot processor)
>  cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+, 2612.48 MHz
>  cpu0:
>  FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
>  H,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
>  cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
> 64b/line
>  16-way L2 cache
>  cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
>  cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
>  cpu0: apic clock running at 200MHz
>  cpu1 at mainbus0: apid 1 (application processor)
>  cpu1: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+, 2612.04 MHz
>  cpu1:
>  FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
>  H,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
>  cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
> 64b/line
>  16-way L2 cache
>  cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
>  cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
>  ioapic0 at mainbus0 apid 2 pa 0xfec0, version 11, 24 pins
>  ioapic0: misconfigured as apic 0, remapped to apid 2
>  acpiprt0 at acpi0: bus 0 (PCI0)
>  acpiprt1 at acpi0: bus 1 (HUB0)
>  acpicpu0 at acpi0: PSS
>  acpicpu1 at acpi0: PSS
>  acpitz0 at acpi0: critical temperature 90 degC
>  acpibtn0 at acpi0: PWRB
>  cpu0: PowerNow! K8 2612 MHz: speeds: 2600 2400 2200 2000 1800 1000 MHz
>  pci0 at mainbus0 bus 0: configuration mode 1
>  "NVIDIA MCP65 Memory" rev 0xa1 at pci0 dev 0 function 0 not configured
>  pcib0 at pci0 dev 1 function 0 "NVIDIA MCP65 ISA" rev 0xa2
>  nviic0 at pci0 dev 1 function 1 "NVIDIA MCP65 SMBus" rev 0xa1
>  iic0 at nviic0
>  iic0: addr 0x2e 00=c1 01=0f 02=00 03=00 04=00 05=00 06=00 07=c0 08=14 09=62
>  10=02 11=00 12=00 words 00=c1ff 01=0fff 02=00ff 03=00ff 04=00ff 05=00ff
>  06=00ff 07=c0ff
>  iic0: addr 0x2f 00=00 01=0c 03=00 13=00 words 00=00ff 01=0cff 02= 03=00ff
>  04= 05= 06= 07=
>  spdmem0 at iic0 addr 0x52: 1GB DDR2 SDRAM non-parity PC2-6400CL5
>  spdmem1 at iic0 addr 0x53: 1GB DDR2 SDRAM non-parity PC2-6400CL5
>  iic1 at nviic0
>  "NVIDIA MCP65 Memory" rev 0xa1 at pci0 dev 1 function 2 not configured
>  ohci0 at pci0 dev 2 function 0 "NVIDIA MCP65 USB" rev 0xa1: apic 2 int 10 
> (irq
>  10), version 1.0, legacy support
>  ehci0 at pci0 dev 2 function 1 "NVIDIA MCP65 USB" rev 0xa1: apic 2 int 11 
> (irq
>  11)
>  usb0 at ehci0: USB revision 2.0
>  uhub0 at usb0 "NVIDIA EHCI root hub" rev 2.00/1.00 addr 1
>  ppb0 at pci0 dev 8 function 0 "NVIDIA MCP65 PCI" rev 0xa1
>  pci1 at ppb0 bus 1
>  emu0 at pci1 dev 7 function 0 "Creative Labs SoundBlaster Audigy" rev 0x04:
>  apic 2 int 10 (irq 10)
>  ac97: codec id 0x83847609 (SigmaTel STAC9721/23)
>  ac97: codec features 18 bit DAC, 18 bit ADC, SigmaTel 3D
>  audio0 at emu0
>  "Creative Labs SoundBlaster Audigy Digital" rev 0x04 at pci1 dev 7 function 1
>  not configured
>  "Creative Labs Firewire" rev 0x04 at pci1 dev 7 function 2 not configured
>  pciide0 at pci0 dev 9 function 0 "NVIDIA MCP65 IDE" rev 0xa1: DMA, channel 0
>  configured to compatibility, channel 1 configured to compatibility
>  atapiscsi0 at pciide0 channel 0 drive 0
>  scsibus0 at atapiscsi0: 2 targets, initiator 7
>  cd0 at scsibus0 targ 0 lun 0:  ATAPI 5/cdrom
>  removable
>  wd0 at pciide0 channel 0 drive 1: 
>  wd0: 16-sector PIO, LBA48, 76293MB, 15625 sectors
>  cd0(pciide0:0:0): 

Re: OT: Dissertation ideas for my degree

[Constantine A. Murenin]

On 19/06/2008, Darrin Chandler <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 18, 2008 at 10:15:54PM +0100, Edd Barrett wrote:
>
> > Hi,
>  >
>  > As it seems my last two project ideas for my degree have fallen through, I
>  > wonder if anyone here has any ideas for software projects which are:
>  >
>  > a) Useful
>  > b) Conceptually new
>  >
>  > Ideas need not be OpenBSD based, but it's a bonus if it is.
>  >
>  > Usually a project consists of a software build and a write up.
>
>
> How about a distributed network file system with RAID-like redundancy.
>  Bonus for self tuning behavior (this machine gets shut down every night,
>  don't rely on it being there).

Dillon is working on it for how many years now? ;-)

C.

Re: Sensors support on proliant DL380 G2

[Constantine A. Murenin]

On 08/03/2008, Ruan Kendall <[EMAIL PROTECTED]> wrote:
> So, I've tried both 4.2 and 4.3 snapshot on this slightly aged proliant I've
>  obtained, and most things have worked very well but for the total
>  absense of any sensor information.
>
>  Is this because a) I've not done something terribly important that
>  would enable it for me, b) because all the sensor stuff is hidden
>  behind something like ACPI which isn't working on this machine or c)
>  because there is no driver for the bit of hardware that handles all
>  the sensor data?
>
>  The various bits of server firmware and the bios have been updated to
>  the most recent version, and the BIOS has been set up to boot as 'linux'.
>
>  It currently looks like my only hope is to give up and use something
>  like Centos 4 instead, but I'd rather not have to.

I totally agree that sensors is the most important part of the OS,
upon which OS selection should be made!


>  Dmesg for a recent 4.3 snapshot. I also have MP and 4.2 dmesgs if
>  they're likely to prove useful, which I assume they won't.
>
>  --
>
>  OpenBSD 4.3 (GENERIC) #695: Tue Mar  4 14:28:56 MST 2008
>   [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
>  cpu0: Intel(R) Pentium(R) III CPU - S 1400MHz ("GenuineIntel"
>  686-class) 1.40 GHz
>  cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
>  real mem  = 1341730816 (1279MB)
>  avail mem = 1287774208 (1228MB)
>  mainbus0 at root
>  bios0 at mainbus0: AT/286+ BIOS, date 12/31/99, BIOS32 rev. 0 @
>  0xf, SMBIOS rev. 2.3 @ 0xec000 (38 entries)
>  bios0: vendor Compaq version "P24" date 05/01/2004
>  bios0: Compaq ProLiant DL380 G2
>  acpi0 at bios0: rev 0, can't enable ACPI
>  bios0: ROM list: 0xc/0x8000 0xc8000/0x4000 0xcc000/0x1800 0xee000/0x2000!
>  cpu0 at mainbus0
>  pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
>  pchb0 at pci0 dev 0 function 0 "ServerWorks CNB20HE Host" rev 0x23
>  pci1 at pchb0 bus 1
>  ppb0 at pci1 dev 3 function 0 "Intel S21152BB PCI-PCI" rev 0x00
>  pci2 at ppb0 bus 2
>  vga1 at pci2 dev 0 function 0 "ATI Rage XL" rev 0x27
>  wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
>  wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
>  "Compaq Netelligent ASMC" rev 0x00 at pci2 dev 1 function 0 not configured
>  vendor "Compaq", unknown product 0x005a (class memory subclass
>  miscellaneous, rev 0x00) at pci2 dev 2 function 0 not configured
>  vendor "Compaq", unknown product 0x00b1 (class memory subclass
>  miscellaneous, rev 0x01) at pci2 dev 4 function 0 not configured
>  pchb1 at pci0 dev 0 function 1 "ServerWorks CNB20HE Host" rev 0x01
>  pchb2 at pci0 dev 0 function 2 "ServerWorks CNB20HE Host" rev 0x01
>  pchb3 at pci0 dev 0 function 3 "ServerWorks CNB20HE Host" rev 0x01
>  pci3 at pchb3 bus 7
>  "Compaq PCI Hotplug" rev 0x12 at pci3 dev 7 function 0 not configured
>  ciss0 at pci0 dev 1 function 0 "Compaq Smart Array 5i/532 rev.2" rev 0x01: 
> irq 3
>  ciss0: 1 LD, HW rev 1, FW 2.62/2.62
>  scsibus0 at ciss0: 1 targets
>  sd0 at scsibus0 targ 0 lun 0:  SCSI0
>  0/direct fixed
>  sd0: 34719MB, 4426 cyl, 255 head, 63 sec, 512 bytes/sec, 71106240 sec total
>  fxp0 at pci0 dev 2 function 0 "Intel 8255x" rev 0x08, i82559: irq 5,
>  address 00:08:02:58:58:9c
>  inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4
>  fxp1 at pci0 dev 4 function 0 "Intel 8255x" rev 0x08, i82559: irq 7,
>  address 00:08:02:58:58:9b
>  inphy1 at fxp1 phy 1: i82555 10/100 PHY, rev. 4
>  "Compaq Netelligent ASMC" rev 0x00 at pci0 dev 6 function 0 not configured
>  piixpm0 at pci0 dev 15 function 0 "ServerWorks OSB4" rev 0x51: SMBus disabled

It looks like SMBus is disabled on your box. If you can find a way to
enable it, you'll have a somewhat higher chance of finding some
sensors.

Cheers,
Constantine.


>  pciide0 at pci0 dev 15 function 1 "ServerWorks OSB4 IDE" rev 0x00: DMA
>  atapiscsi0 at pciide0 channel 0 drive 0
>  scsibus1 at atapiscsi0: 2 targets
>  cd0 at scsibus1 targ 0 lun 0:  SCSI0
>  5/cdrom removable
>  cd0(pciide0:0:0): using PIO mode 4
>  ohci0 at pci0 dev 15 function 2 "ServerWorks OSB4/CSB5 USB" rev 0x04:
>  irq 11, version 1.0, legacy support
>  usb0 at ohci0: USB revision 1.0
>  uhub0 at usb0 "ServerWorks OHCI root hub" rev 1.00/1.00 addr 1
>  isa0 at mainbus0
>  isadma0 at isa0
>  pckbc0 at isa0 port 0x60/5
>  pckbd0 at pckbc0 (kbd slot)
>  pckbc0: using irq 1 for kbd slot
>  wskbd0 at pckbd0: console keyboard, using wsdisplay0
>  pms0 at pckbc0 (aux slot)
>  pckbc0: using irq 12 for aux slot
>  wsmouse0 at pms0 mux 0
>  pcppi0 at isa0 port 0x61
>  midi0 at pcppi0: 
>  spkr0 at pcppi0
>  npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
>  pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
>  fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
>  fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
>  biomask ef4d netmask efed ttymask ffef
>  mtrr: Pentium Pro MTRR support
>  softraid0 at root
>  root on sd0a swap on sd0b dump o

Re: anoncvs asking for password

[Constantine A. Murenin]

On 24/02/2008, Chris Smith <[EMAIL PROTECTED]> wrote:
> All of a sudden when using cvs (via ssh) to update the src tree
>  (following the instructions on http://openbsd.org/faq/faq5.html#Bld) I
>  am prompted for a password. Several different mirrors same issue.

anoncvs.ca.openbsd.org is being rebuild, and currently asks for password.

You probably have it hardcoded into CVS/Root files, and so it may be
used regardless of the server you specify in CVSROOT.

>  What to do?

find /usr/src -path "*/CVS/Root" -exec rm {} \;

C.

Re: OpenCVS?

[Constantine A. Murenin]

On 20 Jan 2008 10:15:15 -0800, Unix Fan <[EMAIL PROTECTED]> wrote:
> Stuart Henderson wrote:
>
> > See for yourself: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cvs/
>
>
>
> I'm slighly confused by something if the "cvs" command in OpenBSD 4.2 is 
> "OpenCVS", why does "cvs --help" refer to places like cvshome.org for updates 
> etc?

If you take a look at src/usr.bin/Makefile [0], you'll notice that
'cvs' (as well as 'pcc', BTW) is not (yet) connected to the build. The
one that is connected is the GNU CVS from src/gnu/usr.bin/cvs/.

On the other hand, the situation with rcs is different -- OpenRCS was
connected to the build before OpenBSD 4.0, and GNU RCS was completely
removed from the source tree before OpenBSD 4.1.

br,
cnst.su.

[0] http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/Makefile

Re: watchdog sysctl missing?

[Constantine A. Murenin]

On 19/01/2008, Richard Daemon <[EMAIL PROTECTED]> wrote:
> Running 4.2-stable (Jan 13).
>
> sysctl:
> kern.watchdog.auto
> kern.watchdog.period
>
> These sysctl's are no longer available? I didn't notice if it's just in this
> build or something changed in 4.1 or 4.2, but I know 4.0 has it and the man
> page now even references these sysctl's.
>
> Is it just me or am I missing something???

These sysctl values are available only when at least one hardware
watchdog driver is attached.

C.

Re: Real men don't attack straw men

[Constantine A. Murenin]

On 14/12/2007, Richard Stallman <[EMAIL PROTECTED]> wrote:
> There is a big practical difference between making a free system
> suggest a non-free package, and making a free package run on a
> non-free system.  We treat the two issues differently because they are
> different.

The only practical difference is that a free system that _practically_
conforms to your proposed definition still doesn't exist nor is it
ready for production.

> People already know about non-free systems such as Windows, so it is
> unlikely that the mention of them in a free package will tell them
> about a system and they will then switch to it.  Also, switching
> operating systems is a big deal.  People are unlikely to switch to a
> non-free operating system merely because a free program runs on it.

Switching operating systems is no bigger deal than switching
application software.  It is only a big deal if one tries to impose
artificial restrictions that certain applications could not be run on
certain operating systems.

Consider that by providing an easy way to install (and deinstall!)
non-free userland application software, a free operating system is
simply compensating for the lost revenue that increased availability
of the free application software has caused for many people and
organisations to remain with non-free operating systems.  Please note,
that FSF is directly responsible for this revenue loss, too; as it
happily provides vast amount of software for Windows users.

C.

Re: Real men don't attack straw men

[Constantine A. Murenin]

On 15/12/2007, Richard Stallman <[EMAIL PROTECTED]> wrote:
> Convincing people to switch to free software is just one part of what
> we need to do to establish a society in which users are free.  We also
> have to teach them to appreciate their freedom, and recognize that
> non-free would deny them their freedom.  That way they will take
> actions to protect their freedom.
>
> Messages of acceptance of non-free software undermine the efforts
> to teach people that appreciation, and that is why I have decided
> to reject them.

However, it has been pointed out many times today that you fail to
reject non-free operating systems in your own free application
software.  If so, who are you to tell us that we should reject
non-free application software in our free operating system software?

C.

Re: cvsweb browsing out of sync with latest src?

[Constantine A. Murenin]

On 13/12/2007, Nick Guenther <[EMAIL PROTECTED]> wrote:
> On 12/10/07, Mayuresh Kathe <[EMAIL PROTECTED]> wrote:
> > > Hey Nick, sorry to go against you, but do take a look at;
> > > http://www.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.bin/sudo/
> > >
> > > It's been eliminated since there's a replacement by Todd under a
> > > non-GNU license.
> > >
> > > ~Mayuresh
> >
> > Crazy, but correcting myself, stuff is put inside "sudo/sudo" not in
> > the main directory.
>
> Which incidentally brings up that it looks like cvsweb is a bit broken
> in places:
> http://www.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.bin/sudo/sudo/Attic/tgetpass.c?rev=1.15&content-type=text/x-cvsweb-markup
> "Error
> Error: Unexpected output from cvs co pbCheck whether the directory
> /usr/OpenBSD/cvs/CVSROOT exists and the script has write-access to the
> CVSROOT/history file if it exists.brThe script needs to place lock
> files in the directory the file is in as well./b"

Where did you get that link from? Manually constructed links are,
obviously, not guaranteed to work, so what's precisely is the problem?
:)

C.

Re: Real men don't attack straw men

[Constantine A. Murenin]

On 13/12/2007, Richard Stallman <[EMAIL PROTECTED]> wrote:
> Do you believe that The Pirate Bay is guilty of copyright infringement?
>
> That is a legal question, not an ethical question.  I do not know what
> the law of any given country would say about the Pirate Bay.  You
> would need to ask a lawyer.
>
> Instead of that legal question, we could ask an ethical question: is
> The Pirate Bay's activity right or wrong?
>
> In general, I think people have a moral right to share copies of
> published works, so I see no reason to criticize the Pirate Bay in
> general.  However, I would not recommend that as a place to look for
> software, both because some of the software might be non-free, and for
> security reasons.
>
> If OpenBSD could spin off the ports system (perhaps people could put
> it on the Pirate Bay), and break off connection with it, then it would
> cease to convey any message from OpenBSD to the users.  Then I could
> recommend OpenBSD while not recommending its ports system.  Currently,
> that option does not exist.

That option does exist. Ports tree is not installed by default. Users
are not required to install the ports tree. When installing software,
the ports tree is viewed as a last resort by both users and developers
of OpenBSD. So if you refer someone to use OpenBSD, and tell them not
to use the ports tree, they'll do just fine without using it.

C.

Re: Real men don't attack straw men

[Constantine A. Murenin]

On 13/12/2007, Richard Stallman <[EMAIL PROTECTED]> wrote:
> If a library has a book on [insert-controversial-topic-here], does that
> imply endorsement of said topic by the library or by someone who reads the
> book?  Should the library burn copies of books on such topics to protect
> the citizenry?  Absolutely not.
>
> A system distribution is more like an anthology than like a library.
> We do consider the editor of the anthology book responsible for the choice
> of what to include.

OpenBSD neither includes nor promotes any non-free software.  However,
like any unbiased material, it does contain a complete and detailed
reference list, called 'ports'.

Please note, that there is no automated process about getting ports
onto your system. The only thing that the OpenBSD install process can
install for you is the base system, which actually happens to have a
lot of software in it as it is, from X and apache, to gcc and lynx. So
unlike other BSD systems, which heavily depend on you installing both
ports and packages for various components of the system, OpenBSD
requires neither ports nor packages for the day to day operation.

C.

Re: Intel(R) Core(TM)2 Duo CPU E6550 freeze on core 2 duo

[Constantine A. Murenin]

On 06/12/2007, Benoit Chesneau <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> HAve currently problem with a server based on Intel(R) Core(TM)2 Duo CPU
> E6550
> with a Realtek 8168 ( re(4) ). It freeze after some random time.  I
> don't know why.
> No log about it. I tried to :
> - enable acpi
> - force the carde in 100baseTX
>
>
> But without any success yet. Hard to test anyway because this is a
> remote machine
> and can't check it from the rescue mode since this rescue mode is under
> freebsd.
>
> Any idee ? Anyone used such machine yet ? Here is a dmesg :
> http://babilu.metavers.net/dmesg/dmesg_enlil_20071206.txt

http://kerneltrap.org/mailarchive/openbsd-misc/2007/10/21/349821
http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&numbers=5504

No patch yet. As these boxes are pretty popular, if someone writes
one, they'll be a hero. :)

C.

Re: /var/log/messages permissions in 4.2

[Constantine A. Murenin]

On 04/12/2007, Constantine A. Murenin <[EMAIL PROTECTED]> wrote:
> On 04/12/2007, Lars Noodin <[EMAIL PROTECTED]> wrote:
> > I'm noticing that the messages log seems to be world readable in 4.2
> > e.g.
> > -rw-r--r--  1 root  wheel   1801 Dec  4 17:51 messages
> >
> > What's up with that?   Shouldn't it be set to 640?  If not what is the
> > rationale for 644?
>
> It has been like this for a very long time, since 2002-11 and OpenBSD 3.3.
>
> http://www.openbsd.org/cgi-bin/cvsweb/src/etc/newsyslog.conf#rev1.20

Actually, it was always rotated with 644 permissions, starting with
NetBSD dated 1993.

What would be the rationale for 640? ;)

C.

Re: /var/log/messages permissions in 4.2

[Constantine A. Murenin]

On 04/12/2007, Lars Noodin <[EMAIL PROTECTED]> wrote:
> I'm noticing that the messages log seems to be world readable in 4.2
> e.g.
> -rw-r--r--  1 root  wheel   1801 Dec  4 17:51 messages
>
> What's up with that?   Shouldn't it be set to 640?  If not what is the
> rationale for 644?

It has been like this for a very long time, since 2002-11 and OpenBSD 3.3.

http://www.openbsd.org/cgi-bin/cvsweb/src/etc/newsyslog.conf#rev1.20

Cheers,
Constantine.

Re: Replace sendmail with qmail?

[Constantine A. Murenin]

On 30/11/2007, Bryan Irvine <[EMAIL PROTECTED]> wrote:
> Strangely, it appears that you have no right put something in the
> public domain, it just happens 70 years after you die.  (Copyright
> lawyers feel free to chime in here)

Says who?

Strangely, this is not how it works.

Any copyright owner can release their work into the public domain.


http://www.openbsd.org/policy.html

 While material that is truly entered into the "Public Domain" can
be included in OpenBSD, review is required on a case by case basis.
Frequently the "public domain" assertion is made by someone who does
not really hold all rights under Copyright law to grant that status or
there are a variety of conditions imposed on use. For a work to be
truly in the "Public Domain" all rights are abandoned and the material
is offered without restrictions.


http://cr.yp.to/publicdomain.html

 I've seen a few people claiming, without justification, that a
clear written dedication of the work to the public domain doesn't
actually abandon copyright. Nobody, to my knowledge, has ever wasted a
judge's time trying to make this silly argument in court.


Cheers,
Constantine.

Re: PF Changes in 4.2

[Constantine A. Murenin]

On 05/11/2007, Axton <[EMAIL PROTECTED]> wrote:
> I remember reading some changes to the defaults for pf in how states
> are tracked in pf.conf rules (default is now keep state flags S/SA).
> For the life of me I can not find any official reference to it on the
> internet or in my mail.  Can someone give me a pointer?
>
> The only reference I can find on the net (nothing from openbsd.org):
> http://home.nuug.no/~peter/pf/en/long-firewall.html#AEN415

http://www.openbsd.org/41.html

 keep state is now the default for pf.conf(5) rules, as is the
flags S/SA option on TCP connections. no state and flags any can be
used to disable stateful filtering or TCP flags checking.

C.

Re: Network troubles with release/AMD64

[Constantine A. Murenin]

On 02/11/2007, Huncar, Peter <[EMAIL PROTECTED]> wrote:
> Hello list
>
> I have trouble upgrading from latest snapshot to -stable :(
> The system will boot, but network won't start with ": no such interface"
> message.
> After loggin from console,when I type ifconfig, I'll get
> ": no such interface"

4.2-current is newer than 4.2, and downgrading is not supported.

You must have newer userland and/or libraries than the kernel that you
are trying to run with. In 4.2-current, there's been a flag day to
accommodate for these changes:
http://www.openbsd.org/faq/current.html#20070903

C.

Re: Bad MD5 of install42.iso

[Constantine A. Murenin]

On 01/11/2007, Przemys3aw Pawe3czyk <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I dloaded the file from two different servers.
> Here's what I got running md5sum:
>
> 1) MD5s for downloaded files
> md5sum install42.iso
> 03dc43a1d18d3003843a1f13b3861917  install42.iso
>
> Just for checking:
> md5sum cd42.iso
> 7d4ba197d25088a4ad487f2830028c8d  cd42.iso
>
> 2) The numbers from MD5 official file:
> MD5 (install42.iso) = b3a80c9010716ebc997571a1609cf334
>
> Just for checking:
> MD5 (cd42.iso) = 7d4ba197d25088a4ad487f2830028c8d
>
> What should I do? To burn it or not to burn?

Yes, 03dc43a1d18d3003843a1f13b3861917 is the correct md5 for i386/install42.iso.

http://marc.info/?l=openbsd-www&m=119391863124282&w=2

Best regards,
Constantine.

Re: machine which freeze with openbsd 4.2

[Constantine A. Murenin]

On 21/10/2007, Matthieu Herrb <[EMAIL PROTECTED]> wrote:
> On 10/21/07, Firas Kraiem <[EMAIL PROTECTED]> wrote:
> > Nicolas Letellier wrote:
> > > Firas Kraiem a icrit :
> > >>
> > >> Salut ;)
> > >>
> > >> I have the very same problem on my laptop (running 4.2) and I've
> > >> discovered that the freezings stop if I'm not using the built-in NIC
> > >> (Realtek Gigabit 8169) but use an USB wifi adapter instead. If you also
> > >> have a Realtek, maybe it could be due to a bug in the re driver ?
> > >>
> > >> Firas
> > >>
> > > Are you sure about what you are saying ?
> > > I have already a laptop with this NIC and I have this problem;
> > >
> > > It means that there is a bug with gigabit realtek 8169 ?
> > >
> > > Nicolas
> > >
> > >
> >
> > That's what I saw on mine, anyway. Try to boot it without using using
> > the NIC (i.e. delete /etc/hostname.re0) and see if the freezes stop.
> >
> > Firas
> >
>
> I see the re(4) hanging my machine problem too.
>
> One more data point:  cnst@ found out that having lots of multicast
> traffic on you local net (Mac OS X machines, IPv6,...) greatly
> increases the probability of such hangs happening.

Actually, that's what you told me. :) I simply noticed that the
machine reliably freezes every time I power up my iBook with OS X.

kernel/5504: re(4) on ASUS V3-P5G965 Core 2 Duo ...
http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&numbers=5504

FWIW, I've also noticed that sftp'ing the machine from a Windows box
on the same local network can reliably freeze it, too. (Although
non-sftp ssh sessions never caused the machine to freeze.)

One other interesting point is that it appears that only one processor
would freeze (e.g. sometimes it is still possible to login from the
console and do a few things until the box is totally frozen).

FreeBSD 7.0 re(4) does not appear to be affected by this bug (insofar
as the machine doesn't freeze).

Cheers,
Constantine.

Re: vr driver trouble on Soekris 5501

[Constantine A. Murenin]

On 12/10/2007, Christian Plattner <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Today something strange happened on one of my Soekris 5501 boxes,
> it runs OpenBSD 4.1-stable. The box is connected with a cross-over cable
> to another machine via the vr1 interface (the box has 4 vr interfaces).
>
> Problem: After having rebooted the machine at the other end of the cable
> multiple times, the Soekris box suddenly stopped receiving packets on
> the vr1 interface.
>
> After playing around with ping and tcpdump on both sides I found out
> that the vr1 interface allowed me to send packets, but incoming packets
> did no show up in tcpdump, even though the LED on the interface was
> flickering.
>
> I changed the cable, connected the vr1 of the Soekris to another
> machine, then to a switch port with lots of broadcast traffic etc.etc.
> nothing helped, ingress traffic on vr1 did not show up in tcpdump.
>
> Solution: Finally, immediatelly after doing "ifconfig vr1 down &&
> ifconfig vr1 up" everything worked again as normal.
>
> The link on vr1 is currently only used to do SSH between the two
> machines, so this is really a low traffic link. On the other hand,
> vr0,vr2,vr3 are heavily used (BGP sessions etc., the Soekris is at the
> border of my AS). btw: the machine at the other end of the cable is a
> Soekris 5501 as well. Had to reboot it to perform a BIOS upgrade.
>
> No suspicious output in dmesg.
>
> Any ideas on how I could further track down the problem?
>
> Thanks,
>   Christian
>
> The vr interfaces in dmesg:
>
> vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
> address 00:00:24:c8:de:68
> ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5,
> address 00:00:24:c8:de:69
> ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9,
> address 00:00:24:c8:de:6a
> ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12,
> address 00:00:24:c8:de:6b
> ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
>
> # ifconfig vr1
>
> vr1: flags=8843 mtu 1500
>  lladdr 00:00:24:c8:de:69
>  media: Ethernet autoselect (100baseTX full-duplex)
>  status: active
>  inet XX.XX.XX.XX netmask 0xffe0 broadcast XX.XX.XX.YY
>  inet6 fe80::200:24ff:fec8:de69%vr1 prefixlen 64 scopeid 0x2

Not sure if related, but something similar has been fixed in
4.2-current already.

http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076486.html
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_vr.c#rev1.70

I think you should be able to safely apply the 1.69 to 1.70 diff to
your source tree if this is of a concern. The diff is for vr_attach()
only, so if your system is already up and running and you never reboot
it, then you probably shouldn't bother until your next upgrade.

Cheers,
Constantine.

Re: OpenBSD XSS ;)

[Constantine A. Murenin]

On 10/10/2007, Anton Karpov <[EMAIL PROTECTED]> wrote:
> 2007/10/10, Can Erkin Acar <[EMAIL PROTECTED]>:
> >
> > Anton Karpov <[EMAIL PROTECTED]> wrote:
> >
> >
> > In this case, if you have some web application on the same
> > *domain name* then the XSS can be used to take control of the
> > user session on the application. Especially fun for isp/hosting
> > kind of settings where you have customer management and
> > troubleshooting (looking glass etc.) services side by side.
> >
> > Can
>
>
>
> Yes, I', aware of it, I
> just forgot about situation when you can really give access to bgplg
> to [stupid] clients/users, which are not too smart to look into the
> url, use firefox/noscript, etc ;) To make things clear
> (as I see cvs commit
> logs), originally this bug was found by my colleague Alexander
> Polyakov, and I just mention it on misc@


"You should never underestimate the predictability of stupidity."

-- Bullet-Tooth Tony, Snatch (2000)

:)

C.

Re: Speeding up OBSD bootup

[Constantine A. Murenin]

On 06/10/2007, Karel Kulhavy <[EMAIL PROTECTED]> wrote:
> Is it possible to specify the kernel that the hardware for which there are
> drivers probing for but I don't have in my PC is absent? Since OBSD has no
> suspend to disk/RAM, the bootup speed is critical when working with a laptop
> in public transport.
>
> Or are there any other possible ways how to speed up the bootup process?

You might want to checkout ports/sysutils/dmassage/.

Obviously, under improper use this might disable all hotpluggable USB stuff.

C.

Re: Venezuala Change to GMT -4:30

[Constantine A. Murenin]

On 03/10/2007, Julian Bolivar <[EMAIL PROTECTED]> wrote:
> In this month Caracas/Venezuela change to GMT -4:30, anyone know if this
> change will be included in the next openbsd release?

Any country that changes the timezones without an advance notice is
asking for an IT disaster.

The whole story with various governments changing timezones out of the
blue is getting a bit old now, and affected people should complain to
their governments about the problem, not to the developers of the UNIX
operating systems that already have a well-defined mechanism for
effectively dealing with the timezones.

C.

Re: Porting OpenBSD to OLPC XO laptops.

[Constantine A. Murenin]

On 26/09/2007, Joshua Smith <[EMAIL PROTECTED]> wrote:
> Maybe I've missed something but what makes it impossible to write a
> device driver for the Wireless chipset?

Nothing is impossible, but the problem is that so many parts of the
OLPC hardware are proprietary and without readily available
documentation that the work would be very difficult and time
consuming.

Looks can be deceiving, too: this version of the laptop appears to be
targeted to 18+ users, because in many jurisdictions you have to be at
least 18 to sign an NDA in order to actually explore the hardware part
of the laptop.

C.

Re: Porting OpenBSD to OLPC XO laptops.

[Constantine A. Murenin]

On 26/09/2007, Paul de Weerd <[EMAIL PROTECTED]> wrote:
> [diverted to [EMAIL PROTECTED]
>
> On Wed, Sep 26, 2007 at 08:08:41AM -0700, big one wrote:
> | OLPC (One Laptop Per Child) had released XO AMD Geode LX Laptops
> | using G1G1 (Buy 2 Get 1). One laptop will be sent to the buyer and the
> | 2nd laptop will be sent to a child in a poor, developing country.
> |
> | According to Mr Theo de Raadt from OpenBSD, it is impossible to
> | write device driver for Wireless chipset inside XO.
> |
> | According to OLPC developer team:
> | 1. There is no standard BIOS inside XO laptops.
> | 2. There is no VGA/EGA/CGA video mode.
> |
> | Is it possible to port OpenBSD to XO Laptops without
> | activating/using the wireless chipset?
> | Thank you
>
> Why not buy some and send them to interested developers.
>
> "Buy 2 Send 1 to an OpenBSD developer" ;)

You'd have to buy at least a total of four laptops then. :)

It is no less interesting to note that the price is obviously 2 times
more what it was supposed to be.

One more thing that deserves attention is that the OLPC camp promised
us all that by the time the laptop goes into mass production, all
parts of the system will be "free", including the wireless module --
but is it indeed so?

C.

Re: Statement by SFLC (was Re: Wasting our Freedom)

[Constantine A. Murenin]

On 16/09/2007, Marc Espie <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 16, 2007 at 09:17:41AM -0400, Eben Moglen wrote:
> > We will make no more public statements until the work is complete, and
> > we will be neither hurried nor intimidated by people who shout at us
> > instead of helping.
>
> http://www.softwarefreedom.org/news/2007/jul/31/openhal/
>
> As I said in a former email, this has several glaring problems.
>
> As far as I understand, this is a public statement, even if it predates
> the issue at hand.
>
> Please fix it in a timely manner, or take it down for now.

Most noticeably, I fail to see any credits to Reyk Floeter in the
above press release.

Moreover, back when the release was first posted at the above address,
there was no credit even to the OpenBSD project, which I found simply
outrageous!  Only after I (and possibly others) have complained to
SFLC did they append the release to give some really vague mention
that OpenHAL is based on OpenBSD's ath(4) HAL.

Eben, is this the work that you are doing in bringing the communities
together, by omitting such vital information as giving credit to the
people and projects who performed most of the work?  After all of
these mistakes, after ignoring the ethical side of the relicensing,
after failing to inform when relicensing is even legally an option,
are you seriously even surprised about the negative attention that
SFLC is getting now?  Taking a step aside, don't you agree it is
well-deserved?

http://bsd.slashdot.org/article.pl?sid=07/09/13/156258

C.

Re: ath5k license revised

[Constantine A. Murenin]

On 03/09/07, Peter N. M. Hansteen <[EMAIL PROTECTED]> wrote:
> "Gregg Reynolds" <[EMAIL PROTECTED]> writes:
>
> > http://marc.info/?l=linux-wireless&m=118857712529898&w=2
>
> IANAL (nor a party to this so ICBW), but AFAICS the SFLC told them to
> DTRT.

In this whole discussion, I really like the following quote from a
response to Luis' email regarding SFLC involvement...

Al Viro <[EMAIL PROTECTED]>:

"if you have to rely on SFLC for licensing decisions...  Ouch."

http://lkml.org/lkml/2007/9/1/222

Yes.  "Ouch."

C.

Re: ath5k license revised

[Constantine A. Murenin]

On 03/09/07, Gregg Reynolds <[EMAIL PROTECTED]> wrote:
> http://marc.info/?l=linux-wireless&m=118857712529898&w=2

This is kinda old news:
http://marc.info/?l=openbsd-misc&m=118866496716802&w=2

The interesting thing, though, is to notice that:

1. Jiri, the original author of the infamous GPLv2 patch, changed his
GPLv2 to BSD (thanks!)

2. Nick, originally a good guy, changed his BSD and BSD/GPLv2 to GPLv2 only.

WTF? Why can't they both agree to use BSD, so that the modifications
remain compatible with what it was forked from -- Reyk's ath(4) HAL in
OpenBSD.

P.S. Also, see Reyk's response:
http://marc.info/?l=openbsd-misc&m=118881908304473&w=2

Constantine.

Re: Fwd: That whole "Linux stealing our code" thing

[Constantine A. Murenin]

On 01/09/07, Theo de Raadt <[EMAIL PROTECTED]> wrote:
> When companies have taken our wireless device drivers, many many of
> them have given changes and fixes back.  Some maybe didn't, but that
> is OK.
>
> When Linux took our changes back, they immediately locked the door
> against changes moving back, by putting a GPL license on guard.
>
> Why does our brother Linux take a file that is 90% BSD licensed,
> and refuse to let us see the 10% he adds?

Indeed, it's upsetting that people like Luis Rodriguez push for the
lawyers to be involved to (fight?) an open source project. Why, may I
ask?

Why Luis puts the phrase "legal hell" next to entirely free software?
[0] Why is he trying to go against the BSD community, which gave him
the entire HAL framework for the driver in question?

Best regards,
Constantine.

[0] http://marc.info/?l=linux-wireless&m=118857712529898&w=2

Re: That whole "Linux stealing our code" thing

[Constantine A. Murenin]

On 01/09/07, Martin Schrvder <[EMAIL PROTECTED]> wrote:
> 2007/9/2, Constantine A. Murenin <[EMAIL PROTECTED]>:
> > If you want your modifications to be licensed differently, then you
> > would have to put a new licence on top of existing licensing text, as
> > far I as understand. This is how it's often done in OpenBSD and
> > NetBSD, IIRC.
>
> This has to agreed by all copyright holders.

You are mistaken, it has not -- as long as the licences are compatible
and the names of the copyright holders appear aligned to their correct
licence.

However, with this Atheros HAL case this is not the solution -- if the
Linux people wrap GPL around BSD code, then we won't be able to get
any changes back.

C.

Re: That whole "Linux stealing our code" thing

[Constantine A. Murenin]

On 01/09/07, Rui Miguel Silva Seabra <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 01, 2007 at 04:08:46PM -0600, Theo de Raadt wrote:
> > > On Sat, Sep 01, 2007 at 11:39:28AM -0600, Theo de Raadt wrote:
> > > > > In the case of the later 3 files, their copyright notice says:
> > > > > "at your choice" you may distribute under the terms of the BSD
> > > > > license or under the terms of the GNU GPL v2
> > > > >
> > > > > So if they chose to distribute those 3 files under the terms of the 
> > > > > GNU
> > > > > GPL v2, it is correct to change the copyright notice of those three 
> > > > > files
> > > > > alone in order to remove a license that the distributor chose not to 
> > > > > use
> > > > > anymore.
> > > >
> > > > Not exactly.  I won't quote from the GPL again, but even the GPL has a
> > > > paragraph about this.  You must pass on the rights you received.
> > >   ^^^
> > >
> > > Yes. The *rights you received* are the central point of the question.
> > > Which did the user receive? The BSD granted ones? Or the GPLv2 granted 
> > > ones?
> >
> >
> > You received the full rights granted by copyright law as a recipient,
> > PLUS the ones granted by the entire document.  But, you did not receive the
> > right to modify the author's license document.
>   ^
> Which is one of two, at the mutually exclusive choice of the user. In the case
> of the three files I see nothing bad done.
>
> > > If some software is dual licensed, you have two sets of rights you can 
> > > choose.
> > > It's not both at the same time. The text is even explicit: "alternatively"
> >
> > The word "alternatively" means "replace"?  It might mean "select", but does
> > it really mean "replace in-line"?  What dictionary are you using?  If 
> > something
> > is not clear in a legal document, who are you to decide what it actually 
> > means?
> > That's the author and the courts who work that out, sorry.
>
> Most dictionaries I had at my hand define alternative as choices. You can get
> http://en.wiktionary.org/wiki/alternative
>
> Noun
> alternative (plural alternatives)
> 1. A situation which allows a choice between two or more 
> possibilities.
> 2. A choice between two or more possibilities.
> 3. One of several things which can be chosen.
>
> If he chose alternative B, the GNU GPLv2, he's bound by the GNU GPLv2 terms, 
> and
> not the BSD ones, or even both at the same time. As such, any derivative from 
> his
> choice on has to be "on the same terms" he got, namely the GNU GPL v2

Yes, I don't think you actually disagree with Theo -- what Theo tries
to say is that you simply cannot alter the text of the licence -- but
you can, obviously, select the terms of whatever one licence you want
to use.

If you want your modifications to be licensed differently, then you
would have to put a new licence on top of existing licensing text, as
far I as understand. This is how it's often done in OpenBSD and
NetBSD, IIRC.

C.

Re: That whole "Linux stealing our code" thing

[Constantine A. Murenin]

On 01/09/07, Siju George <[EMAIL PROTECTED]> wrote:
> On 9/1/07, Marco Peereboom <[EMAIL PROTECTED]> wrote:
> >
> > Try to run strings on windows command line utilities.  You'll see that
> > they preserved the copyrights as required.
> >
>
> Could somebody please explain about "Running Strings"?

tvc: {2476} strings `where ftp` | grep -A1 -i copyright
@(#) Copyright (c) 1985, 1989, 1993, 1994
The Regents of the University of California.  All rights reserved.
tvc: {2477}

That's on OpenBSD. On Windows, you can presumably get strings(1) as a
part of the Cygwin package, or try out Windows Services for UNIX.

http://undeadly.org/cgi?action=article&sid=20030927090008

C.

Re: That whole "Linux stealing our code" thing

[Constantine A. Murenin]

On 01/09/07, David H. Lynch Jr. <[EMAIL PROTECTED]> wrote:
> The ISC License requires little more than preserving the copyright
> notice, not the license itself,

That is entirely false.

If the file has a copyright on it, unless it is otherwise noticed, you
cannot simply do whatever you wish with the file.

The moment you remove the licence is the moment you make the code
nonfree (e.g. non-compatible with any free or open-source licence).

If instead of removing the licence you put your own licence under a
copyright statement of someone else, well, that simply constitutes
fraud -- it's no different than quietly changing the first page of a
legal document after the document is already signed and approved.

C.

Re: Asus Striker Extreme does not support 4GB memory

[Constantine A. Murenin]

On 31/08/2007, Sam Fourman Jr. <[EMAIL PROTECTED]> wrote:
> This may be a retarted question, but can a Intel quad core run amd64

just as i386 doesn't run on 80386, amd64 does run on Intel Core 2 processors

http://en.wikipedia.org/wiki/X86-64

C.

Re: Linux Driver Violates BSD License

[Constantine A. Murenin]

On 29/08/2007, Theo de Raadt <[EMAIL PROTECTED]> wrote:
> > On 8/28/07, Darrin Chandler <[EMAIL PROTECTED]> wrote:
> > > Normally I wouldn't repeat undeadly stuff here on misc@, but I'm sure
> > > many of you will want to know.
> > >
> > > http://undeadly.org/cgi?action=article&sid=20070829001634
> > >
> > >
> > > And if you do this kind of thing, it's worth letting the rest of the
> > > world in on this:
> > > http://digg.com/linux_unix/Lnux_Driver_Violated_BSD_License
> >
> > I am currently having a discussion about dual licensing, and am a bit
> > confused. Is Reyk and others working on this drivers code dual
> > licensed (from the diff it doesn't seem like it is, since I see a BSD
> > 3 Clause)? Also say I submit a patch for this driver, does that mean
> > this will have to be dual licensed also or can I choose if it is BSD 3
> > Clause or GPLv2?
>
> Well, there are two parts to the Atheros driver.
>
> Reyk's code is *NOT* dual-licensed under the GPL.  So there is no
> issue with Reyk's code.  He has explicitly stated that his code is not
> dual-licenced.  The file have no GPL on them.  He's the author, he
> said so.  None else can add a GPL to it.  (No matter how much Luis
> begs and pleads and whines).
>
> The other part of the driver was written by Sam Leffler.  Sam's code,
> though, is dual-licenced with a 4-term BSD'ish license (it has only 3
> terms, but the wrong term was deleted, and the attribution term was
> actually strengthened -- read the license).  The GPL annotation in the
> licenses says specifically --
>
>  * Alternatively, this software may be distributed under the terms of the
>  * GNU General Public License ("GPL") version 2 as published by the Free
>  * Software Foundation.
>
> Note that word "Alternatively".
>
> That means "or".
>
> That means that if anyone makes changes to that file and distributes it,
> after their changes are in the file then EITHER license will apply.
>
> Since it says "Alternatively" / "Or", we can simply take any of those
> new changes UNDER THE LICENSE WE PREFER, and commit them to our file
> which is NOT dual licensed.  If they want to use the GPL to restrict
> our use -- that is us, the original authors, see -- they should work
> on seperate files.
>
> Note there are some files out there that don't use words like "or" or
> "alternatively" when they mix licenses.  One must read what the
> license says very carefully.  Trying to brush everything into the same
> simple catagories will get you nowhere.
>
> As a commentary, it seems as if many people have tired of the "make my
> own license" game, and now are playing the "mix licenses in my own
> way" game.  And the "interpret it in the way that is most beneficial
> to me" game.
>
> Simpler said, I don't know why they have to be such jerks.  Luis in
> particular has been ragging on Reyk for years to dual license his
> code, and won't take no for an answer.  It's already totally free code,
> but apparently there is some stupid Linus rule that says that all the
> code must not be free  n it can't just be free, it has to
> be SPECIFICALLY GPL.  Now I know that's not the truth, because the Linux
> tree is FULL of objectional code that either has CSRG licences on it, or
> no license at all.
>
> Now he's saying that Linux people should basically ignore Reyk's
> license.  Well screw you Luis, that is precisely not what you will do
> -- you uneducated twit.  Copyright is law.  You will obey it.
>
>
> Anyways, hope that explained the question you asked, FOR THIS PARTICULAR
> CASE.  As I say, read the exact files, and the exact licenses.


BTW, since this is misc@openbsd.org, people might be interested to
know about the history of the licensing terms of ath(4) in OpenBSD.


OpenBSD's ath(4) consists of two parts:

1. a driver, copyrighted by Sam Leffler of FreeBSD

2. a HAL, copyrighted by Reyk Floeter of OpenBSD


What Theo explained above concerns the OpenHAL code.  OpenHAL is the
Linux name for madwifi driver connected with reyk's entirely free and
open source ath(4) HAL code.

Sam originally put a dual BSD/GPL licence onto his driver code.

Reyk always put a BSD-style licence onto his HAL code.

At the time OpenHAL was forked from OpenBSD, OpenBSD's ath(4)
_driver_, but _not the HAL_, was dual licensed.


As already mentioned, OpenBSD's ath(4) HAL, written by Reyk, was
_never_ dual licensed. See the history on
/sys/dev/ic/{ar52{10,11,12}{.c,{reg,var}.h},ar5xxx.{c,h}}.

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/#ar5210.c


Few months ago, Sam changed the licence of _his_ code to a 2-clause
BSD licence. Sam had every right to do so, because he was and is the
only copyright holder of that code, as the licence header of the
driver file indicates, in FreeBSD, OpenBSD etc.

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ath/if_ath.c#rev1.170
http://www.freshbsd.org/2007/06/06?project=freebsd&committer=sam


Reyk committed Sam's changes to OpenBSD the same day, so now,
OpenBSD's ath(4) is _entire

Re: sensorsd says the sensor is within limit, but it's not...

[Constantine A. Murenin]

On 04/07/07, Per-Olov Sjvholm <[EMAIL PROTECTED]> wrote:

On Wednesdayen den 4 July 2007 04.17.30 you wrote:
> Please, check the manual page for your system [0], specifically, the
> following:
>
>  Sensors that provide status (such as from bio(4), esm(4), or

ipmi(4))

> do not require boundary values specified (that otherwise will be ignored)
> and simply trigger on status transitions.
>
> In other words, for those sensors that provide the status themselves,
> the keywords "high" and "low" in sensorsd.conf have no effect. This
> limitation was removed at c2k7 [1], and the newest sensorsd in OpenBSD
> 4.1-current allows you to set your own limits for any sensor, and
> ignore the status that the sensor device itself provides.
>
> So if you need this functionality, you may wish to upgrade to OpenBSD
> 4.1-current.
>
> Alternatively, you may upgrade to OpenBSD 4.1-stable that has the new
> two-level sensor framework, and then manually update sensorsd to
> 4.1-current (files /usr/src/{etc/sensorsd.conf,usr.sbin/sensorsd/*}),
> compiling and installing it afterwards  -- sensorsd in 4.1-current as
> of today is source-code-compatible with 4.1-stable (note that it is
> not binary compatible). However, please be warned that mixing
> 4.1-stable and 4.1-current is not officially supported, so use it at
> your own risk! (Even though it works for me in this specific case with
> sensorsd.)
>
> Cheers,
> Constantine. :)
>
> [0]
>

http://www.openbsd.org/cgi-bin/man.cgi?query=sensorsd.conf&sektion=5&manpat

>h=OpenBSD+4.0
>
> [1]
>

http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/sensorsd/sensorsd.c#rev1

>.32


Thanks for the answer

So I only need the "command" with %1-%4 and no "low"/"high" specs in
sensorsd.conf?


yes


The trigger will come when Dell think the temp i to low or
high?


yes, it will trigger whenever there is any transition in state. I.e.
when you start sensorsd, sensors state in sensorsd goes from undefined
to whatever it is for every sensor, and this also triggers the
command.


If so... Is there a way of knowing at what temperature this happends. I
mean, could you ask the hardware itself with any software, or do I have to
dig into some of Dell:s docs? That is not super important, but it would be
nice to know at what value it happends, and if possible test it.


not that I'm aware of, however, I've never used ipmi


Also, isn't it possible then to have different commands for low and high if
low and high has no meanings? I mean, do I have to take care of if it's a

low

or a high warning in the command script. If low and high have meanings (as

in

OBSD 4.1-current) I could have one sensor row in sensorsd.conf for high and
one for low with different commands. Right?


No, if you read the man-pages, you'll see that every sensor is matched
by at most one entry in the config file. You can have a shell script
as the command, which can compare sensor values to the limits and take
appropriate decision on which command to execute.


You said that:
"Alternatively, you may upgrade to OpenBSD 4.1-stable that has the new
two-level sensor framework" Why do I need to go to -CURRENT if it's

included

in 4.1-STABLE? Isn't 4.1-STABLE ok? I want to avoid -current on production
servers. But after looking at
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/sensorsd/sensorsd.c it
seems I am *not* OK with just 4.1 STABLE, and that I need -CURRENT if I

want

this functionality...


In 4.1-stable we have the new two-level sensors framework, but no
changes in sensorsd other then the way sensors are addressed --
however, this change in sensor addressing is a huge improvement for
sensorsd in itself. ;)

In -current, we have the new sensorsd functionality, which is based on
the new framework. Hence my suggestion to use -current sensorsd with a
4.1-stable system -- it's not officially supported, but it works as of
today without any problems.

If you don't want to copy and compile sensorsd sources from -current
to 4.1-stable, then I'd suggest you wait until 4.2 is released. :)

Cheers,
Constantine.

Re: sensorsd says the sensor is within limit, but it's not...

[Constantine A. Murenin]

On 03/07/07, Per-Olov Sjvholm <[EMAIL PROTECTED]> wrote:

Hi Misc


I am probably missing something, but what..


sensorsd says in the syslog that the sensor is "within limits" even though
a "sysctl -a|grep sensor" shows that it is not.


Are there any known bugs? I have checked the list and cannot find anything
related to this... I run a Dell PE830 on OpenBSD 4.0 stable (latest update

in

May 25:th). I have these sensors which appears to always show the correct
values running a "sysctl -a|grep sensor".
hw.sensors.0=ipmi0, Temp, 43.00 degC, OK
hw.sensors.1=ipmi0, Planar Temp, 38.00 degC, OK
hw.sensors.2=ipmi0, CMOS Battery, 3.13 V DC, OK
hw.sensors.3=ipmi0, Back Fan, 2204 RPM, OK
hw.sensors.4=ipmi0, Intrusion, Off, OK
hw.sensors.5=ami0, sd0, drive online, OK



From sensords.conf
hw.sensors.0:high=42C:command=/bin/echo "test test"|/usr/bin/mailx -s

"Sensor

warning: CPU temp over %2 bla bla bla" MYEMAIL
hw.sensors.1:high=39C:command=/bin/echo "test test"|/usr/bin/mailx -s

"Sensor

warning: Chassie temp over %2 bla bla bla" MYEMAIL


Starting sensorsd and look at /var/log/daemon
Jul  3 16:12:22 xanadu sensorsd[14634]: hw.sensors.0: within limits, value:
43.00 degC
Jul  3 16:12:22 xanadu sensorsd[14634]: hw.sensors.1: within limits, value:
38.00 degC


I assume I receive no reports as the daemon say the sensor wrongly is

within

the limits



Please, check the manual page for your system [0], specifically, the
following:

Sensors that provide status (such as from bio(4), esm(4), or ipmi(4)) do
not require boundary values specified (that otherwise will be ignored)
and simply trigger on status transitions.

In other words, for those sensors that provide the status themselves,
the keywords "high" and "low" in sensorsd.conf have no effect. This
limitation was removed at c2k7 [1], and the newest sensorsd in OpenBSD
4.1-current allows you to set your own limits for any sensor, and
ignore the status that the sensor device itself provides.

So if you need this functionality, you may wish to upgrade to OpenBSD
4.1-current.

Alternatively, you may upgrade to OpenBSD 4.1-stable that has the new
two-level sensor framework, and then manually update sensorsd to
4.1-current (files /usr/src/{etc/sensorsd.conf,usr.sbin/sensorsd/*}),
compiling and installing it afterwards  -- sensorsd in 4.1-current as
of today is source-code-compatible with 4.1-stable (note that it is
not binary compatible). However, please be warned that mixing
4.1-stable and 4.1-current is not officially supported, so use it at
your own risk! (Even though it works for me in this specific case with
sensorsd.)

Cheers,
Constantine. :)

[0]
http://www.openbsd.org/cgi-bin/man.cgi?query=sensorsd.conf&sektion=5&manpath=
OpenBSD+4.0

[1]
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/sensorsd/sensorsd.c#rev1.3
2

Re: Intel Core 2

[Constantine A. Murenin]

On 27/06/07, Jacob Yocom-Piatt <[EMAIL PROTECTED]> wrote:

you make more money if your widgets break because your new widget is
vastly improved. new packaging, same great defects!


The best thing about computer parts randomly failing will hit us in a
few years, due to RoHS directives:

http://en.wikipedia.org/wiki/RoHS#Impact_on_reliability
http://en.wikipedia.org/wiki/Whisker_%28metallurgy%29


Another problem that lead-free solders face is the growth of tin

whiskers. These thin strands of tin can grow and make contact with an
adjacent trace, developing a short circuit. Tin whiskers have already
been responsible for at least one failure at a nuclear power plant.
Other documented failures include satellites in orbit, aircraft in
flight, and implanted medical pacemakers.


Reliability decay of low-lead materials may be economically

desirable for some consumer product companies because it provides a
mechanism to enforce planned obsolescence and replacement. Ironically,
this is the opposite of the claimed intent of RoHS legislation.

C.

Re: Intel Core 2

[Constantine A. Murenin]

On 27/06/07, Daniel Horecki <[EMAIL PROTECTED]> wrote:

Anyway, what about Transmeta?


Check the news:


On February 7, 2007, Transmeta closed its engineering services

departments and terminated 75 employees. The company announced that it
would no longer develop and sell hardware, but would focus on the
development and licensing of intellectual property.

http://en.wikipedia.org/wiki/Transmeta

C.

Re: sensors process use 10% CPU time and high memory

[Constantine A. Murenin]

On 11/06/07, Marc Balmer <[EMAIL PROTECTED]> wrote:

* Jean-Girard Pailloncy wrote:
> Hi,
>
> I have 3 Tyan Trinity GC-SL boxes with OpenBSD 4.1. sensors kernel process
> use 10% of the CPU time and have RES high up to 74 MB.
> I did not have a sensorsd daemon runing.
> I do the same on my soekris, nothing like that.

try to disable iic and ichicc in UKC (boot bsd -c).


Are drivers attached at i2c bus always that bad on CPU time?

C.



>
> Any idea ?
> JG Pailloncy
>
> # top -uIS -s1
> load averages:  1.18,  0.96,  0.75
> 09:34:33
> 70 processes:  5 running, 64 idle, 1 on processor
> CPU states:  3.2% user,  0.0% nice, 11.4% system,  0.0% interrupt, 85.4%
idle
> Memory: Real: 75M/388M act/tot  Free: 615M  Swap: 0K/1028M used/tot
> renice
>   PIDUID   PRI NICE  SIZE   RES STATEWAIT TIMECPU COMMAND
> 5  01000K   40M sleeptimeou  57:32  9.03% sensors
> # sysctl hw.sensors
> hw.sensors.lm1.temp0=0.00 degC
> hw.sensors.lm1.temp1=-44.50 degC
> hw.sensors.lm1.temp2=-44.50 degC
> hw.sensors.lm1.fan0=3199 RPM
> hw.sensors.lm1.fan1=49 RPM
> hw.sensors.lm1.fan2=49 RPM
> hw.sensors.lm1.volt0=0.00 VDC (VCore)
> hw.sensors.lm1.volt1=0.00 VDC (VINR0)
> hw.sensors.lm1.volt2=0.00 VDC (+3.3V)
> hw.sensors.lm1.volt3=0.00 VDC (+5V)
> hw.sensors.lm1.volt4=0.00 VDC (+12V)
> hw.sensors.lm1.volt5=-14.91 VDC (-12V)
> hw.sensors.lm1.volt6=4.56 VDC (-5V)
> hw.sensors.lm1.volt7=0.00 VDC (5VSB)
> hw.sensors.lm1.volt8=0.00 VDC (VBAT)
> # dmesg
> OpenBSD 4.1 (GENERIC) #1435: Sat Mar 10 19:07:45 MST 2007
> [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Intel(R) Pentium(R) 4 CPU 2.66GHz ("GenuineIntel" 686-class) 2.66 GHz
> cpu0:
>
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID,xTPR
> real mem  = 1073246208 (1048092K)
> avail mem = 745324544 (727856K)
> using 4278 buffers containing 280363008 bytes (273792K) of memory
> mainbus0 (root)
> bios0 at mainbus0: AT/286+ BIOS, date 11/09/04, BIOS32 rev. 0 @ 0xfdb80,
> SMBIOS rev. 2.3 @ 0xf0640 (50 entries)
> apm0 at bios0: Power Management spec V1.2
> apm0: AC on, battery charge unknown
> apm0: flags 30102 dobusy 0 doidle 1
> pcibios0 at bios0: rev 2.1 @ 0xf/0x1
> pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf4ee0/272 (15 entries)
> pcibios0: PCI Interrupt Router at 000:01:7 ("ServerWorks CSB5" rev 0x00)
> pcibios0: PCI bus #0 is the last bus
> bios0: ROM list: 0xc/0x8000 0xc8000/0x2200 0xca800/0x1000
0xcb800/0x1800
> acpi at mainbus0 not configured
> cpu0 at mainbus0
> pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
> pchb0 at pci0 dev 0 function 0 "ServerWorks GCNB-LE Host" rev 0x32
> pchb1 at pci0 dev 0 function 1 "ServerWorks GCNB-LE Host" rev 0x00
> pci1 at pchb1 bus 1
> ami0 at pci1 dev 3 function 0 "Symbios Logic MegaRAID" rev 0x01: irq 10
> ami0: LSI 520, 64b/lhc, FW 1L37, BIOS vG119, 64MB RAM
> ami0: 1 channels, 0 FC loops, 1 logical drives
> scsibus0 at ami0: 40 targets
> sd0 at scsibus0 targ 0 lun 0:  SCSI2 0/direct fixed
> sd0: 70512MB, 70512 cyl, 64 head, 32 sec, 512 bytes/sec, 144408576 sec
total
> scsibus1 at ami0: 16 targets
> vga1 at pci0 dev 7 function 0 "ATI Rage XL" rev 0x27
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> fxp0 at pci0 dev 8 function 0 "Intel 8255x" rev 0x10, i82551: irq 9,
> address 00:e0:81:29:42:76
> inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4
> piixpm0 at pci0 dev 15 function 0 "ServerWorks CSB5" rev 0x93: polling
> iic0 at piixpm0
> lm1 at iic0 addr 0x28: W83782D
> piixpm0: exec: op 1, addr 0x49, cmdlen 1, len 0, flags 0x08: timeout,
> status 0x9
> pciide0 at pci0 dev 15 function 1 "ServerWorks CSB5 IDE" rev 0x93: DMA
> atapiscsi0 at pciide0 channel 0 drive 0
> scsibus2 at atapiscsi0: 2 targets
> cd0 at scsibus2 targ 0 lun 0:  SCSI0
> 5/cdrom removable
> cd0(pciide0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 2
> ohci0 at pci0 dev 15 function 2 "ServerWorks OSB4/CSB5 USB" rev 0x05: irq
> 10, version 1.0, legacy support
> usb0 at ohci0: USB revision 1.0
> uhub0 at usb0
> uhub0: ServerWorks OHCI root hub, rev 1.00/1.00, addr 1
> uhub0: 4 ports with 4 removable, self powered
> pchb2 at pci0 dev 15 function 3 "ServerWorks CSB5 LPC" rev 0x00
> pchb3 at pci0 dev 16 function 0 "ServerWorks CIOB-X2 PCIX" rev 0x05
> pchb4 at pci0 dev 16 function 2 "ServerWorks CIOB-X2 PCIX" rev 0x05
> pci2 at pchb4 bus 2
> em0 at pci2 dev 7 function 0 "Intel PRO/1000MT (82545EM)" rev 0x01: irq 5,
> address 00:e0:81:29:42:77
> isa0 at mainbus0
> isadma0 at isa0
> pckbc0 at isa0 port 0x60/5
> pckbd0 at pckbc0 (kbd slot)
> pckbc0: using irq 1 for kbd slot
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> pcppi0 at isa0 port 0x61
> midi0 at pcppi0: 
> spkr0 at pcppi0
> lpt0 at isa0 port 0x378/4 irq 7
> npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
> pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> pccom0: c

Re: sensorsd shutting computer down

[Constantine A. Murenin]

On 27/05/07, Steven <[EMAIL PROTECTED]> wrote:

Hello,

Last update (~2 weeks ago) and the one from last night result in
sensorsd shutting down my PC within 2 to 4 minutes after booting up.
Now /etc/sensorsd.conf has an entry in it that I added to safely
shut the computer down if the CPU gets too hot.  The only problem is
that sensorsd keeps shutting the computer down even though the
temperature displayed using systat -w 1 sensors shows the cpu to be
a good 8 to 10 degrees cooler than the conditional temperature!
Perhaps the temperature is spiking at some point between systat
updating itself?

Anyhow, here are the relevant /etc/sensorsd.conf and dmesg.  Thanks
and let me know if there's anymore information that I can (should)
include.


# $OpenBSD: sensorsd.conf,v 1.1 2003/10/08 20:30:04 grange Exp $

#
# Sample sensorsd.conf file. See sensorsd.conf(5) for details.
#

# +5 voltage (volts)
#hw.sensors.3:low=4.8V:high=5.2V

# +12 voltage (volts)
#hw.sensors.4:low=11.5V:high=12.5V

# Chipset temperature (degrees Celsius)
#hw.sensors.7:high=50C

# CPU temperature (degrees Celsius)
hw.sensors.viaenv0.temp0:high=70C:command=/sbin/shutdown -hp now "System 
overheating!  Emergency Shutdown!"

# CPU fan (RPM)
#hw.sensors.3:low=5000


Have you updated the userland? There was some change in
 2 months ago (22nd March) that required recompilation
of all userland and port utilities that interact with the sensors
framework.

If updating the userland doesn't fix your problem, then please include
`grep sensorsd /var/log/daemon` and `sysctl hw`.

Cheers,
Constantine.

Re: www.openbsd.org (and vs openbsd.org)

[Constantine A. Murenin]

On 10/05/07, Emilio Perea <[EMAIL PROTECTED]> wrote:

On Fri, May 11, 2007 at 12:10:13AM +0200, Martin Toft wrote:
> Nobody answered my second "question" though :) Maybe nobody knows the
> answer? :)
> Summary: I was once told not to use openbsd.org; it was said that
> www.openbsd.org was the only valid site (ignoring mirror sites). Is this
> just bullshit?

I think the question was answered indirectly when he mentioned
www.openbsd.org being a mirror site.  As I understand it, openbsd.org is
the "root" site (probably in Theo's house) but www.openbsd.org is the
main mirror located at the university.  It has much higher bandwidth so
it should be used instead.  As a matter of courtesy as well as
practicality, you should use www.openbsd.org instead.


www.openbsd.org has some scripts and pages that no other mirror
carries, i.e. /cgi-bin/man.cgi, /cgi-bin/cvsweb and a few others.

But you don't have to worry about it -- all mirrors link to
www.openbsd.org for those pages that they are not supposed to carry.

Cheers,
Constantine.

Re: sensorsd

[Constantine A. Murenin]

On 24/03/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

On Mar 24, 2007, at 1:38 PM, Constantine A. Murenin wrote:
> I'm surprised you've got any emails from those exceeds at all, because
> the sensors that you have warnings for do not match the one's you
> claim you are monitoring in sensorsd.conf (hw.sensors.3 in conf,
> hw.sensors.4 on log).

Sorry I didn't post the whole sensorsd.conf

hw.sensors.3:low=4.8V:high=5.2V:command=/bin/sh /etc/sensorsd/notify

# +12 voltage (volts)
hw.sensors.4:low=11.5V:high=12.55V


You do not have a command specified on hw.sensors.4, so you should not
be expecting any emails to be sent when this sensor undergoes
transitions from one state to another.

I think the syntax of sensorsd.conf is rather obvious here -- your
command gets executed only when hw.sensors.3 undergoes state
transitions, hw.sensors.4 transitions will only be reported into
syslog.

C.

Re: sensorsd

[Constantine A. Murenin]

On 24/03/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

In /etc/sensorsd.conf

hw.sensors.3:low=4.8V:high=5.2V:command=/bin/sh /etc/sensorsd/notify

In /etc/sensorsd/notify

#!/bin/sh

/usr/bin/tail -n 25 /var/log/daemon | /usr/bin/grep sensorsd | /usr/
bin/grep exceed > /etc/sensorsd/`date +%m%d%y_%H%M`.log
/usr/bin/mail -s "Hardware Sensors Monitor - Threshold Exceeded" < /
etc/sensorsd/`date +%m%d%y_%H%M`.log [EMAIL PROTECTED]

 From /var/log/daemon

# grep sensorsd /var/log/daemon | grep exceed
Mar 24 02:31:31 vegeta sensorsd[23054]: hw.sensors.4: exceed limits,
value: 12.61 V DC
Mar 24 03:30:44 vegeta sensorsd[23054]: hw.sensors.4: exceed limits,
value: 12.61 V DC
Mar 24 03:30:52 vegeta sensorsd[13951]: hw.sensors.4: exceed limits,
value: 12.61 V DC
Mar 24 08:28:51 vegeta sensorsd[13951]: hw.sensors.4: exceed limits,
value: 12.61 V DC
Mar 24 08:30:51 vegeta sensorsd[13951]: hw.sensors.4: exceed limits,
value: 12.61 V DC

 From /var/log/mail

Mar 24 03:30:54 vegeta sendmail[23902]: l2O8UrwM023902:
[EMAIL PROTECTED], ctladdr=dj_goku (1000/1000), delay=00:00:01,
xdelay=00:00:00, mailer=relay, pri=30599, relay=[127.0.0.1]
[127.0.0.1], dsn=2.0.0, stat=Sent (l2O8Us5n000215 Message accepted
for delivery)
Mar 24 03:30:55 vegeta sm-mta[18718]: l2O8Us5n000215:
to=<[EMAIL PROTECTED]>, ctladdr=<[EMAIL PROTECTED]> (1000/1000),
delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=30901,
relay=mail.mail.com. [12.34.56.78], dsn=2.0.0, stat=Sent (OK
1174725055 15si26531894nzn)

I have only gotten 1 email from all those exceeds from sensorsd.

Any ideas?


I'm surprised you've got any emails from those exceeds at all, because
the sensors that you have warnings for do not match the one's you
claim you are monitoring in sensorsd.conf (hw.sensors.3 in conf,
hw.sensors.4 on log).

Cheers,
Constantine.

Re: searching a good MRTG/SNMP configuration

[Constantine A. Murenin]

On 10/02/07, Andreas Bihlmaier <[EMAIL PROTECTED]> wrote:

On Sun, Feb 04, 2007 at 04:04:56PM +0100, Henning Brauer wrote:
> * Andreas Bihlmaier <[EMAIL PROTECTED]> [2007-02-04 14:04]:
> > I guess somebody using OpenBSD already has a nice MRTG configuration
> > showing:
> > IN/OUT traffic
> > [CPU] load
> > memory usage
> > some stuff about pf (states, blocks/pass)
> > (using this patch: http://www.packetmischief.ca/openbsd/snmp/)
>
> save yourself the trouble and just go for ports/sysutils/symon/

Thanks everybody who responded.
I eventually went with symon and used a shell script based on:
http://www.benzedrine.cx/statistics.html
but heavily modified.

Results:
http://bihlmaier.org/stats

Problems:
- The new two-level sensor framework is not supported, meaning
  sensor() is useless ATM.


There is a patch for symon for allowing it to adapt to the old
one-level or the new two-level sensor framework at compile time:

http://marc.theaimsgroup.com/?l=openbsd-ports&m=116917726601827&w=2

Willem Dijkstra, author of symon, has this patch, but he told me he is
too overwhelmed with other work, so I don't know if a new version of
symon is coming out anytime soon. Maybe someone could put this patch
into the ports tree before OpenBSD 4.1 freeze?

Cheers,
Constantine.

Re: HTTP URL filtering?

[Constantine A. Murenin]

On 06/02/07, Xavier Mertens <[EMAIL PROTECTED]> wrote:

Hi *,

I've a problem with an Apache web server hit by f*cking spammers...
I would like to filter some URLs (unused but still used by the bots) *BEFORE* 
they reach the httpd processes. What could be the best method? pf? something 
else?

Thanks!


I haven't played with it myself, and don't know if it even compiles on
OpenBSD as it was written for FreeBSD and then ported to Linux, but I
think nginx would be something that would be more than appropriate in
such an occasion.

http://nginx.net/

To my knowledge, nearly half of Russian high-traffic web-sites utilise
this thing for various http traffic routing purposes...

Cheers,
Constantine.

Re: OT: Domain Name Freedom

[Constantine A. Murenin]

On 03/02/07, J.C. Roberts <[EMAIL PROTECTED]> wrote:

Please pardon the off topic post but last month some people on this list
were wondering about "Friendly Registrars" after what happened to
"Fyodor" (of nmap fame) with is seclists.org domain being shut down by
godaddy.

http://marc.theaimsgroup.com/?t=11688078341&r=1&w=2

If you're interested in what's going on and possibly "friendly"
registrars, "Fyodor" has set up a site about it.

http://nodaddy.com/


Can't say I'm surprised at all: sometime ago GoDaddy blocked around a
thousand domain names of some Russian hosting company named
Majordomo.ru, and requested 200 USD for each domain that is to be
reactivated, or 50 USD for each domain that is to be unblocked and
released for transfer.

http://yro.slashdot.org/article.pl?sid=06/06/17/1319233

That story was resolved, but according to Majordomo.ru, it took them 3
days to finally contact GoDaddy and reach an agreement.

Re: Is Theo still hiking ????

[Constantine A. Murenin]

On 28/01/07, Brian Candler <[EMAIL PROTECTED]> wrote:

On Sun, Jan 28, 2007 at 12:36:38AM -0800, Joe wrote:
> whats sad is how many people will never let go of NAT after they migrate
> to ipv6.

It's not sad; for many people it would be essential. How would you like your
48-bit MAC address to become a permanent cookie, following you about
whenever you access the Internet? And if you need to change ISP, and
therefore get a new address allocation, many people would rather just put in
some NAT at the border than take the pain of network renumbering (which IPv6
doesn't make any easier than IPv4)


I don't see your point here -- IPv6 has a notion of prefix. ISP should
give your site a /64 (or /48 if you are a medium-size company with
many sites), and then the rest of your address space will be the same
regardless of the prefix.

I.e. as far as DNS is concerned, you just do a simple search and
replace. And as far as the reverse zone modifications are concerned,
then they are so trivial that it's not even funny.

[...]


Nope. One year ago, France Telecom applied for, and was granted, a /19 of
IPv6 address space. Since the first three bits are fixed in the unicast
addressing plan, this means that a single ISP has already taken 1/65,536th
of the total available.


Last I checked, France Telecom was an NSP, not a "single ISP". So I
don't see a problem for them having a /19, as long as they will not
request any more IPv6 allocations within the foreseeable future.

Cheers,
Constantine.