Re: rdr outgoing traffic
On Wed, 20 Jun 2007, Jason Dixon wrote: > On Wed, 20 Jun 2007 12:00:18 +0200, RafaE Brodewicz <[EMAIL PROTECTED]> > wrote: > > Hello. > > I have machine with one interface pcn0 and ip 192.168.1.7 and I was > > trying to redirect outgoing traffic from it with no success. > > My pf rule: > > > > rdr on pcn0 inet proto tcp from pcn0 to 192.168.1.1 port 80 -> > > 192.168.1.10 > > > > When I do "telnet 192.168.1.1 80" it doesn't redirect traffic. > > What am I doing wrong? > > http://www.openbsd.org/faq/pf/rdr.html#reflect Certainly interesting reading, but I don't think it addresses OP's question. As I understand it, the refers to an ethernet, no routing through a firewall being involved. 192.168.1.7 192.168.1.1 192.168.1.10 | | | ...-+---+---+- Host7 connects through its sole interface pcn0 to an ethernet. The OP has a rule which he believes will cause tcp packets for Host1:80 to be redirected to Host10:80. OP implies (and I infer) that the rdr rule given is his only pf rule. Clearly packets going from Host7 to anywhere else pass through interface pcn0. There is no interface to reflect from in the sense of the faq entry cited. I can duplicate OP's problem. This rule is slightly different. (his Host10 is my Host2, obviously) I have added "pass log". This is the ~entire~ contents of /etc/pf.conf rdr pass log on fxp0 inet proto tcp from fxp0 to 192.168.1.1 port 80 \ -> 192.168.1.2 port 8080 My OS is 4.1 STABLE, i386. Note that in my kernel, net.inet.ip.forwarding=0. Also note that this kernel was booted with "pf=NO" in /etc/rc.conf, so the extra stuff related to that switch in /etc/rc was not performed. Trial: [EMAIL PROTECTED] root 0:167]# telnet 192.168.1.1 80 Trying 192.168.1.1... telnet: connect to address 192.168.1.1: Connection refused This does not appear to be redirected. I would have expected to see this: [EMAIL PROTECTED] root 0:167]# telnet 192.168.1.1 80 Trying 192.168.1.2... telnet: connect to address 192.168.1.2: Connection refused (No daemons are listening on port 1:80 or 2:8080). Enabling forwarding changes nothing. (I didn't expect it to.) I have time and resources (throw-away boxes on the LAN) to experiment, but request guidance and clues. I have repeated the experiment with this pf.conf and forwarding enabled: (129... is www.openbsd.org) It also failed to redirect. ## rdr pass log inet proto tcp from any to 192.168.1.1 port 80 -> 129.128.5.191 port 80 pass log all ## A few years ago, I would have said to enable packet filtering in /etc/sysctl.conf, but that appears to be no longer switchable. A few trials with block filter rules shows pf to be "on". Dave
Re: booting to ignore fstab
On Mon, 2 Jul 2007, David B. wrote: > Hi, hate to bother. I'm working in 3.8 and I've run across something new > and can't figure out. For some reason, on this box a drive isn't > mounting, and the boot blows and asks for shell. so, I go to shell and > I've tried to edit the fstab file to remark out the mountpoint that's > gone bad. First off, VI isn't there, so I've tried ,s/old/new/g using > ed, but then it says that it's a read only file, and when I try to > whoami, or to su, it doesn't see the programs. So, all I need to do is to > be able to edit fstab and remark out the bad mount point and I can take > it from there. thanks > Its free. Remount / with write access. I believe that would be: # mount -u -w / No need for "su", you're already root. Dave -- Resistance is futile. You've already been assimilated.
Re: mutt, getmail & procmail
On Fri, 13 Jul 2007, Philip Guenther wrote: > On 7/13/07, Denny White <[EMAIL PROTECTED]> wrote: > ... > > PATH=$HOME/bin:$HOME:/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin:/usr/local/sbin:. > > That line is probably unnecessary. Unless you can point to a specific > program that your .procmailrc uses that is not in the default PATH set > by procmail, why change it? > > > > FORMAIL=/usr/local/bin/formail > > Why do people think that hardcoding the paths to normal programs is a > good thing? Why not just say "formail" and let the shell do the work? Sometimes users do nutty things with aliases. Then they need to undo the nuttiness when they need default behavior. Even worse is the sort who defines new meanings for common commands and places them "high" in the PATH, or defining nutty shell functions named for standard commands. (Such as the nutty implementation of "undelete" functionality through a redefinition of rm to a mv of a file to a "hidden" directory.) The default ksh.kshrc shipped with OpenBSD contains "nutty" aliases: alias su=wsu alias cd=wcd alias ftp=wftp alias ssh=wssh alias telnet=wtelnet alias rlogin=wrlogin alias ls='ls -gCF' wxxx are nutty shell functions, given the best of both kinds of nuttiness. Once this nuttiness is invited in, the author of shell scripts and configuration files becomes justifiably nervous about their scope. On a multiuser system, even one with one human user, uncertainty arises about what flavor of nuttiness is in play for each user in all possible contexts. (Is my user name that invokes ksh subject to the same nuttiness as the one that invokes zsh or csh?) Also, slipping a dubious substitution for a system command into another user's ~/bin, on ill-administered or "trusty" systems, can lead to various forms of good-natured, puckish mischief. (Suppose I can substitute an arbitary executable named "vi" or "rm" into your ~/bin.) Setting a PATH and using fully qualified path names for utilities may be classified as a sort of prudent practice. Whether it is best practice I do not judge. Dave
Re: Is this a filesystem bug?
On Sat, 8 Sep 2007, Antti Harri wrote: > Hello, > > First just plain directory with mode=700: > > drwx-- 43 root wheel2048 Sep 7 22:24 /backups/ > > Then I mount filesystem under /backups: > > /dev/sd0i on /backups type ffs (local, softdep) > drwxr-x--- 43 root wheel2048 Sep 7 22:24 /backups/ > > The permissions changed, so far good because I've changed > the modes of the mounted volume to 750. > > Then as a normal user belonging to 'wheel' I do: > > $ ls -la /backups/ > ls: /backups/..: Permission denied > [rest of the files are listed normally, including '.'] > > $ stat /backups/.. > stat: /backups/..: Permission denied > > Doing those as root is fine. > > I asked my friend to reproduce this on Linux but > he was unable get any weird errors, therefore > I'm asking here. :-) You're clearly accessing /backups/.. according to the permissions (700) of the mount point, /backups, not the root directory of the mounted volume, which is what you see with ls and stat for /backups after the mount. (This can be demonstrated by umounting /backups, chmoding /backups to 750, remounting and trying again.) As far as I know, this is normal operation for ffs/BSD. My *guess* is that this feature may serve to stifle a way of leveraging permissions through mounting, but, I repeat, that's a guess. Linux may well have different fs semantics (it definitely does in other aspects of file system permissions); it's System-V-ish, not BSD-ish. It's not a guide, therefore, in these file-system semantics problems. Dave -- "America ... might become dictatress of the world. She would be no longer the ruler of her own spirit." -- John Quincy Adams, July 4, 1821
Re: Looking for something similar to "screen"-command
On Wed, 12 Sep 2007, Jon Sjvstedt wrote: > Hello all! > > I have installed BitTorrent-4.2.2 on my 3.9-box. With this i would like to > start file sharing on a console, logout, login later and reattach to the > console of the BitTorrent-4.2.2 session. AFAIK this is done in most > Linux-distros using the command screen, but how can I do it in BSD? > > Any help appreciated > > <> > Jon Sjvstedt Well, you could use "screen" ;-) It's in the ports (/usr/ports/misc/screen) or you could add it with pkg_add. Dave
Re: OpenBSD Install Goal
On Thu, 13 Sep 2007, Marco Peereboom wrote: > I installed FreeBSD once in my life. Took me 3 tries and I am sure some > kittens were murdered in the process. I am also pretty sure I wept at > some point. Honestly I can't remember a much worse installer; maybe SCO > OpenServer but not by much. Me too with F'BSD. A worse installer was present from Redhat, around Fedora 5, I think (maybe 10 years ago). It demanded a VGA monitor, IIRC, among many other sillinesses. OpenBSD's installation is a breath of cool, clear mountain air. It even teaches what "installation" is, if one is attentive. It's a definite selling point to me. It's archaic, thank the gods. My first OpenBSD installation was 2.x, done by building from a borrowed SCSI drive laying on the desk on the end of kludged cables, on a pmax running Ultrix with most of the Ultrix userland unavailable, it being on a remote afs system. *IT WENT WITHOUT A HITCH*, including the X11R5 server. I ran and updated those pmaxes for years, (after the initial installation, by ftp from an i386 on the LAN), until the hardware died of old age. (Anybody need the hockey puck mice?) I got so I was running Open on an 386sx with no fpx and about 9MB of memory and something like a 100MB disk. It wouldn't auto install, but one could, *knowing what was involved through study of the pellucid installation script and the short printed document*, do it with a second host. (It needed a custom kernel to really save memory, so I would build that on another host, and make my own installation floppy with it.) This sort of experience builds True Believers. Dave -- "America ... might become dictatress of the world. She would be no longer the ruler of her own spirit." -- John Quincy Adams, July 4, 1821
Re: sudo & wheel group
On Mon, 17 Sep 2007, Chris wrote: > On 9/17/07, Darrin Chandler <[EMAIL PROTECTED]> wrote: > > problem is. This is why people keep asking you to explain the problem > > more. > > Sorry for being vague. Ok, I have these in /etc/sudoers for joeuser. > joeuser is also in the wheel group. > > joeuser server = NOPASSWD: /sbin/mount, /usr/libexec/locate.updatedb mount can be leveraged to full root. > joeuser server = NOPASSWD: /usr/local/bin/vim /var/www/conf/httpd.conf > joeuser server = NOPASSWD: /usr/local/bin/vim /etc/rc.local Both of these commands, if done with vi, probably allow joe to launch a root shell, ex command :!sh I don't think vim has any better protections. This was, at one time, a common hole in programs like chpass(1). And, of course, joe can execute arbitrary commands through rc.local. > joeuser server = NOPASSWD: /usr/sbin/apachectl Some sort of cleverness with groups might eliminate this one. > joeuser server = NOPASSWD: /usr/bin/tail -f /var/www/logs/access_log > joeuser server = NOPASSWD: /usr/bin/tail -f /var/www/logs/error_log Just make these readable by group wheel. > joeuser server = NOPASSWD: /usr/local/bin/vim /etc/motd > joeuser server = NOPASSWD: /usr/local/bin/vim /etc/pf.conf Same comments as about previous vi-as-root. Make these files rw by group wheel, and no sudo is needed. Changes might be needed to /etc, too. Consider making /etc/motd a symbolic link to a file that joe can edit without privilege. This might work with pf.conf, too, but I dunno -- maybe pf chokes if ownership isn't right? Try an experiment. > I am finding that I need to add joeuser to use pkg_* tools, tcpdump as well. > > Is this the right way to do this? No, not unless you trust joe with full root. Dave -- "America ... might become dictatress of the world. She would be no longer the ruler of her own spirit." -- John Quincy Adams, July 4, 1821
Re: sudo & wheel group
On Sun, 16 Sep 2007, Matthew Szudzik wrote: > What's a laptop user to do? Run as root -- why not? Be careful. Limit PATH. Keep the cat off the keyboard. (This can be pesky if you're using vi at the time.) Open a root xterm, make the background some weird color, use a font and size you don't normally use. You might try setting a deadman to log it out automatically after N seconds of inactivity at the prompt. (man ksh, see the TMOUT variable). Set window-manager attributes so it's "always on top" and can't be "shaded" or "iconified" if you want to be paranoid. Measure twice, cut once; you know the drill. Dave
Re: minimum hard-drive space to compile patches?
On Mon, 24 Sep 2007, Douglas A. Tutty wrote:
> I currently have OBSD running on my P-II with an 850 MB drive and 64 MB
> ram. On install, I chose not to include the compiler set over concern
> re drive space. The FAQ says how much space is required to minimally
> run OBSD and it says how much to be able to comfortably compile ("4G is
> not a bad size").
>
> It may not be "bad" but what is the absolute minimum size of hard drive
> for an i386 to be able to recompile any necessary patches itself?
>
> Thanks,
>
> Doug.
4G is not a bad size. ;-)
(Longer and detailed reply sent offlist -- bottom line, there is
no definite minimum. 250MB for comp41.tgz installed, about 120MB
more to rebuild a kernel, unknowable amounts for rebuilding parts
of userland, ranging from near zero to near 2GB).
Solutions: a second fleabay disk, NFS or use a second box.
Dave
--
Dude, Dave's not here!
Re: files in root directory
On Fri, 28 Sep 2007, Chris Nolan wrote: > Hello, I read through the FAQ and searched the archives but couldn't find an > answer to this question. In /src/distrib/sets/lists/etc/mi, why does openbsd > include the .cshrc and .profile files in the root directory? > > Thanks for any insights! This is root's home directory, traditionally, when booting single-user. > Discover the new Windows Vista I have heard of it, and I don't like what I hear. Dave -- Dude, Dave's not here!
Re: getopt(3) differences OpenBSD/GNU
On Wed, 16 Jan 2008, Sebastian Reitenbach wrote: > Hi, > > I run into troubles with getopt(3). the test program below shows the > problem. It produces different output on Linux and OpenBSD, when it is > called like this on Linux it looks like this: > > ./a.out asdf -n > option char: 110, n > > on OpenBSD, getopt returns -1 and no output is shown. > what would be the best way to make it work on OpenBSD? Could not duplicate. Code worked on OpenBSD 4.2 Dave
Re: low-MHz server
On Wed, 30 Jan 2008, Paul D. Ouderkirk wrote: > Probably your best bet to cover these requirements would be some old > school Compaq Proliant > with 2 or 4-way Pentium Pro CPUs. You can find them clocked around 200MHz. OpenBSD has troubles recognizing the SCSI drives on some of these. (The ones I have, for instance). Also, Compaqs use a persnickety, proprietary bios setup routine that resides on disk -- they were too cheap to pop a 64K ROM into their high end machines. Compaqs of this type require tweaking in boot.conf to recognize all their memory, too. NetBSD, OTOH, and OpenBSD before 3.9, work. Proliant 800. Believe it or not, there are only two obvious P-Pro machines on ebay (us) right now. One is an overdrive (330MHz), the other a diskless Dell "Demention" (sic ;-) at 180. They want 96$+ship for that one. It must have considerable antique value. Dave -- I told you so. -- Cassandra
Re: multi-disk external scsi enclosures
On Wed, 6 Feb 2008, Douglas A. Tutty wrote: > If the drives and carriers are inseperable, then when HP decides to stop > selling them, then no new drives can be had. However, if once one has HP probably stopped making them when people now on this list were in short pants. How time flies. > the carriers, one can swap drives in them, then future upgrades are > easier. They're just the usual SCSI drives (typically 80 pin) screwed into the carriers with the usual screws. I threw out a bunch of these (or similar) Compaq carriers a couple years ago. Swapping drives is a screwdriver job. > Does anyone make a universal hot-plug carrier or do the styles keep No. And they change all the time. Dell is disgusting this way. For their older (~1550) stuff, Dell carriers now cost about the same as a used 16GB drive. Dave -- The president of the United States is the commander-in-chief of the armed forces. He is not the commander-in-chief of the government, nor is he the commander-in-chief of the country.
Re: Where is NAN Defined?
On Sun, 10 Feb 2008, Jim Razmus wrote:
> I'm told that math.h should do this for me. Moreover, I think NAN is a
> machine dependent value.
See /usr/include/i386/ieee.h for some hints.
> Adding the line you mention would break on VAX (assuming I understand
> this correctly). Although I don't think anyone would run this program
> on a VAX, if it's in the ports tree there's the possibility.
Probably. Vaxes didn't use IEEE floating point.
> Worst case, I could add those defines though.
I'd do some more research. Examine the source code for "isnan()"
This is the i386 version
#include
#include
#include
int
isnan(d)
double d;
{
struct ieee_double *p = (struct ieee_double *)&d;
return (p->dbl_exp == DBL_EXP_INFNAN &&
(p->dbl_frach != 0 || p->dbl_fracl != 0));
}
We notice the || in the comparison. There is more than one NaN,
in other words. DBL_EXP_INFNAN is defined in ieee.h
So there is no unique "NaN".
Dave
--
The president of the United States is the commander-in-chief of
the armed forces. He is not the commander-in-chief of the
government, nor is he the commander-in-chief of the country.
Re: Watching the prgress of dd if=drive1 of=drive2
On Mon, 25 Feb 2008, Jan Stary wrote: > On Feb 23 12:15:21, Jon wrote: > > I'm using dd to clone a drive. How can I watch the progress of this or > > see the transfer rate in real time? > > You can use 'fstat -o' on the device file. > > Jan If the dd is running on a terminal, sending the "status" signal will cause a little printout. Usually that's a T, which for console may need to be set first with $ stty status ^T where ^ and T are normal characters. See man stty and also note the kerninfo option. Dave -- The future isn't what it used to be. -- G'kar
Re: XForwarding problem: SOLVED
On Fri, 29 Feb 2008, Denny White wrote: > 4AM, but that's okay. Problem solved. Had previously done some > experimenting around with ~/.profile and ~/.kshrc when I'd been > having history file problems in ksh. As soon as I reverted back > to my old ~/.profile instead of the newer short one that just > exported HISTSIZE, HISTFILE, and ENV=$HOME/.kshrc the XForwarding > problem disappeared. Don't try this at home, kids, especially at > 4AM when you're not only old and senile, but tired as hell too. :-) So what was the fix? What is in the one .profile that was not in the erroneous one? Thanks, Dave -- The future isn't what it used to be. -- G'kar
Re: Where I ma? [Was: Rolling release?]
On Tue, 22 Apr 2008, Tony Abernethy wrote: > Zbigniew Baniewski wrote: > > Is it possible to participate in this mailing list without > > being insulted > > for asking a question, being called by names and so on? > Yes. Easily. No, not easily. Only certain questions can be asked without meriting insult. The casting of an uninsult-worthy question is difficult. This is because of semantic problem, in that "to question" in list language has the primary meaning "to criticize", and "to criticize" has the sole meaning, "to slander, deprecate, mock, or ridicule" and by implication, "to demand changes". The usual broader-world meaning of "to question" is "to request information". > However, you do NOT get to set anyone's agenda, > not even your own. Illustrating my point about list-speak semantics. > > The developers do this the way they want to. > They accomplish a lot with extremely limited resources. > You and I do not even get to have an opinion. Right. The OpenBSD core has this bifurcated nature: they do not accept questions about their policy, offering the project's results on a strict take-it-or-leave-it basis. They do not pretend, in other words, to have a user base that pays for the product and that as consumers have the final say in whether the product succeeds or fails. This attitude is brutally (some might say "inhumanly") honest, easily articulated and frequently understood. Sometimes, however, people insist that OpenBSD fulfill a "democratic-socialist" political model including universal suffrage, or a market-driven "business" model, with a sovereign consumer. On the other hand, the core really-really likes: a) fawning gratitude, and I do mean fawning, almost like that which drips from the slack jaws of a religious worshipper, but also like that from a doting, hovering mother, or syrupy lover, b) regular "donations" in cash or kind or purchase of the product(s). These two tines of the fork -- absolute autonomy on product design and policy and a hunger for fawning worship and donations -- characterize a monopolistic religion, not a business or demo-socialist political entity. (OpenBSD does not pretend, I repeat, to be a business or any sort of democracy.) The term "OpenBSD core" is a misnomer. Like the medieval Catholic church, there is no "core/rim" division. The "users" constitute a "laity", who, seeking heaven and fearing hell, need the sacraments, and approach the Church, which is constituted solely of the "clergy", for them. In return, one tithes, prays, and hopes. Some, eager to work for the Church, and demonstrating their zeal, wisdom and obedience, can receive Holy Orders and join the clergy, i.e. the Church. It is a curious model, but in fact works rather well. But the layman does not ask the bishop why the Mass is in Latin, or why it's held on Sunday morning and not Friday night or Wednesday at 3PM. This is treated almost as if he asked if the nature of Christ is human *and* divine, or solely divine, or solely human, or if Christ is present en toto in the Eucharist bread, or if the wine is necessary. The layman does not ask those questions. There are also a number of lay zealots, who form various lay orders, (such as the Knights of Columbus, Malta, St. John...) who are used to slay the heretic or infidel when such stumbles into Christendom, purging with flame impurity and falseness. When an heresiarch such as the reviled Stallman or one of his deluded imps assaults the Church, spreading dissension and citing false scripture, the Pope might call for Crusade. These lay orders then swing into violent and righteous action, and gratifying flame-fed autos-de-fe entertain the congregation, illuminating the orthodox and obliterating those fallen into Error. Questions of the form "request for information" are covered in a periodically revised chatechism, styled a "FAQ". Requests for information not in the FAQ are entertained on the list, but should be submitted in special form, surrounded by fawning and hand-kissing, in illuminated emails, and often gently reminding the clergy that the supplicant has diligently and regularly tithed. Dave "I'm not Luther" -- The future isn't what it used to be. -- G'kar
Re: whither pow() ?
On Sat, 3 May 2008, Ben Calvert wrote: > On May 3, 2008, at 12:56 AM, Richard Toohey wrote: > > > On 3/05/2008, at 6:21 PM, Richard Toohey wrote: > > > > > $ cc -lm test_pow.c > > $ > > > ok, this fixes it. i'll attempt to understand it when more awake. Thanks! It has been this way since dinosaurs roamed the earth. Understanding why libm and libc are separate might involve the Vax, some of which had no floating point coprocessor. One might have more than one math library on a system for other reasons. (Remember the Weitek coprocessors for i386 about 15 years ago?) Dave -- The future isn't what it used to be. -- G'kar
Re: SMTP Message-ID's
On Tue, 20 Feb 2007, Peter Fraser wrote: > Would not a better test be for message-id's of the format > [EMAIL PROTECTED] ? Probably not. It is quite possible for a legitimate MUA on a host to generate message-ids of the [EMAIL PROTECTED] form. Consider a RFC1918 LAN behind NAT, running from /etc/hosts only. Now OpenBSD creates (or strongly encourages the creation of) a default /etc/hosts with a y.z domain name, and a default /etc/myname with a y.z name in it, but there are, alas, other, less picky OS's out there. And there may be legitimate MUA's that form their message-ids from the basename, since such *does* satisfy RFC. Fighting spam always seems to involve a tradeoff with irritating users, i.e. false positives. Breaking old MUAs is very irritating. Only Beelzebub himself knows what ancient MUAs Win95 lusers are still using. > I also noticed that I seem to have some of my spam that > has a message-id of my own domain name in, so I assume > that some of the mail comes in with no message-id in it at all. Or the spammer generates it on the fly. One host.domain name the spammer can presume to be good is yours. Moveover, such a message-id makes the spam appear (somewhat) to be a response to an email you sent. Whether any spam filters value that, I can't say. Message-ids are not a requirement for legitimate mail, AFAIK. Dave
Re: Spamassassin overwrites manual of OpenBSD spamd
On Tue, 20 Feb 2007, Guido Tschakert wrote: > Hello, > > while reading the discussion about spamd, I decided to learn a little > bit about it and have a look in the manual, but man spamd yields to the > manual of "spamd - daemonized version of spamassassin" what is not > exactly what I was looking for. (I installed p5-Mail-SpamAssasin from > ports/packages) > > apropos spamd shows: > spamd (8) - spam deferral daemon > spamd-setup (8) - parse and load file of spammer addresses > spamd.conf (5) - configuration file read by spamd-setup(8) for spamd(8) > spamdb (8) - spamd database tool > spamlogd (8) - spamd whitelist updating daemon > Mail::SpamAssassin::Client (3p) - Client for spamd Protocol > spamc (1) - client for spamd > spamd (1) - daemonized version of spamassassin > spamd (8) - daemonized version of spamassassin > > The first and the last entry are both spamd (8), but spamassassin from > ports has overwritten /usr/local/man/man8/spamd.8 from the system (which > I am looking for) The system's version is in /usr/share/man/cat8/spamd.0 by default. You can see them all with man -a spamd. (At least on my 4.0-stable) As a work-around, you can name the spamassassin spamd's man pages something else, say Spamd. > I don't know if there is an easy solution for this (I don't want to call > it a problem), but I think this shouldn't happen. This is probably a matter for the spamassassin port maintainter. Renaming its spamd would not be hard. Dave -- When the mandate of Heaven passes, there occurs the rule of concubines and eunuchs. The rule of concubines and eunuchs endures until the righteous take arms. This is the Tao. -- A fragment from the I Wu Juk, or "Book of Burrowing"
Re: Spamassassin overwrites manual of OpenBSD spamd
On Tue, 20 Feb 2007, Mike Erdely wrote: > Guido Tschakert wrote: > > The first and the last entry are both spamd (8), but spamassassin from > > ports has overwritten /usr/local/man/man8/spamd.8 from the system (which > > I am looking for) > > The man page for OpenBSD's spamd is not in /usr/local. > On my system, SpamAssassin's spamd is (1) not (8). > > For OpenBSD's spamd: man 8 spamd > For SpamAssassin: man 1 spamd > > That spamd (8) in /usr/local must be from something else: The version of spamassassin (p5-Mail-SpamAssassin-3.1.4p0) I have installed does install that file. This is, I believe, the latest 4.0-stable port. Dave
Re: chillispot in OBSD 4.0
On Fri, 2 Mar 2007, sonjaya wrote: > Dear all > > i try install chillispot in OBSD 4.0 , it try follow step in > http://www.geeklan.co.uk/?p=72 > i try patch -p1 nothing show , so i try compile manualy You would have to compile manually in any event. > # ./configure --prefix=/usr/local/chillispot > # make > make all-recursive > Making all in src > if gcc -DHAVE_CONFIG_H -I. -I. -I.. -D_GNU_SOURCE -fno-builtin > -DSBINDIR='"/usr/local/chilli/sbin"' -g -O2 -MT chilli.o -MD -MP -MF > ".deps/chilli.Tpo" -c -o chilli.o chilli.c; then mv -f > ".deps/chilli.Tpo" ".deps/chilli.Po"; else rm -f ".deps/chilli.Tpo"; > exit 1; fi > chilli.c: In function `process_options': > chilli.c:734: warning: passing arg 2 of `inet_aton' from incompatible > pointer type > chilli.c:802: warning: passing arg 2 of `inet_aton' from incompatible > pointer type > chilli.c:820: warning: passing arg 2 of `inet_aton' from incompatible > pointer type Sloppy programming or a horrifying bug, probably just slack programming. > if gcc -DHAVE_CONFIG_H -I. -I. -I.. -D_GNU_SOURCE -fno-builtin > -DSBINDIR='"/usr/local/chilli/sbin"' -g -O2 -MT tun.o -MD -MP -MF > ".deps/tun.Tpo" -c -o tun.o tun.c; then mv -f ".deps/tun.Tpo" > ".deps/tun.Po"; else rm -f ".deps/tun.Tpo"; exit 1; fi > tun.c:369:29: missing binary operator before token "defined" As is too often the case, this bit of Linux software was released with software bugs -- it won't compile, was not tested before release, unless Linux gcc comes with a --ignore-fatal-errors switch. Perhaps it does. In your case, the patch you mentioned appears to be for a different version of this slopware. You should have suspected that when it failed to apply. That was your first error. If a patch doesn't work, find out *why*. Find out why by examining the patch and the thing it's alleged to patch. The line giving your *first* error, line 369 of tun.c is this: #elif defined (__FreeBSD__) defined (__OpenBSD__) || defined ... The obvious error is the missing binary operator "||", which belongs, as the compiler told you, before "defined", thus: #elif defined (__FreeBSD__) || defined (__OpenBSD__) || defined ... This error occurs in several other places. Hint: This is NOT an OpenBSD problem. Advice: Do not run C compilers until you know C. Flame: Do not report bugs in C code without first *looking at the code*. This bug is apparent without any knowledge of C, by the way. Flame: Try, next time, to report the version of the software you're trying to compile, its source (URL), and your efforts to fix the problem. Hint: Do not download "development releases" of Linux software, and expect them to work. "Development" has a different meaning in that world, often it means "broken and I can't fix it." Tip: Most malware for Linux likes the system V style make, which is called "gmake" among the righteous. Install the gmake package. Go download the earlier version (from 2005), apply the patch and try again. You should report bugs to the laid-back slackers who would release code with compiler errors in it (and who can't even spell "chile" properly) and wait for them to fix it. Since the release date of this bugware was in September of last year, I wouldn't expect very rapid response. I wouldn't use code like that. I'd be highly suspicious of code with compiler errors that is supposed to be used for authentication. I'd be highly suspicious of code that is not distributed with checksums, too. (ftp is so ~old skool~). I'd suspect somebody had trojanned the thing. Wireless authentication is a target of Evil People, remember, and a penguin is easy meat for sharks. Be thankful somebody *mean* didn't get to this first. Dave the Patient
Re: stupid question re kernal build make install
On Wed, 14 Mar 2007, Jacob Yocom-Piatt wrote: > Clint M. Sand wrote: > > I know this is a dumb question but make install on a kernel build does: > > > > rm -f /obsd > > ln /bsd /obsd > > cp bsd /nbsd > > mv /nbsd /bsd > > > > > > But I can't see the reasoning here. Why do we copy it then move it > > rather than just copying it straight to /bsd? > > > > > > > to prevent a poorly timed "act of god" from making the system unbootable. Doesn't this method also keep the original file correctly mapped by any processes (the running kernel? a debugger?) that may have it open for some reason or other?Just "cp bsd /bsd" would perhaps wreck such a process. With the given method, the old version of /bsd just leaves the namespace, but the vnode, if open, still maps the old blocks, which won't be freed until close(2)d. This is in addtion to the other reason of providing an atomic action, and not messing with the kernel until nearly all possibilities for the action to fail (no space on /, blah blah) have been eliminated, as others have already mentioned. Dave
Re: Compiling your own system as a way of upgrading it is not supported
On Fri, 16 Mar 2007, Karel Kulhavy wrote: > "Some reasons why NOT to build from source: > [...] > Compiling your own system as a way of upgrading it is not supported." > http://openbsd.org/faq/faq5.html > > I want to upgrade my 4.0-release system to get rid of the ipv6 remote > vulnerability. I understood it's possible only by recompiling because the fix > has been released only in source form. Does it mean when I do it, my system > will not be supported anymore? > > CL< Give up this Good Soldier Schweik act, will you? It is tedious and not amusing. It is something that is done to an enemy. When done to friends, it will make them enemies. For those not familiar with Czech literature (most of North America): http://en.wikipedia.org/wiki/Schweik 'Svejk is so enthusiastic about faithfully serving his country that no one can decide whether he is merely an imbecile or is craftily undermining the Austro-Hungarian Army's war effort. This idiocy/subversion has come to be known as "svejking".' One important form of svejking is reading or following instructions literally, twisting their meaning beyond recognition and/or asking offensively stupid questions while pretending not to understand. This, coupled with occasional use of "the Czech truth" (outrageous, deadpan lying), is what you've been doing here for months. Lt. Lukas -- Resistance is futile. You've already been assimilated.
Re: Important OpenBSD errata
On Fri, 16 Mar 2007, Darren Spruell wrote: > On 3/16/07, Martin Schrvder <[EMAIL PROTECTED]> wrote: > [snip blah blah blah...] > > I want > everyone trying to make that point to think of all the software > vendors they deal with, including the commercial software vendors to > whom you pay thousands (and depending on the size of your > organization, millions) of dollars to per year. Can you say that you > get SMTP notifications from all of them? The answer, if you're in any > situation resembling what I've been in for the last decade, is no. To focus this even more, I managed some VAX/VMS machines in the 1980's, supporting about a half dozen aero engineers and programmers. The software support contract for VMS ran me around 5-7 thousand USD a year, in the dollars of the day, say $15K/yr in current money, which got us mailed magtapes when there were bug fixes or new versions, and great boxes of paper when the documentation changed. This was not the most extreme level of support available, which would have included a field engineer to come around and patch the systems within 24 hrs or such. This did not include support for such extras as the Fortran, C or Pascal compilers or other "fluff". This did not include the VMS license itself, just the support on it. And, at that time, Digital was considered a responsive, cost-effective solution, and it was. With OpenBSD, I get a system that is at least as robust, much more capable, but with support that fixes bugs before I hear of them. (And I listen.) I get this for almost nothing. Digital actually warranteed their software (unheard of these days, at least in the PeeCee world), i.e. if it didn't work, you'd get it fixed, and quickly. OpenBSD doesn't warrantee anything, but they fix things as fast as Digital used to (24-48 hrs). Did I mention what a VAX/VMS source code license cost? I seem to recall 100K$ being mentioned. I get a kick out of people who are too slack to spend the two hours of reading and twenty minutes of unattended execution time it takes to CVS or patch a kernel and compile it. I would have killed to have the VMS kernel sources. Dave
Re: BIND9 and /dev/arandom
On Sun, 18 Mar 2007, Phusion wrote: > I have a question about BIND9 that comes with OpenBSD 4.0. I just > setup BIND and am seeing the following messages in my logs. > > named[25017]: could not open entropy source /dev/arandom: file not found > named[25017]: using pre-chroot entropy source /dev/arandom > > I have looked for this and found another person asked about it a few > years ago. The post I saw was when someone was running 3.6 and the > response was as follows. > > -- > This is normal and harmless. All it means is that there was no > /dev/arandom in the chroot jail so named will continue use the > descriptor it opened for /dev/arandom before it did the chroot. > -- > > So, apparently I should always see this message correct? You could (as root) create the device in /var/named/dev if the error message is annoying. that would be: # cd /var/named/dev # mknod -m 644 arandom c 45 4 Those are the appropriate major/minor device numbers for 4.0. I assume that /var/named is your named chroot habitat. man mknod for more info. Dave -- Resistance is futile. You've already been assimilated.
Symbols in a .so
I would like to know which symbols are defined in a shareable object library, say libfoo.so.1.0. If this were an old-style library (i.e. an archive), say libfoo.a, I would use "nm". Surely there is a tool for doing this with the .so's. What is it? (it's not "strings" ;-) The .a library is not available. Thanks, Dave
Re: Symbols in a .so
On Sun, 18 Mar 2007, Woodchuck wrote: > I would like to know which symbols are defined in a shareable > object library, say libfoo.so.1.0. False alarm! The lib had been stripped during installation. Port maintainer has been notified. nm will give a useful symbol table on an unstripped libxxx.so, as will readelf -s, as Rafael kindly pointed out. Hadn't noticed that readelf thing before. No man page. Hmmm. Smells gnuish... Yeah, there's an "info readelf" for those curious about it. Thanks to all! Dave -- Resistance is futile. You've already been GPLed.
Re: Symbols in a .so
On Sun, 18 Mar 2007, Rafael Almeida wrote: > On 3/18/07, Woodchuck <[EMAIL PROTECTED]> wrote: > > I would like to know which symbols are defined in a shareable > > object library, say libfoo.so.1.0. > > I think readelf might be what you want. Yeah, that will dump out some useful stuff. Actually the problem is that the .so was from a port, and the library had been installed stripped. On an unstripped .so, nm works fine. Will a stripped .so even work as a library for ld? The one in question seems not to. Dave
Re: Symbols in a .so
On Sun, 18 Mar 2007, Philip Guenther wrote: > On 3/18/07, Woodchuck <[EMAIL PROTECTED]> wrote: > > I would like to know which symbols are defined in a shareable > > object library, say libfoo.so.1.0. > > > > If this were an old-style library (i.e. an archive), say libfoo.a, > > I would use "nm". > > > > Surely there is a tool for doing this with the .so's. What is it? > > (it's not "strings" ;-) The .a library is not available. > > Uh, you didn't simply try 'nm' and notice that it works on shared > objects? If you're looking for something that can see some of the > other structure of a shared library, take a look at 'objdump'. Nm doesn't work on stripped .so's. It does work on unstripped ones. Thanks for reminding me of objdump; that works, too. (Although it won't show a symbol table (-s) on a stripped .so. -T will show the dynmaic sym.tab. however, stripped or not). I am simply interested in knowing in which library of several possibilities a certain symbol might be defined. Objdump and readelf will do it. thanks to all who responded! Dave
Re: strange output on openbsd C code
On Tue, 20 Mar 2007, Tobias Ulmer wrote:
> /*
> * You assume that the in memory representation of an
> * unsigned [2] looks exactly like unsigned long long and you
> * expect to access the valid initialized memory of x by
> * dereferencing p.
> *
> * These assumptions are all wrong.
> */
Indeed.
The error is very similar to making assumptions about how
the internal structure of x, p and c might relate in the
commonly seen:
union roach_motel {
unsigned long long x;
unsigned int p[2];
unsigned char c[8];
} foo; /* draws bugs */
We haven't even scratched the surface of the subtle joys of
big-endian addressing schemes (note the plural) or alignment
requirements in some architectures.
> Your program is invalid. Gcc has all rights to fuck it up,
> -omg-optimized or not.
It's not strictly invalid, it just doesn't follow the programmer's
intent. This is the most difficult sort of bug to find for the
original programmer ("code blindness"), but a stranger can find it
more easily. Now if we take code like the example program, and
intersperse a few thousand lines of other code, and break it all
up over a hundred functions (and files, and bury the declarations
about 5 deep in include files), put half the bug in a library, we
have the makings of a Windoze-grade nightmare. Add some conditionals,
we can write it so that the problem with uninitialized "c" only
shows up one run in a thousand. 0xDEADBEEF comes to mind...
> Casts are basically syntactic sugar for "(i know what i'm doing, now
> shut up and stop complaining)". Remove the (void *) and compile with
> -Wall.
Some casts are "READ MY MIND, DAMN IT!". In this case, we notice
that cc -O2 and cc -O3 have different psychic skills.
I murmur again about "alignment issues", which don't exist for
the i386 architecture, as far as I know, except as an optimization.
(And certain obscure features of the PeeCee like DMA.)
The C standard is full of references to alignment.
In some architectures, I believe
void *p,*q; p=(long *)1; q=(char *)1;
p==q will be false.
To the OP: you can't do both bit-wise manipulation and arithmetic
and expect the results to be always what you think. Besides "endian"
issues and "alignment" issues, there can be questions of arithmetic
(2s-complement, 1s-complement, and others). The PeeCee has blinded
many to the rich diversity of hardware possibilities.
Sometimes you just have to drag out the assembler.
Dave
--
Resistance is futile. You've already been assembled.
Re: Saving memory on small machines
On Thu, 22 Mar 2007, David Given wrote: > I have a machine with 48MB of RAM that I want to use as a server. > > The OpenBSD kernel is a bit over 5MB. I assume that gets loaded into memory > and is not swappable, giving me 43MB left, which isn't a lot. I sent a longer ramble offlist, but onlist, the bottom line is this: you'll save some memory, a few megabytes, but if they are the tipping point between usefulness and non-usefulness of the machine, spend your time and money on Ebay, finding more memory. Sometimes you can find a couple of hundred MB for cheap, with a faster CPU, large discs, snappy ethernet and video cards, a new case and power supply, and other cool stuff still attached to it ;-). Other point: swapping (i.e. paging) is perfectly acceptable behavior in some circumstances. It used to be the "way things were". The Golden Age of cheap servers (and laptops and ...) is almost upon us, just as soon as the lemmings start going to Vista. Dave
Re: bcw(4) is gone
On Thu, 5 Apr 2007, Daniel Ouellet wrote: > And this make it even worst: > > http://www.theinquirer.net/default.aspx?article=38746 Typical of that rag. The author talks as if bcw was part of a release, not some sort of development code. Apparently GPL means "Go Piss in the Lake". ... > Where is the Open Community is going these days... To the lawyers *sigh*. RSM and his pet toad Egon have discovered the subtle joys, glories and honors of litigation, and this unwholesome appetite is spreading to a world starved for respect and admiration. All this once again shows that GPL is about free as in "free beer", not "free" as in "free will", and the forced acceptance of some sort of True Faith. What a waste. Barely worth talking about. Probably has negative worth to talk about it. If *BSD felt that way, we'd be auditing the Linux/GNU userland looking for Regents code falsely GPLed. But what a stupid thing to do. Anybody willing to sign an NDA with Mr Buesch and his crew to use their spec? Are we now in the position of having to reverse engineer a reverse-engineered Linux driver? Maybe OpenBSD could put a "click to consent" shrink-wrap license/NDA/hold-harmless on the CVS sites (like Sun had on jde) Maybe Marcus should have released a sed script (acting on the Linux code) to grab the parts temporarily needed for debugging/regression and "include"d them in his source? That would pass the GPL, I think -- copyright would only apply to the code output from sed and cpp, which would be transient. "Here's a book! Don't read it! If you read it, forget it!" (c) Woodchuck 2007. Some rights reserved, you guess which. Maybe the whole thing is Mr Buesch's idea of some sort of protracted April Fool's hoax. Dave "I may hold the patent on the off-by-one bug." -- Resistance is futile. You've already been GPLed.
Re: nonsense from OBSD 4.0 ping
On Fri, 4 May 2007, Karel Kulhavy wrote:
> I have the OpenBSD 4.0 ping and it wrote this:
>
> 64 bytes from 192.168.2.215: icmp_seq=3029 ttl=64 time=6.057 ms
> 64 bytes from 192.168.2.215: icmp_seq=3035 ttl=64 time=44.108 ms
> 64 bytes from 192.168.2.215: icmp_seq=3036 ttl=64 time=-994831.-515 ms
>^
> Parse error: minus sign not allowed between decimal dot and the decimal part.
Is "Parse error:..." the output of some program?
>
> CL<
Observe the "ping" source:
733 if (timing)
734 (void)printf(" time=%d.%03d ms",
735 (int)(triptime / 1000),
736 (int)(triptime % 1000));
your indicated triptime is -994,831,515 usec.
Expressed otherwise, that is -994831515 3300135781 c4b41365, as an
unsigned and in hex. Taking the unsigned interpretation, that would
be 3300 seconds or about 55 minutes. (triptime is a quad_t type).
I suggest a fault in your computer, some sort of glitch in the
highspeed clock... unless the ping actually took 55 minutes. You
can peruse the pellucid source to ping at /usr/src/sbin/ping.c
Perhaps, if ping times must always be positive, the printf
might be changed to
734 (void)printf(" time=%u.%03u ms",
735 (unsigned int)(triptime / 1000),
736 (unsigned int)(triptime % 1000));
Your output would then have read:
64 bytes from 192.168.2.215: icmp_seq=3036 ttl=64 time=3300135.781 ms
It would have been more helpful had you exhibited the original ping command.
I am curious about the value for the -w ("maxwait") parameter, which
defaults to ten seconds. If that was the -w you used, then again
I suggest looking for a hardware failure (or perhaps some process that
pre-empted the clock or blocked interrupts in general).
Dave
--
Resistance is futile. You've already been assimilated.
Re: US Export of Cryptography
On Sun, 20 May 2007, dreamwvr wrote: > > -- > > Mark Reitblatt > > > The entire world is not the US. The entire world AND the US is addressed > by OpenBSD. Mr Reitblatt should be advised that there are some of us in the USA that are quite pleased with and in fact grateful for a reliable, free and open source of crypto software from *outside* the USA. The thicket of law, regulation, executive decree and "discretionary interpretation" by bureaucrats, administrative law judges and others in this country is legendary, and growing more tangled with every sea change in politics. The idea that "democracy" can remedy this situation is charmingly naive and dangerously unrealistic. "Democracy" brought this situation about. Mr Reitblatt seems to believe that to be arrested, sued or otherwise harassed, drained of one's resources, and then finally, after years of litigation and other forms of immiseration (crypto export is a *crime*, involving prison), vindicated, is the same as having been left in peace initially. In the technical sense only, this is correct. This is the sort of Pyrrhic victory that only lawyers on retainer celebrate. My initial reaction to Mr Reitblatt was to wonder if he was a provacateur from a US government department intending to "plug a security loophole". This view is not justified, but the fact that I had it is itself indicative of the climate here concerning such issues -- this is now a country in which bank transactions less than about a month's wages (anything over 5000 USD!) are reported to "authorities". Everywhere one looks, one is being looked at by some "security entity". OpenBSD might find itself "vindicated" if it began distribution from the US. It might find itself bankrupted, too. It might find its hardware vanished into the black hole of an "evidence locker" or "impound lot". There is very little satisfaction in being ruined and right. The risk/reward ratio is absolutely stunning. Executive summary: There is no *need* for OpenBSD to enter this meat grinder, so there is no *reason* to do it! Stay Canadian, gents, and stay out of the US. Others would do well to follow OpenBSD's example! Dave -- Resistance is futile. You've already been assimilated.
Re: pf.conf settings
On Mon, 28 May 2007, Lontronics Mailinglist account wrote:
> Okay, found some stuff on the internet; this is it at the moment:
>
> # $OpenBSD: PF firewall rules $
>
> # ports: see /etc/services
> # 21 = ftp
> # 22 = ssh
> # 25 = smtp
> # 53 = domain
> # 80 = www
> # 110 = pop3
> # 123 = ntp
> # 631 = ipp (CUPS)
> # 6667 = irc
>
> tcp_pass = "{ 21 22 25 53 80 110 123 6667}"
> udp_pass = "{ 53 110 }"
>
> # scrub
> scrub in all
>
> # setup a default deny policy
> block in all
> block out all
>
> antispoof for { bce0, wpi0 } inet
>
> pass out on { bce0, wpi0 } proto tcp to any port $tcp_pass
> pass out on { bce0, wpi0 } proto udp to any port $udp_pass
You may wish to add pass in and out rules for icmp, to be RFC compliant.
If you are passing to 80 outbound, you may want to also pass 443
(SSL, https).
You may wish to add "log" options to the block statements, particularly
the "out" -- if you are trying to pass packets that you have forbidden,
you probably want to know that, either to allow those packets, or to
wonder where they are coming from, going to, and why.
If you are going to be using pop and irc, you may wish to evalute
allowing inbound tcp on 113, the identd/auth service. (Also enabling
it in /etc/inetd.conf). Or not.
I wonder if this setup will allow you to do dhcp. Probably during
boot, (before it takes effect, when the rules in /etc/rc are active),
but afterwards, not. This might be an issue. I dunno how dhcp
communicates, don't use it myself.
But do try logging, maybe all packets at first, to familiarize
yourself with your normal network traffic. A tcpdump process
in a little xterm can be fascinating and make debugging a more
complicated pf setup easy or possible. I use
# /usr/sbin/tcpdump -n -e -ttt -i pflog0
to watch in realtime.
Dave
Re: serial terminal
On Tue, 29 May 2007, Maurice Janssen wrote:
> Hi,
>
> I'm trying to use a VT420 serial terminal on an i386 box running
> 4.1-stable. Not as a system console, just as an extra screen to login.
> The output of the boot loader and kernel output should go to the
> monitor, as usual.
>
> The terminal is hooked up to the first serial port with a null modem
> cable. I changed the tty00 line of /etc/ttys to:
> tty00 "/usr/libexec/getty std.9600" vt220 on secure
> and sent -HUP to init. There's a getty process on tty00, but there's
> no login: prompt on the terminal. Everything I type on the terminal is
> echoed on the screen, so the cable is OK (local echo is off).
H. Look into two things, no, make that three:
1) The settings on the terminal, whether XON/XOFF or RTS/CTS
synchronization is selected, also baud rate, parity, 8/7 bits. Try
8 bits, No parity, 1 stop bit ("8N1").
2) The settings on the tty, from # stty -a /dev/tty00 when
the getty is running.
3) There are null modem cables, and there are null modem
cables. Some are just plain junk, providing only cross over of the
two data pins and if you're lucky, a ground. Others implement
various ideas of what a null modem cable should be; the opinions
of what a null modem cable differed between Digital, who made your
terminal and IBM, who designed the PeeCee.
> The funny thing is, when I start 'tip tty00' on the machine (while
> logged in at the keyboard+monitor), the login: prompt appears on the
> terminal.
Yeah, this is weird. You should be able to get the login: prompt
by at most hitting the carriage return on the 420 twice. Try to
set up everything for XON/XOFF flow control.
> When I quit tip, I can login at the terminal. When I logout from the
> terminal, the login: prompt doesn't appear (but everything I type is
> echoed to the terminal screen as before). I can start tip again, and
> then the login: prompt shows up again.
>
> I suspected a problem with the permissions of the tty00 device. After
> logout, they are set to
> crw--- 1 root wheel8, 0 May 29 21:44 tty00
This, by default, should be uucp.dialer, permissions crw-rw---,
when "at rest". When a getty is running, it should be as shown here.
> When logged in it is set to
> crw--- 1 maurice tty8, 0 May 29 22:00 tty00
> Not sure if this is what it should be, but it doesn't look strange to
> me.
>
> BTW: not sure if it is related, but when I login as normal user, the
> following warning is shown on the terminal:
> ksh: No controlling tty (open /dev/tty: Device busy)
> ksh: warning: won't have full job control
> When I login as root, I don't get this warning.
Ick. I have my suspicions, but won't voice them since they are
superstitious. They involve a brief trip to single-user mode and
running cd /dev; sh MAKEDEV all.
> Any ideas what's going wrong?
Yeah, you're using a serial terminal on a PeeCee. (sarcasm).
You are in a maze of twisty little passages, all alike. The
lamp grows dimmer. (Zork, a metaphor for debugging RS-232).
Install a terminal emulator on the box, like kermit or something
like minicom, from ports if the sometimes goofy behavior of tip/cu
annoys you (like killing its parent xterm when you give it ~.).
Hook up the terminal. See what you can do. Try things (settings).
Terminals are a PITA, as bad as serial printers. See if the 420
has a VT-220 emulation mode, if so try it. It's hard to debug them
"over the phone" (by email) like this, one needs to poke and try.
A RS232 line analyzer is real handy. There used to be various
utilities for MS-DOS that would display line status of the com ports
on the screen, much like the blinkenlights on a modem. Don't know
it they exist for Unix. Could kermit have such a feature? One has
to delve into the kernel to see these things, a forbidden zone in
Unix, unless some happy ioctl to pccom exists.
Helpful man pages: tty, tip, remote, cu, getty, gettytab, pccom
With the getty killed, try catting a "large" text file to
/dev/tty00 (as root), look for garbage on the terminal, a sign
of flow control being wrong. Try this with the terminal set
for "smooth scrolling".
A debugging test: use the same cable (if you can) and connect
the com ports of two OpenBSD boxes. Start the getty on one, and
use tip/cu/minicom/kermit on the other. Everything should work
fine. If it doesn't, the cable sucks in some way. If it doesn't
work, force XON/XOFF on both boxes. How you do this for getty is
a good question, settings in gettytab is the answer.
Dave "I already have a headache, and it's not my problem!"
Re: Can't see full boot using the console scrollback buffer
On Thu, 31 May 2007, Andris wrote: > After OpenBSD boots, it clears the screen. Then I can't see some > information, for example, the start of local daemons. All I can see > using the console scrollback buffer is this: > > > Automatic boot in progress: starting file system checks. > /dev/rwd0a: file system is clean; not checking > setting tty flags > kbd: keyboard mapping set to es > > > So you can see that a lot of info is "hidden" to me. I can see tan > information when OpenBSD boot, but not later. > > Any idea if I can "fix" this in some way? Try "cat /var/log/messages" after booting. With default settings, what you want is stored there. The previous part of booting the kernel (before booting the OS), is in /var/run/dmesg.boot Dave
Re: Can't see full boot using the console scrollback buffer
... snip ... > No information about local daemons, for example. > > Any idea why I can't see the information using the console scrollback > buffer after boot? The information detailing the start of daemons, for > example. > > Greetings. Darn. You're right. I looked before, but saw what wasn't there (in /var/log/messages). This stands to reason, one cannot log through syslogd before syslogd is started. By the same token, one cannot log to *any* disk file, before a filesystem has been mounted with write access. This is non-trivial, because / is not mounted (remounted) for write until /etc/rc is well along. In fact, it is not knowable in advance exactly when various filesystems may be mounted (due to the possibility of nfs mounts). What you are seeing on /dev/console is the standard output and standard error from /sbin/init and its various descendents (sh, sh's scripts, and so on). I don't think there is an official way to get this output anywhere other than the console. So you have two options -- the easy and the hard. The easy option is to rig up another machine with a serial port to the subject machine's serial port and use a serial console. On the second machine, your output from the boot>> prompt onwards can be readily captured to disk or wherever you'd like. Man boot.conf on how to get the console output sent to serial port. Man tip, man cu, maybe see /usr/ports/comms/minicom or kermit for terminal software. The hard option is to figure out why you can't page backwards in /dev/console. I just did a fresh, unaltered installation of 4.1_STABLE to a test/ sacrifice machine. (Painless enough to do with OpenBSD, cheer-cheer). There was no screen memory wiping on the console when rebooting. There was a formfeed/newpage stunt, early during kernel loading. After boot, and after logging in as root, I can "Page Up" into the console history, to *before* BSD booted, catching the last few lines of output from GRUB bootloader, which happens to be installed on this machine, and of course all the "white on blue" kernel load. All I can think of is that you are doing something during startup that causes loss of console buffer. I suspected "kbd" of doing this, but I can do "kbd es" without ill effect. In my case /etc/wsconsctl.conf is default, i.e. containing nothing but comments. Perhaps you are doing something with wsconsctl that causes it to have the effects you observe? Loading a character set? Try without kbd or wsconsctl during boot. (mv /etc/kbdtype /etc/XXkbdtype, mv /etc/wsconsctl.conf /etc/XXwsconsctl.conf) /sbin/getty *used* to clear the screen before issuing the login prompt, due to control characters in /etc/gettytab, in the "im" field, but that has been mercifully absent for several releases now. Perhaps you have restored that for some reason (ending over-the-shoulder snooping, say). Maybe you are doing something in /etc/ksh.kshrc or similar file. Maybe /dev/console uses your video card's memory, or somesuch. The card on my test machine is an ATI Rage XL. Yours is some sort of S3 I don't know about. Good luck, and I hope I have been of some use. Dave -- Resistance is futile. You've already been assimilated.
Re: How can I build a release without writing into the /usr/src tree?
On Tue, 5 Jun 2007, Don Jackson wrote:
>cd /home/openbsd/4.1/src/etc/../sys/arch/amd64/conf && config GENERIC
>config: cannot create ../compile/GENERIC: Permission denied
>*** Error code 2
>
>Stop in /home/openbsd/4.1/src/etc (line 11 of etc.amd64/Makefile.inc).
>
> (FYI, /usr/src -> /home/openbsd/4.1/src )
>
> Looks like make release is trying to build a new kernel in my /usr/src tree.
Hmmm. Readonly /home partition?
> 1) Is there a way to get make release to NOT build a new kernel inside
> my source tree?
The "obvious" kludge is to move .../conf and .../compile to somewhere
writable, replacing the directories with symbolic links.
An "inobvious" kludge is to mount something(s) writable on /conf
and .../compile. (cleverly having copied the relevant files there).
Unionfs used to be a cute way to do this, but that is no longer
supported. A memory file system might do the trick. (man mfs).
A dangerous kludge, or as it might be more properly called, a
"kulhavy", would be to find which Makefile(s) call for building the
kernels and remove the offending lines. There are gotchas connected
with this when it comes time to populate "RELEASE_DIR", especially
if all your kernels are not "just so" before "make release". The
way you make them "just so", of course, is to recompile them, so
why not let make release do it?
> 2) Actually, I have already built a GENERIC kernel anyway, it would be very
> nice
>if "make release" would be able to figure that out, and just use
> the already built
>GENERIC kernel. I understand it will still need to build bsd.mp,
> bsd.rd, etc.,
>but hopefully it would build those outside the source tree also.
I have a bug report that I will never file titled "Make doesn't".
"make" in the context of ports, releases, kernels and so on is not
the make we once loved, a program for compiling programs whose
source is updated. In these other contexts, it is instead a bizarre
and nearly opaque "write only" scripting language used to build
programs and systems, almost a wrapper for "autoconf", "libtool"
and concepually similar stuffs. So don't expect it to accept a
kernel that is built from up-to-date sources and config file as
being up-to-date, that is not make's true function in "make release".
(Or "make build", for that matter.) (Oh, if you mosey down the
tree away from /usr/src and don't use targets like "build" or
"release", make almost "makes" most of the time. But too often
it's a driver for "rm" and other tools already mentioned and
implicitly cursed, and this overshadows its original purpose. The
whole idea of make ~was~ to avoid rm'ing all intermediates ("make
clean") all the time, but this is now a common first target -- there
are, ahem, human-factor reasons for this (doltish lusers poking
at source with sticks), but there may be stuff now that cannot
be built properly without a "make clean" preliminary step, for thus do
tails wag dogs.)
The "obvious" kludge above will solve your "build this outside the src
tree" problem in the readonly-dodging sense.
I am feeling uneasy, though. "make release" may wish to do some other
"minor" and "incidental" (but abending) writes in /usr/src in the release
process. You are well-positioned to discover them ;-)
An unrelated gotcha with "make release" is that svnd0 must be free
before you start, and must stay free until it's used towards the
~end~ of the "make release". So if you use svnd0 routinely for
something, don't. Update: in 4.1, there is now a variable VND which
defaults to svnd0. So if you use svnd0, you can have "release"
build its ramdisks on a different svnd device by saying so in
/etc/mk.conf or on the command line. (This is a nice improvement!).
Dave
--
Resistance is futile. You've already been assimilated.
Re: open(hd0a:/etc/boot.conf): Invalid argument
On Thu, 7 Jun 2007, Shag Bag wrote: > I've installed OpenBSD4.1 from the 3 CD set which I purchased shortly after > it was released and have been running it on and off ever since. However, > this morning I tried to boot it and it came up with the above error (full > error listing below). > > I re-installed the whole OS yesterday (everything except bsd.mp and > game41.tgz) and it was working fine. The only thing I did after re-install > was add a few packages and ports and compile the LookXP source packages from > http://lxp.sourceforge.net. I have not knowingly touched the boot.conf file > at all so I'm at a loss as to how the above error is showing. > > I have read the biosboot(8) man page but it didn't help. I am new to > OpenBSD having come from a brief linux background and would appreciate any > help. > > I could always simply re-install OpenBSD4.1 again but this would be a last > resort as: > i) I'd like to know what the cause of the problem is and how to fix it - > in case it happens again; > ii) I wouldn't learn anything if I simply reinstalled everytime; and > iii) I've spent a lot of time configuring icewm to get it like I want and am > loathed to go through this process again. > > The full error list I'm getting is: > > Loading... > probing: pc0 apm mem[632K 2046M a20=on] > disk: fd0 hd0+* > >> OpenBSD/i386 BOOT 2.13 > open(hd0a:/etc/boot.conf): Invalid argument > boot> Well, evidently there's something wrong with /etc/boot.conf, right? First, if you haven't done it already, print out the man page for ed(1), even from a linux system. On paper. So boot the installation CD again. Instead of "update" or "install", select "shell" At the prompt (#), mount your root partition. Do I know what it is? No. I'll guess that it is either /dev/sd0a or /dev/wd0a Anyway, mount it: # mount /dev/sd0a /mnt Now you can look at (and edit, using "ed(1)") the file in question. (Maybe you get errors? Maybe you need to run fsck on that partition before mounting it?) # cat /mnt/etc/boot.conf Tell us what you see. You can edit it. The routine PeeCee installation doesn't even need this file to exist. To edit: # ed /mnt/etc/boot.conf What no manpage? Didn't print it out? Don't know how to use ed(1)? Expected ed to pop up "help windows?" Thought I was lying? Here's your second chance: # mount /dev/sd0d /mnt/usr Assuming sd0d is where your /usr is. Forgot where that is? # cat /mnt/etc/fstab read what it says. Maybe your /usr is on the same partition as /, (linux having poisoned your mind in this regard), in which case it's already mounted. (partition = what disklabel makes. Not what fdisk manipulates). The man page is right there /mnt/usr/share/man/cat1/ed.0 Try to "more" it. I don't recall if "more" is available on the bsd.cd ramdisk, if not you're going to have to read quickly. Try running /mnt/usr/bin/more Would rather use vi? Well, maybe it's there under /mnt/usr/bin/vi Maybe it will even work. But this is diverging from topic. Summary: you can mount and manipulate your harddrive(s) from the "installation" CD using sh. It is not scary, just touchy. The simple manipulation might be just: # mv /mnt/etc/boot.conf /mnt/etc/boot.conf.bad and try rebooting from the harddisk. I have an uneasy feeling that something else may be wrong. If you found this post highly useful and full of new info and startling concepts, there's a openbsd-newbies list at sfobug.org. Visit http://sfobug.org for further info. Dave
Re: on the remote root login in OpenSSH
On Thu, 23 Nov 2006, Darrin Chandler wrote: > No. It would be simple enough to disable everything, but that wouldn't > be functional. OpenBSD has an excellent track record for security, yet > many useful things are enabled by default. Do you *really* believe that > nobody has thought about turning off root ssh in the default configs? Of > course they have. Yet it remains enabled. Selecting a secure password > for root is YOUR responsibility. You know, I seem to recall that many versions ago (maybe even as far back as 2.xx) root login on ssh *was* disallowed by default. I recall being bitten by it, too, on "remote" (other-side-of-the-room) installations on headless machines. At worst you have a small window during installation in which root logins are allowed, before you shut them off by chroot'ing as Paul outlined in his post. btw, that chroot to /mnt may not be obvious to some, and a little advisory (or even a menu choice) at the end of the install script might be a good use of a 100 bytes or so. Halt now (H), Chroot to installed system (C) or shell (S)? [S] Dave -- "Confound these wretched rodents! For every one I fling away, a dozen more vex me!" -- Doctor Doom
Re: on the remote root login in OpenSSH
On Fri, 24 Nov 2006, Joachim Schipper wrote: > While I'm inclined to agree with the last part, setting up a botnet > isn't *that* hard. Particularly in the domain .kr, which Igor sees intermittent attack from. Korea has the perfect "ecosystem" for such a botnet -- very large numbers of pretty fast CPU machines (Made in Korea, very good, fast enough to run a bot without the user noticing ;-), a very, very large amount of ADSL or cable-modem connections, (and good world-wide trunks, too), high percentage of unpatched or neglected Windoze machines of ancient OS release, since Internet use is very wide-spread and most users are (therefor) very naive, a government that does not do gross censorship as in China, and in fact is not too interested in security or related issues. Hence all the @#$% spam from .kr -- the bot nets already exist, are in the hands of professional spammers, and any organization intersted in scanning lots and lots of hosts, say knocking on ssh ports, can hire them and run them without a lot of expertise. Now let's say that that person interested in scanning/mapping the world and starting stealthy attacks against ssh open machines happens to be a Chinese governmental agency, and they want deniability. After a scan of a netblock, you find some hosts that look real secure, all nicely buttoned up, no rpc crap hanging out for the world to probe, no goofy toy services running -- you fingerprint that box as OpenBSD, latest release. The ssh port is open. This is a high-value machine, probably. People don't buy tanks and hire armed guards to protect their lawnmower. BTW, this is the *sole* security disadvantage to OpenBSD I've ever really noted: it's like a new bank with a big, shiny vault and a sign out front, "Gold stored here! Security is our Lifeblood!". Armored trucks are seen driving in and out through the heavily guarded gates. Serious badguys are going to be interested. I get probed all the time, even sitting on the end of a 56K dialup, including brute ssh hacks, when I have ssh open. I've thought of hanging a sort of Tiergrube off that port, but at 56K it would also DoS myself. > > > I also rely on having the abiltiy to install/upgrade remotly and ssh > > > into the system post install. With root access blocked off, well...kind > > > of hard! > > > I am curious... how can OpenBSD be remotely installed on a computer > > without a [serial console]? How can the installer be run remotely > > without a device that the operating system calls "console"? > > Well, at least theoretically, one could just replace the install script > by one that does whatever you want it to, without asking any questions. Yup, build a custom bsd.rd. Not that hard for upgrading purposes, no operator on the remote end is required. I don't know how to do this for a clean install on, say, (pardon me) a Windoze machine that is being improved, without having a remote operator install a floppy or CD (or other appropriate installation medium for other arch's) at the remote end. Dave -- "Confound these wretched rodents! For every one I fling away, a dozen more vex me!" -- Doctor Doom
Re: on the remote root login in OpenSSH
On Fri, 24 Nov 2006, Paul de Weerd wrote: > Hi Dave, > > On Fri, Nov 24, 2006 at 01:50:52AM -0500, Woodchuck wrote: > | At worst you have a small window during installation in which root > | logins are allowed, before you shut them off by chroot'ing as Paul > | outlined in his post. > > I'm not sure I understand, what window is this ? Before (and after) Apparently no window at all, perhaps the one painted on my wall by some of the refreshments yesterday. I was ignoring changing it after installation and before first boot. The window would have been between first boot and hupping sshd with the no root option. Dave -- "Confound these wretched rodents! For every one I fling away, a dozen more vex me!" -- Doctor Doom
Re: Bug in ksh // Improvement for tar ?
On Tue, 5 Dec 2006, Uwe Dippel wrote: > 2 humble suggestions to make my server OS of choice even better. > > I seem to have found a bug in ksh: > Here is a sample that doesn't behave as I'd expect it to. > > # demo="" > # if [ "$demo" == "-n" -o "$demo" == "-e" ]; then > > echo bar > > fi > # demo="-n" > # if [ "$demo" == "-n" -o "$demo" == "-e" ]; then > > echo bar > > fi > ksh: [: -n: unexpected operator/operand > > IMHO, I'd consider it a bug, since the correctness of syntax must > not change with the value of the variable. It's probably more of a feature. Probably the correct name for it is a "wart". The nature of name expansion in ksh, and the syntax of the [ and other things is such that demo="" should correctly expand to , but the syntax of [ wants before a ==. So in this sense, it is not a bug. It's a disappointment, maybe. The idiom used when a null value of "demo" matters is: # demo="" # if [ X"demo" == X"-n" -o X"demo" == X"-e" ]; then > echo bar > fi You'll see this throughout scripts in OpenBSD, see /etc/rc for examples > AFAIK, this syntax is considered correct generally; if not, please > advise me. If you mean "generally in the world of Bourne and Korn shells", then no, it's not correct. If you mean "generally when considering language design" then I agree. It all hinges around the nature of name expansion in ksh/sh, i.e. the way sh parses a command line, which is in various passes. The man page for ksh will provide insight. Dave > Secondly, I still need to resort to gtar for the backup of my users' home > directories (you know those silly long filenames in WORD). > I understand it is just a frontend to pax ? If it could process The system tar is a frontend to pax. I don't know about gtar.
Re: pkg_add -r -F update
On Tue, 5 Dec 2006, Karel Kulhavy wrote: > man pkg_add says "-r Replace existing packages". > > I did pkg_remove transcode, then installed transcode I compiled from > sources, then removed all files containing "transcode" in their name from > the system and then tried to replace the OpenBSD binary package again. > > pkg_add transcode-1.0.2p0.tgz says Collision: the following files already > exist > some with same md5, some with different > pkg_add -r update transcode-1.0.2p0.tgz should replace the package acording > to the manpage. It doesn't - prints the same error. > > The manpage further says "use -F update to force the replacement" > When I use pkg_add -r -F update transcode-1.0.2p0.tgz, I get the same errors. > > Why doesn't pkg_add do what's written in the manpage? > > CL< Somehow, an evil hacker got into your system, r00ted it, and broke it by deleting a bunch of files from protected system directories, probably under /usr/local. Maybe you have a Virus or other Pest. I assume (since you do not say it explicitly) that the transcode you "compiled from sources" was not done via /usr/ports/multimedia/transcode; therefore the pkg_* subsystem believed that no transcode package was installed; therefore "replacing" was not a good idea, perhaps it fell back to a simple "add". Then pkg_add detected files (whose names the evil hacker must have filtered from your post, check that your sendmail binary has not been 0wn3d!) that it felt were part of transcode. Foolishly assuming that transcode was installed (from outside the package/ports system), it refused to damage that installation. It is possible that the evil hacker missed these files since they did not contain the string "transcode" in their names, and yet there they were in the transcode packages "+CONTENTS" file. Had it worked, you could have posted, instead, that a bug in pkg_add overwrote your custom transcode installation. pkg_add probably decided it shouldn't decide what to do. Try it again with the -i switch. Dave the Patient -- "Lokot' blizok, da ne kusaesh'."
Re: Compiling netpbm
On Tue, 5 Dec 2006, Karel Kulhavy wrote: > Hello > > I want to use xpm2ppm, but it doesn't work because it says > [EMAIL PROTECTED]:~$ xpmtoppm < vnc/img_0.xpm > xpmtoppm: Input file has line that is too long (longer than 2048 bytes). > > Obviously, someone programmed with fixed-size buffers. Perhaps he had a reason. Maybe it was a bad reason. > > I would like to increase the compiled-in buffer size from 2048 to 4096 and > try again. I would like to get the source for netpbm somewhere, change it > and compile. However it turns out to be an impenetrable obstacle: > > - The OpenBSD website describes only some CVS method which seems to involve > getting > sources for all programs in the operating system and I don't have space for > that: Filesystem 512-blocks Used Avail Capacity Mounted on > /dev/wd0a 74935160 70114912 107349298%/ > - Getting sources -> web -> ports -> graphics -> netpbm there are no sources, > only some auxilliary files > - when I download the official netpbm 10.26.34 source and say "y enter > openbsd enter enter enter enter library filename or 'none' [libjpeg.so] > libjpeg.so.62.0 JPEG header directory [default] ==> /usr/local/include > libtiff.so.37.3 /usr/local/include libpng.so.4.2 /usr/local/include > libz.so.4.1 /usr/local/include" (the filenames were determined using locate), > the compilation of netpbm crashes with > libopt results: ' -L/home/clock/netpbm-10.26.34/lib -lnetpbm -ljpeg.so.62' > /usr/bin/ld: cannot find -ljpeg.so.62 > collect2: ld returned 1 exit status > gmake[3]: *** [ppmtompeg] Error 1 > gmake[3]: Leaving directory > `/home/clock/netpbm-10.26.34/converter/ppm/ppmtompeg > > Is it possible to compile netpbm on openbsd from the sources without extensive > OpenBSD maintainer expertise? > > CL< Please run the following script as root: #! /bin/sh if ! cd /usr/ports/graphics/netpbm ; then cd /tmp ftp ftp://ftp.openbsd.org/pub/OpenBSD/4.0/ports.tar.gz cd /usr tar xzvf /tmp/ports.tar.gz fi cd /usr/ports/graphics/netpbm more Makefile make extract ls # see the patches directory? cat >patches/patch-converter_ppm_xpmtoppm_c <<__EOF__ --- converter/ppm/xpmtoppm.c.orig Tue Dec 5 06:53:10 2006 +++ converter/ppm/xpmtoppm.cTue Dec 5 06:54:52 2006 @@ -38,7 +38,7 @@ #include "nstring.h" #include "mallocvar.h" -#define MAX_LINE 2048 +#define MAX_LINE 32768 /* The maximum size XPM input line we can handle. */ /* number of xpmColorKeys */ __EOF__ make build # tempis fugit make install # now test it. I took a guess that the file xpmtoppm.c was the source # of your problem. I changed the define. I did not look for ramifications # from that change, I don't care, since I am not going to use the program. # You, on the other hand, should spend some time seeing how that change # may reverberate through the package. man ports echo Woodchuck, OpenBSD user
Re: Commands don't work after rm -rf /*
On Wed, 6 Dec 2006, [EMAIL PROTECTED] wrote: > Jason Dixon wrote: > > I wrote a script that tested inode performance by removing unwanted > > blocks. It was pretty simple, so I tested it first against the first > > slice (it's the smallest, so it should be a quick test). However, > > something happened after I ran the script and the system no longer > > responds. Even rebooting the system, it just hangs where I would > > expect to see the boot> prompt. > > > > Perhaps there is some sort of performance inhibitor in the kernel > > that stops users from performing these delete tests against a whole > > partition? If not, surely there should be some way to protect stupid > > users from themselves. Or perhaps I should have just called the > > command (rm -rf /) manually, rather than by ksh? What's with this > > shell anyways, give me bash! > > I ran your test and got the same result, so this is a bug in OpenBSD and > they should fix it. This has been fixed in -current. Dave
Re: Bug in ksh // Improvement for tar ?
On Wed, 6 Dec 2006, Uwe Dippel wrote: > Woodchuck: Thanks for the confirmation of tar being frontend to pax. Then, > what is the good reason that the frontend kind of suppresses the > abilities of the underlying routine ? > > Thanks, > > Uwe I suspect it is to maintain compatibility with the most ancient tars. There are a lot of ancient archives sitting around on 12" 9- and [gasp] 7-track tape, punch cards, etc, that would be lost forever if tar changed. Tar, as an archive program, should be always backward-compatible. Nothing is as frustrating as a write-only tape. Sometimes we forget that this system is now ~30 years old, which is really ancient for software, so it will accumulate a few warts and false teeth with time. For example -- the system call "creat(2)" has five letters because of a limitation of an early compiler. Should we change it to "LetsMakeANewFile(2)"? You can use a tool daily, and it does its job, but lacks a feature that the similar tool in a neighboring village has -- Still you'll never really want that feaure, you'll never think of it -- I think this comes into play, too. But I cut my unix teeth on SysV, so sometimes I wonder what happened to a SysV switch or feature. Dave -- "Confound these wretched rodents! For every one I fling away, a dozen more vex me!" -- Doctor Doom
Re: mounting an svnd device on /var
On Thu, 7 Dec 2006, Jacob Yocom-Piatt wrote: > it's not clear to me where the best place to mount a disk image is using > vnconfig for the whole /var partition. this should obviously happen after > mounting /usr. > > advice appreciated. > > cheers, > jake For a start, I'd *guess* it could be mounted immediately after the file-system containing its "regular file" (and of course /usr) is mounted. If this file-system is not nfs, then that is at the first occurences of "mount" in /etc/rc. (Around line 203 in 4.0). You would add your vnconfig and mount command there. You now have a "non-standard" /etc/rc. You want it mounted before logging and any other process or daemon that uses /var is run, including daemons that chroot to /var, notably named. You probably want them running on the svnd, not "underneath" it on whatever /var was before mounting the svnd. Note that if you plan on encryption, the vnconfig command will hang waiting for the key. It uses a call to getpass(3) for the key, which will read from /dev/tty. Usually /etc/rc executes with a /dev/tty so I think that if you use vnconfg -k or -K in /etc/rc, a human will have to intervene at boot time to enter the key. (I don't know a cute, simple way (i.e. a shell trick) to execute vnconfig without a controlling terminal, so it could read from its stdin (presumably a disk file or maybe from some dongle-like Sekrit Krypto Device) or if that would be a good idea anyway.) You could hack vnconfig to read the key from a file, but that's kinda insecure. I don't know your threat model. See man getpass(3). Hoping for further comments, Dave -- [In] all human groups at all times there are the few who rule and the many who are ruled. -- A. Livingston
Re: unable to login
On Wed, 10 Jan 2007, Chuck Robey wrote:
> I have a problem with my Zaurus, let me paint the scenario. I am a rank
> newbie with OpenBSD, so I was trying (as a startup experiment) to build
> all of it. I have my main machine sitting nearby (running FreeBSD
> current, at which I have years of experience), so I NFS mounted the
> little Zaurus's /usr/src and /usr/obj from my FreeBSD host. I used cvsup
> to get the entire OpenBSD archive, then checked out copies of ports and
> and src (forgot to add ports to my list up on top, I had 3 remotely mounted
> filesystems). OK, I went ahead, built a kernel successfully, and did a
> "make build".
>
> I was kinda shocked to find that the install was included in the build
> target, so this shows me to be a little bit stupid, that I didn't read
> it well enough to make sure, but that's not the problem. I had the new
> kernel
> installed, and it seems to boot ok, but for both of my two user's, once
> I enter my password, it immediately cycles back to "login:" again. I tried
> giving it tons of control'c's but that wouldn't catch it, so I cna't get
> logged in.
>
> Look, as far as emergencies go, I have the orignal Linux OS sitting in
> back as a emergency, and it does work, so if there's no better fix,
> I could reinstall everything, or maybe just my /etc/ but could anyone
> give me guesses as to what sort of screwup I perpetrated, so as to
> keep me from getting logged in? Else, I will probably do this again,
> and I really, really like to learn from my mistakes, you know?
>
> Thanks for your guesses, folks...
Something got broken, and I suspect it was in /etc, but I can't picture
a simple make build in /usr/src as the full culprit here. (This shouldn't
mess with /etc/*. As of yesterday, when I did one (4.0 stable) it didn't.)
so first try this:
at the BOOT> prompt, enter -s ; this should give you "single user mode",
i.e. a root shell on the console, with no filesystems save / mounted.
You can at this point inspect /etc/master.passwd and see what is up.
(Are your users there? what's in their password fields?) Are other things
in /etc messed up? Things that you customized, like /etc/myname, /etc/mygate,
probably /etc/rc.conf, others.
If you find something obvious, you can fix it. First remount / for writing
(mount -u -o rw /) Then you can mount /usr to get some tools (mount /usr
should do it).
Do "dmesg | head" and see what the kernel thinks it is, then read on:
(You will need to mount /usr to get /usr/bin/head, or just "dmesg" and
be quick on the ^S or ^C, or pipe the dmesg to /tmp/foo and use "ed"
on it. In ed, try 1,10p to display lines 1 through 10. Use q to quit.
When you get the system working, print out the ed man page and put it
in your desk.)
You should see something like this:
[EMAIL PROTECTED] root]# dmesg | head -2
OpenBSD 4.0-stable (GENERIC.MP) #3: Wed Jan 10 11:55:06 EST 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP
(Probably just "GENERIC" not "GENERIC.MP").
A possible source of your problem: when you checked out the sources, what
tag did you specify in the cvs command? It should have been of the form
-r OPENBSD_4_0. If you didn't specify a tag, you did not get "STABLE",
you got "current", the experimental/developmental branch. You did not
want to do that ;-) If you did, then boot the installation CD and do
a reinstallation. On your freebsd box, you can check the tag by
displaying the file {some path known to you}/src/CVS/Tag. If it's
not "TOPENBSD_4_0" wipe out the hierarchy and re-fetch it. this tag
business applies to the X and ports sources, too.
man 8 release (very most excellent reading, refreshing and engaging,
with a plot you just can't put down.)
man 1 cvs (packed full of vital goodness.)
Dave
Re: slow configure script...
On Fri, 12 Jan 2007, poncenby smythe wrote: > list, > > when any configure script is checking for standard header files > (stdlib.h, memory.h) it hangs for a few seconds on each file, as if it > is taking this long to actually find each file on the disk. which i > guess is actually happening. making the script take about almost five > minutes to complete. > > any ideas why this could be happening? > > below is dmesg... 534MHz/150MB/150GB sounds like a laptop. I'll assume it's not in some sort of slow-down power-saving mode. Sounds like it's probably running X. If you're running several applications (I'm thinking specifically of Mozilla or other mem-eater) besides the configure, it is quite feasible that you are swapping. (Check this with "top" or "systat swap"). Another reason for slow configures/compilations is c++, which is molasses in January. Configure scripts often run the compiler. Do you have a specific script example? Some port you're compiling? Try it after a fresh boot, before starting X, i.e. from a text console. 150MB is not a lot to run X, a browser, and other stuff. Never thought I'd say that, but it's true these days; applications are bloated beyond belief because of assumptions about cheap memory. I assume you have a nice big swap partition defined. 500MB won't hurt. Dave
Re: MD5 sum of /bsd on freshly installed system/?
On Mon, 15 Jan 2007, Gregory Edigarov wrote: > Hello, > > It would be greatly appreciated if somebody can make an md5 checksum of the > generic kernel. > Need to check that as my OpenBSD 4.0 install hangs while booting at the very > early stage. The kernel embeds information that is different each time it is compiled. If you are using the kernel from the official release, the MD5 sum should be available at the official ftp site. The file would be ftp://ftp.openbsd.org/pub/OpenBSD/4.0/i386/MD5 (assuming i386 is your architecture). For the generic kernel MD5 (bsd) = e8f67a2fd90f98d5b4edee9fe837c2fd > I was trying to install my openbsd on a reletively old pc, all went just fine. > I.e. I've boot from cd, made partitions, etc... > Then on the first boot from HDD it hanged after it recognized the second USB > controller. > I suspect something is wrong with memory/HDD but I can't investigate it right > now. Could it be a kernel bug also? Can't tell. Repost as a separate request, and include the dmesg if possible. (This can be tricky if the machine won't boot. Note that using the installation CD, you can establish a working networked system and copy the dmesg to another machine, maybe using ftp. (I don't remember if scp is available on the install media).) Really -- whoever can help you with this has to know all the details. Dave -- [In] all human groups at all times there are the few who rule and the many who are ruled. -- A. Livingston
Re: Compiling OpenBSD Kernel With Generic SMP
On Wed, 24 Jan 2007, Demuel I. Bendano, R.E.E wrote: > Hi, > > As you can see, there are only few entries in the GENERIC.MP and if it > compiles indeed how about the device drivers usually found in the GENERIC? > Would it be included when GENERIC.MP compiles? YES. That's what the "include" at the top of GENERIC.MP is all about. as root: cd /usr/sys/src/arch/i386/conf config GENERIC.MP cd ../compile/GENERIC.MP make clean && make depend && make Now the MP kernel is in the file "bsd" in the current directory. You can install it however you want. If you say "make install", it will be installed on the current machine as /bsd, the default kernel. The previous kernel will be in /obsd Dave
Re: /etc/rc.local changes not picked up by first insecurity report
On Thu, 25 Jan 2007, Will H. Backman wrote:
> Running 4.0 RELEASE in i386.
> I installed yesterday, and today, received my nice daily insecurity
> output. I love this report because it is a great way to document my
> initial configuration changes.
> I noticed that it didn't pick up my changes to /etc/rc.local that I made
> to start mysql.
> Looking in /var/backups, I do see etc_rc.local.current, but it contains
> my changed version.
> Is /var/backups seeded with initial versions that match the files in the
> install?
> Thoughts?
It (the system) will not pick up rc.* changes unless you reboot.
Start mysql by hand once. Perhaps I misunderstand your question.
("it didn't pick up" is unclear to me.)
I do not believe /var/backups contains anything until it is backed up
by the /etc/daily script. Nothing will document /var/backups better than
the source code which writes files to it.
You might wish to manually run /etc/weekly and /etc/monthly once after
installation.
Dave
Inetd rejecting connection from privileged port
... On port 37 (time, UDP). If timedc from a NetBSD host attempts clockdiff with an OpenBSD host (same ethernet, no firewalling involved), sending from a privileged port, OpenBSD (inetd, I presume) does not respond. If the UDP packet originates from an unprivileged port (say 63,xxx or 19,xxx), then all is happy. Why is OpenBSD set up this way? I recall a philosophical security issue for this, and would like to refresh my memory, so that I might offer an explanation to some people at Net. I can't seem to find a discussion anywhere in /usr/share/man/*. They are taking the position that it is upside down to require an unprivileged source port. What are the issues? Thanks, Dave
Re: Inetd rejecting connection from privileged port
On Fri, 26 Jan 2007, Brian Candler wrote: > > They are taking the position that it is upside down to require an > > unprivileged source port. What are the issues? > > The code is here in /usr/src/usr.sbin/inetd/inetd.c: > > if (port < IPPORT_RESERVED || port == NFS_PORT) > goto bad; > > The only reason I can think of is to avoid your host being used as a > reflector to attack services on other hosts. Yes, I believe you're right. Thanks for refreshing my memory. This is a heuristic to stifle such attacks. The only breakage I've seen is that the "timedc(8)" program of another BSD uses a privileged source port for a minor feature (detecting hosts that are whole days off in time). The NetBSD inetd deals with the DoS problem by checking "port" against an array of likely problem source ports. > For example: attacker sends a UDP packet to you on port 37, with spoofed > source IP address and source port 53. Without this check, inetd would send > its response back to the spoofed IP address on port 53, so it looks like you > are trying to attack someone else's DNS server. > > In the case of UDP 'time', the attacker can't control the response you send, > but can predict it. Other services launched from inetd might give the > attacker more direct control over the packet sent, with the most extreme > example being "echo" :-) Yes, two hosts talking UDP to each other's echo datagram ports is probably the archtypical DoS -- of the hosts and any network they're on. Chargen is pretty vicious, too. Doubtless this and other similar attacks also account for the rate-limiting -R switch (and its default) to inetd. > The assumption here of course is that the only services worth attacking are > on ports <1024 or 2049. This still doesn't prevent your box being used as a Quite. NetBSD makes the similar assumption that those are the only "commonly" attacked/attacking services. I notice that in OpenBSD, this policy leads to encouraging honest clients to use unreserved ports, which then can lead to sometimes eliminating the setuid requirement for clients that non-root has a reason to run. So it's a double win. > DoS repeater, but that's a pretty fundamental limitation of simple UDP > request-response exchanges. Ah, for the happy days when people played nice, and an attack consisted of a manually typed password, and an unlisted modem telephone number was a serious security measure, and a source port <1024 meant you probably knew the sender personally. Thanks for your comments! Dave
Re: SVND -k and -K
On Sat, 27 Jan 2007, Don Smith wrote: > On the newer versions of OpenBSD, there is -K added as > an option for SVND. > > I always used the -k option with a strong key and no > salt file. > > Is the original -k method still secure, given a strong key? No. But that's hearsay. Here's what I heard someone say: "The biggest drawback of svnd is its lack of security in the general use case. It is vulnerable to an offline dictionary attack. That is, you can generate a database mapping known ciphertext blocks on the disk back into pass phrases that can be accessed in O(1) without even being in possession of the disk. What's even worse is that the same database will work on any svnd disk. It is possible--and perhaps even likely--that large agencies such as the NSA have constructed such a database and can crack a majority of the svnds in the world in less than a second. The way that one prevents an offline dictionary attack is to use a salt in conjunction with the pass phrase," Source: http://www.onlamp.com/pub/a/bsd/2005/12/21/netbsd_cgd.html?page=3 Disclaimer: I am not a cryptanalyst. Maybe that's all FUD and blown smoke. Advice: Use the salt. How can it hurt? It depends on your threat model. If it's a laptop and you don't want some random thief or whoever he sells your stolen property to to read your disk, -k will suffice. If you're worried about a large government, there are still other considerations (rubber hoses for one), but the salt won't hurt. If I recall the source code correctly, using -k, you are already using salt -- of zero. The salt is used when generating the key from the passphrase, and won't slow down the actual disk en/decryption, so salt is a win. Dave -- The law has converted plunder into a right and lawful defense into a crime. -- Frederic Bastiat, 1850
Re: SVND -k and -K ERRATUM
On Sat, 27 Jan 2007, Woodchuck wrote: > Disclaimer: I am not a cryptanalyst. Maybe that's all FUD and blown > smoke. > > If I recall the source code correctly, using -k, you > are already using salt -- of zero. Checked the source code, I was wrong. In the -k case, the passphrase is passed without processing to the vnd routines. In the -K case it is passed to pkcs5_pbkdf2 for massage and hashing. Dave the Erring
Re: build question
On Mon, 29 Jan 2007, John . wrote: > Hello list > > When XF4 is brought to -stable, does the machine have to be rebooted > for the changes to take effect? It doesn't say so explicitly in the > FAQ. > > cheers It should suffice to stop X and restart it. That includes xdm. Dave -- "I believe that banking institutions are more dangerous to our liberties than standing armies." -- T. Jefferson
Re: SVND -k and -K ERRATUM
On Tue, 30 Jan 2007, Don Smith wrote: > I looked at the source code. In /src/sys/dev/vnd.c, it > has the lines: > > blf_ecb_encrypt(vnd->sc_keyctx, iv, sizeof(iv)); > if (encrypt) > blf_cbc_encrypt(vnd->sc_keyctx, iv, addr, bsize); > > This looks like it encrypts the key using the iv of > all zeroes. True, it doesn't add any salt using -k, > but it doesn't look like the user's key is the key > that is actually used. I am curious what happens if > the user enters a key longer than 448 bits. If the > user enters a 456 bit key, would the extra 8 bits just > be dropped from the key? You're looking in the wrong place for salt. The user's entered key and salt in the -K case are hashed together in vndconfig (userland), generating the key that is the actual one used in the kernel routines (blf*). The salt doesn't survive vndconfig as a separate entity. Compare the "case 'k':" and "case 'K':" code in vndconfig.c This is an incomplete comment; the fate of the user entered key should be traced out to its bitter end. This will involve the initial setup of blf when the svnd is mounted. > I was playing around on my system, and it seems that > you can enter around 248 or so of the 256 possible > characters. Exceptions include CTRl+C,CTRL+D, and a > few others. A problem here is that evidently getpass() is reading the terminal in "cooked" mode. Unfortunately, the characters that are consumed in "cooking" can vary depending on user settings (man stty). This can lead to surprises if you get too loose about what control (and high ascii, maybe) characters you use in input to getpass(). An svnd device you mount one day from an xterm might be mysteriously unreadable when you mount it from a text console during a single-user session. The source for getpass() is in /usr/src/lib/libc/gen/readpassphrase.c You might wish to analyze that routine with respect to what state of "cooking" it places /dev/tty or STDIN into. You're one step away from "hexadecimal armor" or whatever the PGP folks call it. ;) Considerations like the preceding paragraph as well as internationalization issues are why PGP keeps its various things as ascii-hex characters. They also simplify storage on paper in the bank deposit box. Dave -- "I believe that banking institutions are more dangerous to our liberties than standing armies." -- T. Jefferson
Re: Pf - Private address blocking
On Mon, 19 Feb 2007, martin g wrote:
> Hey all
>
> I have a question about blocking private addr. with pf.
>
> I have defined the reserved addresses acording to RFC 1918 in a table
>
>
> My default rule is :
>
> block in on $ext_if
> block out on $ext_if
>
> pass in on $int_if
> pass out on $int_if
>
> 1. With this 2 rules defined is it still recomended to block private addr.
Yes. RFC1918 source/destination packets should be kept from the
public internet. Any coming to you are bogus. Any leaving your
router are bogus; they should both be dropped. Such packets are
"non-routable".
> If it is then:
>
> Computers on my network have IP's from block 192.168.0.0/16 let's say
> 192.168.1.100 to 192.168.1.105
> I make another table called
>
> What is the correct rule? Do i negate table lan in a rule
>
> block in on $ext_if from any to { , ! }
> block out on $ext_if from { , ! } to any
>
> or do i negate ip's in a table like so
>
> table { !192.168.1.100 , ...}
>
> tnx for reply
Neither. You want to block them all at the ext_if. You want to use
nat to map your LAN addresses to something routable. If you forward
packets from an RFC1918 address, those packets will soon be dropped,
probably by the next host to forward them.
Dave
Re: spamd unnecessarily abrasive?
On Tue, 20 Feb 2007, Peter N. M. Hansteen wrote: > J Moore <[EMAIL PROTECTED]> writes: > > > Isn't this a bit "over the top"? > > Well, people don't read these strings at all unless they're looking at > spamd source code or doing a "telnet yourhost.tld smtp" for debugging > purposes. The message you quote here is essentially just a preserved > version of the telnet to smtp case. In their present form, don't these messages provide a clear fingerprint for the next generation of spamware to read and then heed? I suppose that problem can be dealt with when it occurs, probably faster than spammers can follow. Dave
Re: spamd unnecessarily abrasive?
On Tue, 20 Feb 2007, Theo de Raadt wrote: > > In the case of a greylisting type of solution, it seems that > > identification would be especially devastating since the work-around > > is so trivial. Unless my understanding is very wrong, the whole > > effectiveness of the solution depends on the spammers not realizing > > the difference between a "normal" MTA and one that greylists. > > If a spammer knows I am running spamd because he can detect it, and > then disconnects, no spam makes it througg -- no spam is delivered. > There is no workaround for the spammer, except to act as a regular > "follow the RFC, and retry", which most of the spammers don't do (and > which we want them to do, since then they are easier to fight). Well, yes and no. I don't understand how causing spammers to modify their 'bots to move greylisted victims to a "failed-451" list and rerunning it after 30 minutes would be more easily fought. I do not see that causing the spammer of tomorrow to become RFC compliant in the area of retry intervals. My impression of 'botnets and the hosts comprising them is that software of the complexity of sendmail could be hidden from their clueless users and apparently indifferent "virus protection scanners". But complex software is not needed to work around greylisting. > In fact, there are spammers who ARE noticing that greylisting servers > look (or behave) different, and they are disconnecting and not sending > spam through them. Thus, no spam is delivered. > > But you don't get it, do you? Stopping spam from being delivered is > the reason for doing all this in the first place! You have it > entirely backwards. > > I think you had better book yourself into a course on logical > thinking. We are saying that spamd provides the spammer with a hook to improve his spamming. I do not see how mimicking sendmail responses for a 451 would aid spammers, but it might not make a difference. I assume a competant spam lord has some level of 451's above which he will implement and deploy improved spamware on his 'botnet, i.e. it is thr 451 error itself that will trigger the improvement, not the 250 taunts. In that respect, I stand corrected. I do not see how RFC compliant spam is better than noncompliant spam. As for logic, we have a situation in which greylisting works only until it is effective above some threshold. If all mail receivers implemented greylisting Wednesday, the spam lords would have the work-around deployed on Thursday, or so I fear. If spamming were still the province of the cottage industry spammer with warez of the "Bull's Eye Gold" vintage, I would have no fear. Dave
Re: Compiler error during porting exercise
On Wed, 2 Aug 2006, Michael C wrote:
> Hi,
>
> I am trying some porting examples to winscw and I have a question:
>
> Why is it that the MetroWerks CodeWarrior 3.1 cannot handle the following?
>
> in header file (pcb.h):
> intin_baddynamic (u_int16_t, u_int16_t);
>
> in c file (pcb.c)
> int
> in_baddynamic (a, b)
> u_int16_ta;
> u_int16_tb;
> {...}
>
> CodeWarrior complains with a 'identifier redeclared' error.
>
> Is it because the declaration is a different style to the definition?
> I am not use -strict, maybe the compiler just can't handle it?
>
> I have searched the whole tree and there is only one declaration and one
> definition.
I cannot address the CodeWarrior directly, but sometimes things glitch
when the type of declaration made in pcb.h are made.
try instead in pcb.h
int in_baddynamic(u_int16_t a, u_int16_t b);
I agree, both types should compile. If this fixes it, you might complain
to MetroWerks.
Dave
--
Experience runs an expensive school, but fools will learn in no other.
-- Benjamin Franklin
Re: Rebuilding for stable.
On Sun, 20 Aug 2006, Eric Stewart wrote: > Hello everyone, > > I've order and received the OpenBSD 3.9 disks. I've read through > the majority of the documentation at least once and two or three > times in certain sections. I've installed the OS about 4 times as dry > runs and I'm preparing for the final OS load for a production box. > > After I've run the CD installation, I've created a task list for upgrading > it to OpenBSD 3.9-stable (I'm not experienced enough for current > yet). I've decided I don't want build any ports and instead use > packages for adding third-party software. > > This is the current task list I ran during the last install and it > works, but I know there is a bunch of stuff in there that relates to > ports and I want to strip that out. > > # Install source tree from CD > mount /dev/cd0a /mnt > > cd /usr/src; tar xzf /mnt/src.tar.gz > > cd /usr; tar xzf /mnt/XF4.tar.gz > > tar xzf /mnt/ports.tar.gz This is the only part of the various commands that has anything to do with ports. If this is the only line of the script that you have removed, then you have removed all the parts relevant to ports. Dave
Re: ksh vs bash
On Sat, 26 Aug 2006, Default User wrote: > I just know I'm going to regret asking this, but . . . > why does OpenBSD have ksh as the default shell, rather than bash? > > Also, what ever happened to the statically-compiled bash that used to be > available in OpenBSD packages? > > BTW, thanks for making ksh the default shell for root - IMHO much easier > to learn than csh, especially if you're used to bash. > > No flames, please. Just honest thoughtful discussion. A better question is "why do others use bash instead of a more standards-compliant shell"? I suspect the answer might be that ksh was a little late being freed (the original ksh, not pdksh). And besides, bash isn't yet free, and probably never will be, and there's enough GPL code around BSD already. Bash is not good (not portable) for scripting, and the interactive bits are not compelling reasons to use it. It has some annoying differences from sh(1), and in some cases implements SysV ideas, and this ain't SysV. (Consider the bash internal "echo" command for an example. Compare 'echo "\nfoo"' and '/bin/echo "\nfoo"'. This whole internal command thing is a bit irritating and possibly bad. Very bad for root. Rule for root: no surprises.) Perl has obviated the need for some sort of interactive interpreted system language. Bash has some new and expanded features, but not enough to make its use compelling. Or so I think. Dave -- Experience runs an expensive school, but fools will learn in no other. -- Benjamin Franklin
Re: sysctl modifications during install?
On Sat, 26 Aug 2006, Edd Barrett wrote: > On 25/08/06, Matthew R. Dempsky <[EMAIL PROTECTED]> wrote: > > > > On Fri, Aug 25, 2006 at 05:38:19AM +1000, Scott Radvan wrote: > > > Or am I missing something which could allow the install to use all > > > available bandwidth? > > > > Can you first choose S for shell, run the necessary sysctl commands, > > then exit the shell and start the install process as usual? > > > > > Read the post again, > > The binary is absent from the install media. > > Regards Why not newfs a floppy, cp the /sbin/sysctl to the floppy (it is already staticly linked), mount the floppy during install... I think you get the picture. Would this not work? It might stick with a floppy install, I don't recall when install umounts the install floppy so the device is free. For a cdrom installation, I don't see a problem, though. As far as that goes, hard drives on the target machine might be available during installation, too. These can be usually mounted/umounted at will. Even if these hds are to be partitioned and newfsed later, you can run progs from them during the early phases of installation. BSD installation is very flexible. Dave -- Experience runs an expensive school, but fools will learn in no other. -- Benjamin Franklin
Re: Serial Console and /etc/ttys
On Wed, 6 Sep 2006, Edd Barrett wrote:
> > You'll need to send a more detailed email to misc@
> >
> > Thanks
> >
> > Tom
> >
>
> The /etc/ttys line reads:
>
> tty00 "/usr/libexec/getty std.9600" vt100 on secure
>
> Which according to the faq is fine?
> http://openbsd.org/faq/faq7.html#SerCon
>
> Regards
>
> Edd
You'll need to use a null modem cable from the terminal to the computer.
Your original symptoms sound vaguely like you're not using a null
modem cable.
Is getty running? (Did you HUP init?) Is getty respawning very
rapidly?
Small semantic note in the interests of clarity: it's called a
"terminal" not a "console". This was confusing some, maybe.
("Console" is a function, i.e. used for booting, receives certain
system messages. "Terminal" is a thing; a terminal may be used
as a "console", but also may be used as a simple login device.)
Dave
--
Experience runs an expensive school, but fools will learn in no other.
-- Benjamin Franklin
Re: Serial Console and /etc/ttys
On Wed, 6 Sep 2006, Edd Barrett wrote: > If it works with the sun box, I assumed it's the correct cable? Not necessarily the case, said the grey old admin, sighing and wincing with the facial tic he thought he had lost in the mid 1990's. Getting a serial terminal to work is one of the bitchier bits of olde-tyme sysadmin work. (It is not as bad as getting a serial printer to work.) Google for "null modem pinout" and you should get a sample of the sort of witchcraft to which desperate admins have had recourse over the decades. There are different kinds of null modem cable, varying by mfg and "philosophy". Null modems were at one time a seductive sink for the sort of creativity that now is reserved for quirky software license schemes and object-oriented programming. An RS-232 cable can have, alas, 25 lines. Since only 7 (2 data, 1 gnd, 4 control (2*(I'm busy, I'm alive))) are useful in any *practical* sense, the other 18 (as well as the 4 "useful" control lines) can be combined in a variety of intriguing ways to achieve or suppress some obscure feature. This includes crossing-over, looping back, joining together, and hard-wiring to ground or to certain voltages. Sometimes a tiny resistor or capacitor might find its way under the shield of the cable, cunningly soldered across the backs of two pins. DEC cables usually work between DEC terminals and DEC computers. Sometimes DEC cables work between genuine DEC terminals and PeeCees. Hooking up an IBM terminal (even emulating (often this means "mocking") a vt100 or vt220 -- this emulation may not extend to the finicky hardware parts) to a Sun with a Sun (?) cable, experiencing the rare joy of "working terminal" does not completely predict behavior of that same terminal and cable with a PeeCee. Some sly manufacturers may have stooped so low as to create "console" ports that require a "straight" cable; this is where "philosophy" can rear its head. PeeCees don't do that, at least the "standard" (har-har) ports don't. Try setting "local" in /etc/ttys. How you make that IBM terminal give up trying to set/read various control lines I don't know. Before you throw in the towel, try a simple 3-conductor null modem cable, simply carrying through signal ground and swapping the two data lines, in conjunction with "local" in /etc/ttys. After that barely works, you will have to figure out how to set XON-XOFF flow control with stty maybe. Some of this junk can be set with tset, too. Dave "My VT-101 works and I'm not touching it again." -- Experience runs an expensive school, but fools will learn in no other. -- Benjamin Franklin
Re: Serial Console and /etc/ttys
On Thu, 7 Sep 2006, L. V. Lammert wrote: > On Thu, 7 Sep 2006, Woodchuck wrote: > > > On Wed, 6 Sep 2006, Edd Barrett wrote: > > > > > > > If it works with the sun box, I assumed it's the correct cable? > > > > Not necessarily the case, said the grey old admin, sighing and > > wincing with the facial tic he thought he had lost in the mid 1990's. > > > Nah, .. forget the documentation! Save the gray cells and get yourself an THe documentation for these terminals are often full of lies and wishes. Perusing the source for terminfo/termcap will convince anyone of that. Each line in there is written with blood, sweat and tears. > 'RS232 breakout box'. Most electronic stores have them, as do most network > vendors. Most PCs use DB9s, but if you can't find a breakout box with DB9s > you can also get 25->9 adapters (just be sure to get the right 'sex'). > > A breakout box will show if the data leads are crossed - you need to see > 'lights' on 2 AND 3 (TX & RX) to know your connection is correct. If > not, just swap 2 and 3. MOST terminals will run quite happily with 2, 3, > and gnd (5 or 7). Unless you do smooth scroll on a VT-xxx and aren't using software (XON-XOFF) flow control. Old terminals have very small data buffers. If the terminal will handle a curses app like top(1) at 9600, it's probably set up OK. 19200 baud is the proof of the pudding. > Knowing what is actually happening is a lot nicer than just trying one > cable after another. It sure is, but it's still painful. > > Lee Breakout boxes... shudder... line analyzers... shudder and flinch. I used to do this with an Ohmmeter with a paperclip soldered to each lead. Sometimes I'd bribe a hardware guy with doughnuts to use his oscilloscope. Dave -- Experience runs an expensive school, but fools will learn in no other. -- Benjamin Franklin
Re: can www execute sendmail -t?
On Fri, 8 Sep 2006, Bryan Irvine wrote: > i have a peice of code that doesn't seem to work. It compiles and > even executes fine but the email never goes anywhere. > > maillog doesn't even show anything trying. Apache is not running chrooted. > > #define SENDMAIL_PATH "/usr/sbin/sendmail -t" > #define RECIPIENT "[EMAIL PROTECTED]" > #define SENDER "[EMAIL PROTECTED]" Note subtle changes made from your original. > FILE *mail; > char sendmail[512]; > sprintf(sendmail, "%s %s", SENDMAIL_PATH, RECIPIENT); use snprintf here, this is exactly the sort of code that some joker will try to do a buffer overflow on. > mail = popen(sendmail, "w"); Check return from popen. Abort if NULL. As in: if(!(mail=popen(sendmail, "w"))) err(1, NULL); /* man 3 err */ You might want to add fflush(stdin); /* man 3 popen, under "BUGS" */ and fprintf(mail, "To: %s\n", RECIPIENT); here. Sendmail -t does not generate this header, and without it aggressive spam blockers might can the message. >From man 8 sendmail: -t Read message for recipients. To:, Cc:, and Bcc: lines will be scanned for recipient addresses. The Bcc: line will be deleted before transmission. You may not need the recipient in the invocation of sendmail. (You don't). > fprintf(mail, "From: %s\n", SENDER); > fprintf(mail, "Subject: test email.\n"); > fprintf(mail, "\n"); > fprintf(mail, "blah\n"); > pclose(mail); if(pclose(mail)) err(2, NULL); > > also worth noting that i'm a terrible C programmer. It's possible > that elsewhere I have a bug, but I just want to eliminate whether www > can even execute sendmail. > > --Bryan If apache is not chrooted, it should run this. Login as www (or however apache runs) and try it from the command line, then from a standalone small program. You will have to make www a log-in-able user with vipw first. -- Experience runs an expensive school, but fools will learn in no other. -- Benjamin Franklin
Re: can www execute sendmail -t?
On Sat, 9 Sep 2006, Matthew R. Dempsky wrote: > On Sat, Sep 09, 2006 at 09:50:16AM -0400, Woodchuck wrote: > > > FILE *mail; > > > char sendmail[512]; > > > sprintf(sendmail, "%s %s", SENDMAIL_PATH, RECIPIENT); > > > > use snprintf here, this is exactly the sort of code that some joker > > will try to do a buffer overflow on. > > Assuming RECPIENT is actually something that will be user > controllable, doesn't he need to worry about quoting RECIPIENT and > making sure it doesn't start with a dash? Sounds reasonable. I was assuming that RECIPIENT would eventually be user input. I suggest not having it in the popen() call, but let sendmail scan the recipients from a To: header or even a Bcc: if that's needed. > Does OpenBSD have a popen(3) replacement but with an exec(3)-like > interface instead of a system(3)-like one? Easy enough to write one's own with a call to pipe(2) and some sleight-of-handle with dup2 and friends, depending on need. Stevens' "Adv. Prog. in the Unix Env." has the canonical examples. Offhand, though, I can't think of an existing library routine. The OP is not so hot on C programming, he says. (I refer him to the book just mentioned, which is truly "how to write real Unix programs", should he like to improve his skills at the feet of a master.) Dave -- Experience runs an expensive school, but fools will learn in no other. -- Benjamin Franklin
Kernel swelling
Tag OPENBSD_3_9, GENERIC.MP kernel (i386) seems to have grown by 1.1 MB in size between 5 Aug and 9 Sep. -rwxr-xr-x 1 root wheel - 7621080 Sep 9 10:11 bsd*<- MP kernel -rw-r--r-- 1 root wheel - 7565469 Sep 9 10:11 bsd.sg <- single proc -rwxr-xr-x 1 root wheel - 5507544 Aug 5 14:41 obsd* <- Previous MP Can anyone offer any clues why? Just curious. (This is not a "strip" issue). There don't seem to have been any noticeable patches or CVS activity. Dave -- Experience runs an expensive school, but fools will learn in no other. -- Benjamin Franklin
Re: can www execute sendmail -t?
On Mon, 11 Sep 2006, Bryan Irvine wrote: > > if(pclose(mail)) > > err(2, NULL); > > that did it. I don't understand why though. Got a cluestick handy? Not really. That's just a common idiom for making a system call and aborting if there is an error. Something else "did" it. We diverge off-topic here. Dave -- Experience runs an expensive school, but fools will learn in no other. -- Benjamin Franklin
Re: Further: Debugging printfs in OpenBSD lkm module
On Fri, 22 Sep 2006, Chris 'Xenon' Hanson wrote: > Chris 'Xenon' Hanson wrote: > > I think I can sort out the problem if I can just get a few debug printfs > > to spit out some bits of info at certain times. But, I'm not an experienced > > BSD kernel guy and I've been unsuccessful in doing so. > > Is this the wrong list to be asking this sort of stuff on? I'm racking my > brains trying > to figure out how to get the driver to tell me what's failing. Maybe blip out > morse code > in the PC speaker? I'm just not familiar with the restrictions and > capabilities available > to me when working inside a kernel device driver. I'd suggest you browse the source for similar drivers and see how they communicate. I haven't done much kernel hacking for a *long* time, and at that time the way to talk from the kernel was with 'printk', so called to avoid conflict with the userland printf. However, that is now all gone. So... *why not put in some printf's and see what happens?* worst case, the kernel locks up or panics. So boot your old kernel and scratch your head. You *know* you can do this, because you see the kernel speaking to you whenever it boots or otherwise writes something to the console. So just look for examples in the source code. (cd /usr/src/sys; find . -type f | xargs -n100 grep -l print ) ought to provide plenty of examples. (Several thousand). Kernel is not magic code sprinkled with fairy dust; it's just our old friend C. Intuition tells me that the output of these kernel printf's is to /dev/console. Dave -- Experience runs an expensive school, but fools will learn in no other. -- Benjamin Franklin
Re: Spamassassin install from ports fail.
On Wed, 27 Sep 2006, Hans Almqvist wrote: > Hi all! > > I am trying to install Spamassaassin from the ports tree on an OpenBSD 3.9 > system. > > I have removed /usr/ports an downloaded a fresh copy starting from scratch. > I did one prior run with make which of course gave the same result. > > I get the fallowing: *Error in package*: > > > # cd /usr/ports/mail/p5-Mail-SpamAssassin/ > # make > ===> p5-Mail-SpamAssassin-3.1.0p0 depends on: p5-IO-Socket-SSL-* - not found > ===> Verifying install for p5-IO-Socket-SSL-* in security/p5-IO-Socket-SSL > ===> Checking files for p5-IO-Socket-SSL-0.97 > `/usr/ports/distfiles/IO-Socket-SSL-0.97.tar.gz' is up to date. > >> Checksum OK for IO-Socket-SSL-0.97.tar.gz. (sha1) > ===> p5-IO-Socket-SSL-0.97 depends on: p5-Net-SSLeay->=1.21 - not found > ===> Verifying install for p5-Net-SSLeay->=1.21 in security/p5-Net_SSLeay > ===> Building package for p5-Net-SSLeay-1.25p0 > *Error in package*: > does not exist > ===> Cleaning for p5-Net-SSLeay-1.25p0 > rm -f /usr/ports/packages/i386/all/p5-Net-SSLeay-1.25p0.tgz > *** Error code 1 Hmmm. Works for me. Just rebuilt the p5-Net-SSLeay-1.25p0 package from source. My source: MD5 (/usr/ports/distfiles/Net_SSLeay.pm-1.25.tar.gz) = 87de8a06802fbb63c7c85e89eedbe139 Try again. Could you have run out of disk space or had some other sort of transient error? Dave
Re: Serial control of LCD display
On Tue, 3 Oct 2006, Jeff Quast wrote: > On 10/2/06, Peter Bako <[EMAIL PROTECTED]> wrote: > > I am trying to get a CrystalFontz 632 serial display to work with an OpenBSD > > box. Under Windows I can just connect the display to a com port, run > > Hyperterminal and send text directly to it, so I assumed that I could just > > send a data stream to /dev/tty00 under OpenBSD and make it work as well. > > Unfortunately it is not turning out to be anywhere that simple. > > So far, neither OS does any more than the other. > > > If I use cu or tip and connect to /dev/tty00 and 19200 then I can send data > > to the display, but eventually I need to be able to send data to it from a > > shell script. Any attempt I make to send data to it (such as cat test > > > /dev/tty00) results in an error of "sh: Cannot create /dev/tty00: > > Interrupted system call". > > > > I've tried to mess with the stty command to setup the serial port (open it > > up, set the speed, etc), but no luck, that error always comes up. Can > > anyone point me to the right direction on this? > > > > Thanks, > > Peter > > Peter, > > I would write what you need in C. I can help you along or start you > out with ~30 lines to do the job if necessary. It is very simple if > you are even just partly familiar with C. After 5 or so lines of > initializing the device, its just basic file i/o operations. > > If you are more comfortable with python or perl, these can probobly > handle the job as well. > > as for being able to use stty, then echo to it, I don't think its > possible. Anyone? In the ancient days, one first had to own the tty device so that one's stty's to it would "stick". This was done with a kludge/cliche in shell scripts like ( cat /dev/null >/dev/ttyxxx; sleep 100) & then followed by stty and other stuff. I've probably got the idiom in the "cat" wrong. It may have been "cat /dev/null". The idea is to "own" the device by opening it and holding it open. It's been maybe 20 years since I had to do this. It shouldn't be necessary, but used to be, because in shell scripts, you "lost" the device after every command, and it would be reset to default values. If you were going to diddle with flow control, speed, and other things, you needed to retain your settings across shell commands. I apologize in advance if this is a System Vism or is so obsolete as to be laughable. Dave -- Of a truth, few men desire freedom, the greater part are content with just masters. -- Sallust
Re: timezone anomalies
On Fri, 23 May 2008, frantisek holop wrote: > nor can i recall this ever being an issue while i was in CEST for years. when > i copied the camera files they were not off by 1-2 hours depending on daylight > saving... > > -f Set your camera to UTC and be happy. The times *in the file system* are in UTC. They will be displayed in localtime. See the source code for ls(1). Recall that there are (still) large numbers of unix machines which are used simultaneously by interactive users in different timezones. On such machines, there is a /etc/localtime for the zone where the machine resides (or where users think it resides ;-) and users set TZ in their .profile or similar files. I'm not aware of cameras that embed zone info in their jpegs. Are there such? Usually you just see a date time thingie. Among your options, you forgot the whole set of variations where the BIOS does daylight/summer time corrections. Invariably, the BIOS is set up for general US rules, and wrong ones at that. Only BIOS = UTC makes any sense. Windoze can get used to it. BIOS = localtime is a stupid lazy idea from a place famous for stupid lazy ideas. Dave -- The future isn't what it used to be. -- G'kar
Re: [OT] C code
On Sun, 25 May 2008, deoxy wrote:
> Hello.
>
> I dont know if this a cuestion for this list, but I think is it a valid
> cuestion...
> I reading a book recomended in http://www.openbsd.org/books.html The book is
> "Advanced programmig in the unix environment".
> In this book I read Figure 3.1 but this not compile. the error is:
>
> $cc F3_10.c
> /tmp//ccnsuA79.o(.text+027): In function 'main':
> :undefined reference to 'err_quit'
> /tmp//ccnsuA79.o(.text+0x74): In fuction 'main':
> :undefined reference to 'err_sys'
> /tmp//ccnsuA79.o(.txt+0xdf): In functiion 'main':
> :undefined reference to 'err_dump'
> collect2: ld returned 1 exit status
>
> The source is:
>
>
> #include "apue.h"
> #include
>
> int
> main(int argc, char *argv[])
> {
> int val;
> if (argc != 2)
> err_quit("usage: a.out ");
> if ((val = fcntl(atoi(argv[1]), F_GETFL, 0)) < 0)
> err_sys("fcntl error for fd %d", atoi(argv[1]));
You might be happier using the err(3) stuff from the standard
library.
See man err
I would replace err_quit(stuff) with errx(1, stuff)
err_sys(stuff) with warn(stuff)
and so on, using err or errx to force the program to end
and dump core, or warn or warnx to keep executing.
Some (old) unix versions may not have err, errx, warn, warnx.
Look in the back of the book and verify that the err/warn stuff
is doing what you expect.
Dave
Re: timezone anomalies
On Sun, 25 May 2008, frantisek holop wrote: > hmm, on Fri, May 23, 2008 at 11:56:22PM -0400, Woodchuck said that > > Set your camera to UTC and be happy. > > and have rubbish exif info in every picture? no thanks. > at least that is OS independent and the only correct data > no matter what. > > this is like saying, set your watch to UTC and when > looking at the time, do the math yourself... Well, you can lead a horse to water, but you can't make him drink. man 2 stat. Read and learn. Dave
Re: chown
On Thu, Jun 4, 2009 at 3:52 AM, Steve wrote:
> I am trying to use chown -R to selectively change permissions on files.
>
> A series of files are contained in many folders under the root data folder. No
> files are stored in the data folder itself.
>
> Running
>
> chown -R user:group /data/*.dat
This command will attempt to descend through directories named "*.dat".
Since there are no such directories (unixspeak for 'folder'), no descent
occurs.
>
> run
> from /data generates an error indicating no files match. If I move a
> .dat
> file into /data the ownership changes in that folder but not those
> below.
Correct behavior.
>
> chown -R user:group /data/*
>
> works as expected
>
> Is there a way to selectively change files recursively ?
>
something with find(1).
Try
find /data -name "*.dat" -exec chown user:group {} \;
But understand it first. Understand the quoting. man find.
Dave
--
Caution, this account is hosted by gmail.
Strangers scan the content of all mail transiting such accounts.
Re: chown
On Thu, Jun 4, 2009 at 5:13 AM, Woodchuck wrote:
> On Thu, Jun 4, 2009 at 3:52 AM, Steve wrote:
> something with find(1).
>
> Try
> find /data -name "*.dat" -exec chown user:group {} \;
>
> But understand it first. Understand the quoting. man find.
>
> Dave
I should add that this and related solutions have the desired
property of doing what you say you want to do -- change the ownership
of certain files named *.dat -- but they do not change the ownership
of the various directories in the tree. So to anticipate the next post,
"Now the new owners can't read/delete/get-a-ls the .dat files!!", you may need
to change the permissions on the directories. How to do that is left
as an exercise, hint man find (-type d) and man chmod.
Dave
--
Caution, this account is hosted by gmail.
Strangers scan the content of all mail transiting such accounts.
Re: What is the "nice" process state?
On Sat, 27 Oct 2007, Karel Kulhavy wrote: > I am raytraing a video with a command "rt" and the "top" is showing this: > > CPU states: 48.4% user, 48.7% nice, 3.0% system, 0.0% interrupt, 0.0% idle > [...] > PID USERNAME PRI NICE SIZE RES STATEWAIT TIMECPU COMMAND > 29174 clock 79 10 33M 15M run -0:00 4.25% rt > > What is the "nice" state? I know what userspace, system, interrupt handler > and idle task is, but nice? > > CL< man 1 nice. man 1 top. man 3 sysctl vide KERN_CPTIME The nice value is added to the basic priority of a task. The higher the "nice", the less likely a task is to get CPU time, so called because it is being "nice" to other users. It's part of an ancient unix work-around for not having proper prioritized batch queues and a more versatile scheduler. The standard joke is that there actually was a user who once voluntarily ran nice on a time-sharing system. Top's 48.7% nice here is telling you that the CPU is spending 48.7% of its time executing tasks that are "niced". If this includes processes with negative "nice" values, I do not know; you could peruse the kernel source or conduct an experiment to discover that, if you care to. Dave
Re: What is the "nice" process state?
On Sat, 3 Nov 2007, Karel Kulhavy wrote: > > > PID USERNAME PRI NICE SIZE RES STATEWAIT TIMECPU COMMAND > > > 29174 clock 79 10 33M 15M run -0:00 4.25% rt > > > > > > What is the "nice" state? I know what userspace, system, interrupt handler > > > and idle task is, but nice? > > > >From the replies I got (none of which actually answered my question) it looks > like the "nice" state might be a state where the nice value != 0. Or less than > zero would also make sense. But it could be also that OpenBSD has the nice() > function like some other operating systems for giving up the scheduled time > back to the system and then the nice state might show amount of time > given up this way. So - what is the nice state printout actually? >From my ancient answer to you, and I quote: "Top's 48.7% nice here is telling you that the CPU is spending 48.7% of its time executing tasks that are "niced". If this includes processes with negative "nice" values, I do not know; you could peruse the kernel source or conduct an experiment to discover that, if you care to." I also referred you to two or three relevant man pages. If that doesn't answer your trolling, disengenuous, never-read-a-manpage, low-grade, losing, pre/sub-newbie question, then answering your questions is impossible. You are not worth further effort, kid.
Re: Remembering Jun-ichiro Hagino
On Fri, 2 Nov 2007, Bob Beck wrote: > * Adrian Fisher <[EMAIL PROTECTED]> [2007-11-01 11:22]: > > This thread is the first I have heard of him. Who is (or was) he? > > > > A. > > How unbelievably [EMAIL PROTECTED] You can't even have the decency to > google his > name before you spout your ignorance here, in an incredibly > insensitive manner. Are you really that lazy that you can't google > "itojun" and I feel lucky? - Instead you need to post here in a way > that makes all the developers, myself included, wonder why we even > read this lists to see posts like this from people who are too lazy to > even look up the name of someone who was instrumental in helping to > write and improve a lot of they software you're using, at least if > you're on this list because you run OpenBSD. > > Your post would be on par with asking on this list who the > hell this Theo de Raadt was. > > -Bob Shucks, really. I'm the ultimate outsider, and I've heard Itojun's name and nym since the dawn of the 'net, it seems, and have exchanged emails with him on certain subjects, I believe back in the days when the pmax port was a current subject. The man was a seemingly inexhaustible well of energy coupled with good cheer. A hacker's hacker. May he rest in peace. His death is a loss to those who never had the privilege to know him. "The light that burns twice as bright burns half as long." (Ridley Scott, "Blade Runner") (A quote from his webpage). That would be www.itojun.org, for the totally bereft of clue. Dave
Re: /tmp permissions, I don't get this...
On Sat, 3 Nov 2007, Daniel wrote: > Hi! > > Case 1: > $ id > uid=1000(leva) gid=1000(leva) groups=1000(leva) > $ ls -ld /tmp/ > drwxwt 4 root wheel 512 Nov 3 13:05:03 2007 /tmp// > $ touch /tmp/test && ls -l /tmp/test > -rw-r- 1 leva wheel 0 Nov 3 13:09:04 2007 /tmp/test > $ rm /tmp/test && ls -l /tmp/test > ls: /tmp/test: No such file or directory > > I can create and remove files in and from the /tmp directory. This is > the expected behaviour (at least for me). > > > Case 2 (I've added myself to the wheel group): > $ id > uid=1000(leva) gid=1000(leva) groups=1000(leva), 0(wheel) > $ ls -ld /tmp/ > drwxwt 4 root wheel 512 Nov 3 13:05:03 2007 /tmp// > $ touch /tmp/test > touch: /tmp/test: Permission denied > > ^^^ I can not create the file in /tmp, although I got world write > permissions to it. It seems if I'm in the wheel group and the wheel > group owns the directory, then only the group permissions counts? > (sounds lame, but I can not think of other reasons). > After changing the /tmp directory's group permissions to -wx, I can > create and remove files from it while I'm in the wheel group. > > What could cause this behaviuour? Evidently, the permission check moves left to right, so to speak. Case1, can you do it as user (root)? No. Can you do it as group (wheel)? You're not in group wheel, ignore group permissions. Can you do it as other? Yes. (with the added features of the sticky (man 8 sticky) bit.) Case 2, you're denied by the group permissions. Evidently creat or stat or whatever bails out at this point. The permissions 1703 (rwxwt) *do* state that group wheel should have no access to /tmp. So this looks like "expected operation". 1703 is a fairly weird set of permissions, giving "other" more privilege than the group. This might be useful, though, if you wanted a directory from which members of group "leper" were excluded. Are SysV, Posix, Linux and Old BSD semantics all the same here? (I dunno). Use 1777 and be happy. Oh -- don't think of it as "world". The proper term is "other". You've given an example where that is relevant. (user-group-other). If you're "user" or "group", you're not an "other". Dave -- You don't have to like businessmen to like capitalism.
Re: Problem with xl interfaces
On Sun, 4 Nov 2007, Limaunion wrote: > hi all! I've been using OpenBSD during the last 2-3 years mainly running > it as a firewall. > > I've an old machine (486 + 48MB RAM) and yesterday decided to make > some improvements: upgrade it from 4.0 to 4.2 (new installation) and > replace the two NICs, switching from NE2000 clones (RTL8029) to 3C905B. > The problem is that i'm getting ton of this messages which > bring down the two interfaces: > > xl0: reset didn't complete > xl1: reset didn't complete > xl0: command never completed! > xl1: command never completed! > > I found that man xl already has some information about 'command never > completed' but in this case the driver does not continue to function > normally. Is this problem a combination of old hardware with the xl > interfaces ? or are this interfaces crap too ? switching to a newer > machine (pentium 166) may help ? or should I buy another brand (which) ? I'll go with Nick and say return to the ne2k's until they fail, or if upgrading, I'd recommend nothing less than a Pentium Pro level machine at 200 MHz. These are available on the curb for next to nothing these days, and many were "server grade" machines originally, with decent SCSI busses, decent ATA, decent PCI in general. I'm using two of them at present, both Toshiba Equium brand, twin CPU possible, using Intel Natoma chipset motherboards in tower cases with large power supplies. One is the inevitable firewall/router, (92MB RAM and never swaps) the other serves as an X-terminal (392MB RAM) with an upgraded ATI video card on its PCI. They have dual onboard 100Mhz intel ethernets, Adaptec SCSI onboard, also sound capabilites. To the 486 user, this is all luxury in abundance, two major generations more "modern". There are (i.e. I have) similar spec machines from Compaq, although these are quirky and subject to not working with OpenBSD (disk recognition problems, and Compaq used a bizarre BIOS scheme involving a hard-drive area.) Stay away from them, or use NetBSD on them. Somebody? Should I document this SCSI-disk recognition bug, or is it too ancient to be of interest? It came in at either 3.9 or 4.0. The Compaqs I have are throwaways anyway. There are some 100Mhz IBM brand (fxp) ethernet/PCI cards around (ebay), these work fine on OpenBSD after a firmware update (available from NetBSD, just boot them once on NetBSD, and they're updated and run fine on Open). Dave
Re: What happened to my virtual consoles?
On Sun, 4 Nov 2007, Matthew Szudzik wrote:
> I just installed OpenBSD 4.2. When I run X, I no-longer have access to the
> virtual consoles. When I try to switch to a virtual console (by pressing
> CONTROL-ALT-F2, for example), the screen goes black for a few seconds and
> then my X session reappears.
>
> Moreover, when I attempt to shutdown the system, X stays running and I
> never the see the "The operating system has halted" message.
>
> Is there a way to fix this problem?
>
> I invoke X by including the following line in my .profile file
> startx
> And my .xinit file only contains the following three lines
> xset s off
I don't do this. Perhaps I should.
> xmodmap -e 'add Mod4 = Super_L'
I do not do this.
> exec fluxbox
I do this more-or-less (see below).
>
I have a similar problem from time to time, identical symptoms.
I attribute it to an X problem.
my fix is to ssh to the problem machine from another, or to
login as root over a secure com port. Then kill the X server
and restart it. In my case, the X server and machine is being
used as an X-terminal, so I start X as
"Xorg -query host_name_offering_xdm"
I think the problem is related to bad behavior by fluxbox (run on
another host, in my case) and the X server, possibly related to screen
blanking or some sort of "focus grabbing".
When the problem manifests, I can see tiny noise on the X screen
(in my case it is displaying a dead-to-the cursor xdm login box),
that responds to console input... I can hit CTL-ALT-F3, say, and
blindly type in a root login followed by shutdown -r now command...
and the machine reboots.
I cannot reproduce this problem at will -- but have seen it once
under 4.2/xenocara, after initial installation on this machine
last week; it has not reoccured, but eventually it will.
> My dmesg is as follows:
snipped...
My dmesg:
OpenBSD 4.2 (GENERIC) #375: Tue Aug 28 10:38:44 MDT 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium Pro ("GenuineIntel" 686-class, 256KB L2 cache) 199 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV
real mem = 402223104 (383MB)
avail mem = 381026304 (363MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 02/07/97, BIOS32 rev. 0 @ 0xfd980
apm0 at bios0: Power Management spec V1.2 (BIOS mgmt disabled) (BIOS managing
devices)
apm0: APM power management enable: unrecognized device ID (9)
apm0: AC on, battery charge unknown
apm0: flags 1b0102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI BIOS has 8 Interrupt Routing table entries
pcibios0: PCI Interrupt Router at 000:07:0 ("Intel 82371SB ISA" rev 0x00)
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc/0x1 0xd/0x4800 0xd4800/0x6000 0xda800/0x6000
0xe9000/0x1000! 0xea000/0x2000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
fxp0 at pci0 dev 6 function 0 "Intel 8255x" rev 0x02, i82557: irq 10, address
00:a0:c9:49:c5:b8
nsphy0 at fxp0 phy 1: DP83840 10/100 PHY, rev. 1
pcib0 at pci0 dev 7 function 0 "Intel 82371SB ISA" rev 0x01
pciide0 at pci0 dev 7 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0
wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
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 0, DMA mode 1
uhci0 at pci0 dev 7 function 2 "Intel 82371SB USB" rev 0x01: irq 9
ahc0 at pci0 dev 9 function 0 "Adaptec AIC-7880" rev 0x00: irq 11
scsibus1 at ahc0: 16 targets
sd0 at scsibus1 targ 2 lun 0: SCSI2 0/direct fixed
sd0: 2047MB, 3511 cyl, 11 head, 108 sec, 512 bytes/sec, 4194303 sec total
sd1 at scsibus1 targ 3 lun 0: SCSI2 0/direct fixed
sd1: 4148MB, 5168 cyl, 10 head, 164 sec, 512 bytes/sec, 8496960 sec total
ahc0: target 4 using 8bit transfers
ahc0: target 4 using asynchronous transfers
sd2 at scsibus1 targ 4 lun 0: SCSI2 0/direct fixed
sd2: 4094MB, 3712 cyl, 21 head, 107 sec, 512 bytes/sec, 8386000 sec total
vga1 at pci0 dev 11 function 0 "ATI Mach64 LI" rev 0xdc
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
fxp1 at pci0 dev 17 function 0 "Intel 8255x" rev 0x08, i82559: irq 10, address
00:02:55:b0:3e:64
inphy0 at fxp1 phy 1: i82555 10/100 PHY, rev. 4
isa0 at pcib0
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
pmsi0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pmsi0 mux 0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
lm0 at isa0 port 0x290/8: LM78
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 d
Re: altroot is not mentioned in FAQ
On Tue, 6 Nov 2007, Douglas A. Tutty wrote:
> While you're at it: the install docs cover the absolute minimum to run
> a basic system (I think they describe it as a basic home system
> connected to the internet). Could you include an example of the same
> thing but the minimum to be able to compile patches?
Include the compXX file set during installation.
Install src.tar.gz after installation.
That's it. (Add xenocara and ports if you like.)
Then you have a basic system connected to the internet and set up
for development and maintenance by AnonCVS of the source tree,
or for applying autonomous patches.
I will not relate the misery getting to this point on a certain
unnamed Linux "distro", whose release tag rhymes with "large".
> OpenBSD runs on old hardware. Old hardware doesn't have 20 GB disks.
> At best, I may have a PII with an 8 GB drive with perhaps a second 1 GB
> drive.
Indeed.
Here is a df from a bare, fresh 4.2 system, all install sets including X,
ports.tgz, and a (very) few smaller packages: (this is an i386 system,
other architectures will have different sizes, but should be close).
[EMAIL PROTECTED] root 0:1]# df
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/sd0a 510168 5731242734812%/
mfs:31119 506407 3481084 0%/tmp
/dev/sd0d 6190742 2123778 375742836%/usr
of the 2123778K in /usr, 1127960K is under /usr/src (including
xenocara source).
Total about 2.25GB, not counting swap. Another 2 GB might be needed
to compile a complete system in one go. ("make release"). Clever
use of NFS could be made. (Mount /usr/src from NFS, have /usr/obj
local, for example). You only need one /usr/src tree per LAN, and
it need not be on an OpenBSD host, just one capable of serving NFS.
An 8 GB disk would be quite ample, as has been my experience in the past,
and as you can conclude from the df output.
If you wish to compile only patches (say openssl is patched, and
you wish to recompile only openssl's subtree of /usr/src), then a
4GB disk would suffice, including a half G or whatever for swap.
OpenBSD doesn't really eat disk until you start building lots of
packages from source, i.e. through the /usr/ports infrastructure.
Dave
Re: changing active slice at boot
On Tue, 6 Nov 2007, Frans Haarman wrote: > Just wondering... > > Has anyone ever thought of having 2 openbsd installations to boot from ? > This way I could upgrade the installation on one slice/disk and boot from it! "slice" is FreeBSD talk. I assume you mean "disk partition", the thing manipulated by fdisk. > > Then if the kernel would crash/reboot the other slice would be used for > booting. > > So at boot time the active slice is changed, after booting its changed back > if there are no troubles! > > > Perhaps this is an ugly work around to most, but it might save my life when a > system refuses to boot the active slice.. Most of this can be > prevented with > remote consoles or ILO stuff I guess! What do you think ? FUD ? ;) OpenBSD's boot loader won't do this... but GRUB and LiLO will. But we do not need to turn to the penguin for this. A "rescue floppy" or any recent OpenBSD installation cd will do it, too. You choose that third option from "upgrade, install, shell". You get a shell, you then run fdisk to change the active partition, then reboot. Presto, change-oed. If the "bad" partition just has a bad kernel, then you will have been wise to have the bsd.rd kernel happily awaiting you, you can boot it from the boot> prompt, run fdisk, etc etc. If you are having "version trouble" recall that bsd.rd need not be the latest and greatest to be used for "rescue". Dave -- You don't have to like businessmen to like capitalism.
Re: Real men don't attack straw men
On Thu, 13 Dec 2007, Theo de Raadt wrote: > Richard, you are a total hypocrite. You are in here creating a fuss about > our software, saying it is non-free, when you are doing exactly the same > thing yourself. Put another way: The presence of an OpenBSD port entry for "opera" encourages the wider use of OpenBSD and all the other free software that implies. The presence of a port of gcc to Windoze encourages the development of software, free and otherwise, for Windoze, encouraging the wider use of Windoze and all the "unfree" software that Windoze implies. A good example of the second case is the encouragement to use Windoze that the gcc-enabled port of Mozilla-* to Windoze has almost certainly caused. I would use the lousy and dangerous behavior of I.E. as an advocacy talking-point to lure Windoze users away from their drug. Mozilla-* has weakened that talking-point. I like opensource, free software. I'll continue to support the OS and userland that best advances that cause. That would be OpenBSD. Dave -- I told you so. -- Cassandra
Re: Using the C programming language
On Sun, 23 Dec 2007, Kim Naim Lesmer wrote: > The Portable C Compiler (PCC) was written in mid-1970s. PCC shipped > with BSD Unix until the release of 4.4BSD in 1994. > > The history of Ada is? About 10 years younger. So? Dave
Re: Experiences running named and rndc on 4.4 vs 4.3
On Tue, 11 Nov 2008, Don Jackson wrote: > Today I began testing named on a freshly installed OpenBSD 4.4 amd64 > machine, using my old named.conf file from 4.3 (which was still running > named version 9.4.2) > > When the machine first boots after the install, /etc/rc determines there is > no rndc.key, and generates one: > > rndc-confgen: generating new shared secret... done. > starting named > > > Here are the owner, group, and file modes of the two different copies of > rndc.key that are generated: > > # ls -lAF /etc/rndc.key /var/named/etc/rndc.key > -rw--- 1 root wheel 77 Nov 11 12:24 /etc/rndc.key > -rw-r- 1 root wheel 77 Nov 11 12:24 /var/named/etc/rndc.key > > > named only cares about the rndc.key in /var/named/etc Right. But later, rndc will use the /etc version. So you need both, and the permissions you show are sane ones. > Looking at the logs: /var/log/daemon, one can see: > > Nov 11 12:24:10 svn01 named[142]: none:0: open: /etc/rndc.key: permission > denied > Nov 11 12:24:10 svn01 named[142]: couldn't add command channel 127.0.0.1#953: > permission denied > > Here is my workaround: > > # chown root:named /var/named/etc/rndc.key > # ls -lAF /var/named/etc/rndc.key > -rw-r- 1 root named 77 Nov 11 12:24 /var/named/etc/rndc.key > > > Should /etc/rc set the group ownership of /var/named/etc/rndc.key? > > Comments? I think rndc.key should pick up the named group from the ownerships and permissions on /var/named/etc. /var/named/etc should be owned by root.named and have permissions 750. I bet your /var/named/etc is owned by root.wheel. Dave
Questions about clock_gettime and friends
I. The system call clock_getres(2) and clock_gettime(2) show strange
results.
Consider this small program and its output on OpenBSD 5.0, amd64:
#include
#include
main()
{
struct timespec tp;
int i;
clock_getres(CLOCK_REALTIME, &tp);
printf("Resolution: %lu %lu\n", tp.tv_sec, tp.tv_nsec);
for (i = 0; i < 10; i++) {
clock_gettime(CLOCK_REALTIME, &tp);
printf("Performance: %lu %lu\n", tp.tv_sec, tp.tv_nsec);
}
return 0;
}
Resolution: 0 1000
Performance: 1331012858 566149475
Performance: 1331012858 566158834
Performance: 1331012858 566164422
Performance: 1331012858 566169031
Performance: 1331012858 566173152
Performance: 1331012858 566177202
Performance: 1331012858 566181253
Performance: 1331012858 566189075
Performance: 1331012858 566195570
Performance: 1331012858 566219945
Surely the clock is resolving better than 10 milliseconds?
II. The man page asserts:
"clock_id can be one of four values: CLOCK_REALTIME for time that
increments as a wall clock should, CLOCK_VIRTUAL for time ..."
How "should" a wall clock increment? Differently from CLOCK_MONOTONIC?
Thank you for your kind attention,
Dave
Re: Questions about clock_gettime and friends
On Tue, Mar 06, 2012 at 07:47:06AM +0100, Otto Moerbeek wrote:
> On Tue, Mar 06, 2012 at 01:01:57AM -0500, Woodchuck wrote:
>
> BTW, your format strings are not right, both in size of operand and
> signedness. Here:
Oops.
>
> > printf("Resolution: %lu %lu\n", tp.tv_sec, tp.tv_nsec);
>
> > for (i = 0; i < 10; i++) {
> > clock_gettime(CLOCK_REALTIME, &tp);
>
> And here:
> > printf("Performance: %lu %lu\n", tp.tv_sec, tp.tv_nsec);
> > }
> > return 0;
> > }
>
>
> struct timespec {
> time_t tv_sec; /* seconds */
> longtv_nsec;/* and nanoseconds */
> };
>
> and time_t is int
Thank you for the correction.
Dave
Re: 4.6 patch support
On Mon, Mar 22, 2010 at 7:36 AM, Andreas Gerdd wrote: > Hi, > > I've an OpenBSD 4.6-Stable system. I wanted to ask how long will > OBSD4.6 has patch/update support? > If there is a support time limit like lets say up to 12/24 months, > does it mean after that time, it will not get any update, not even > (possible) critical vulnerabilities? > > Kind regards. "Support" means something special for OpenBSD. It means two things: fixing security bugs and answering questions about how a feature of a release works or can be invoked. That ends at 12 mos. There is no back-porting of features, and that end of support starts at the moment of release. In the "new features" (say a driver for new hardware) sense there is no support for any release after it's released. Ports/packages are sort of hit-or-miss. This is a very Spartan situation, and comes from a shortage of resources. In a sense, one achieves the level of support offered elsewhere by recognizing that the method of obtaining it is to always update versions. With OpenBSD, as others point out, this is very easy and usually very-very well debugged prior to the next release. Most OpenBSD "releases" would be termed incremental updates by other OSes. Nine times out of ten, an upgrade can be completed in ten minutes, and mass upgrading of a "farm" not much longer for the whole farm. One advantage of the Open system is that one knows where one stands, and there is no in-system forking of releases, a problem which makes certain other *n*x systems or "distros" a crazy mess. Open is like a single-track railroad, there are breathing points called "stations", where one gets on or off, and after a year the old track is ripped up and recycled. The fare is $100/year but hoboes are still welcome. Dave -- teh googlez read my emails 'n' STUFF LOLZ!!! urz 2!!! LOLZ!!!
Re: Unix billennium in calendar(1)
On Thu, Jul 9, 2009 at 2:33 AM, Mikolaj Kucharski wrote: > Calendar told me that Unix billennium was today, but Wikipedia and > date(1) command say something different. > > Calendar wrote: >> Jul 09Unix billennium begins at 01:46:40 UTC, 2001 > > $ date -r 10 > Sun Sep 9 02:46:40 IST 2001 > > > References > 1. http://en.wikipedia.org/wiki/Unix_billennium > > -- > best regards > q# [m...@marcus 0.5.0 1:1749]$ date -r 10 Sat Sep 8 21:46:40 EDT 2001 [m...@marcus 0.5.0 1:1750]$ date -ur 10 Sun Sep 9 01:46:40 UTC 2001 [m...@marcus 0.5.0 1:1751]$ Got to watch that time zone! Dave -- Caution, this account is hosted by gmail. Strangers scan the content of all mail transiting such accounts.
Re: Unix billennium in calendar(1)
On Thu, Jul 9, 2009 at 3:11 AM, patrick keshishian wrote: > On Thu, Jul 9, 2009 at 12:02 AM, Woodchuck wrote: >> On Thu, Jul 9, 2009 at 2:33 AM, Mikolaj Kucharski >> wrote: >>> Calendar told me that Unix billennium was today, but Wikipedia and >>> date(1) command say something different. >>> >>> Calendar wrote: >>>> Jul 09Unix billennium begins at 01:46:40 UTC, 2001 >>> >>> $ date -r 10 >>> Sun Sep 9 02:46:40 IST 2001 >>> >>> >>> References >>> 1. http://en.wikipedia.org/wiki/Unix_billennium >>> >>> -- >>> best regards >>> q# >> >> [m...@marcus 0.5.0 1:1749]$ date -r 10 >> Sat Sep 8 21:46:40 EDT 2001 >> [m...@marcus 0.5.0 1:1750]$ date -ur 10 >> Sun Sep 9 01:46:40 UTC 2001 >> [m...@marcus 0.5.0 1:1751]$ >> >> Got to watch that time zone! > > "watch" the month. Ah, so. Calendar is wrong, then. Dave -- Caution, this account is hosted by gmail. Strangers scan the content of all mail transiting such accounts.
Sort doesn't sort
Sorry for cowering behind a pseudonymous email address, but I have the same given names as certain famous people in professions related to mine and wish to avoid confusion. Moreover such fame and identity as I have is tied to the delightful creature, the woodchuck, after which I am pseudonamed. Perhaps this is cowardly in certain nations more closely associated with their former or present colonial Masters than my own; I should concede that the genetic stock of such places might facilitate a deeper understanding of criminality and cowardice than does that in a land peopled through free will and whose folk's liberty was at one point established by force of that will, instead of confounding one's Masters with a dreary stew of sycophancy, beggary, stultification, boredom, servile coarseness and expense. That said, consider the following: I have transposed the output to rows for ease of study. For these examples, ascii collating order and numeric collating order are by coincidence the same. cat testfile 16.88 16.54 15.12 15.00 14.57 sort testfile 14.57 15.00 15.12 16.54 16.88 ascii CORRECT sort -n testfile 14.57 15.00 15.12 16.54 16.88 numeric CORRECT sort -nr testfile 16.88 16.54 15.12 15.00 14.57 numeric reversed CORRECT sort -k1 testfile 14.57 15.00 15.12 16.54 16.88 ascii CORRECT sort -k1n testfile 14.57 15.00 15.12 16.54 16.88 numeric CORRECT sort -k1nr testfile 16.88 16.54 15.00 15.12 14.57 incorrect reversed numeric FAILURE In this example, f(i) >= f(i+1) (reverse numeric sort) is not true. 15.00 !>= 15.12 Note that the integer part is sorted correctly. Add some more 15.nm to the testfile to see more detail. Do I misunderstand the man 1 sort entry concerning -k? I suspect that attribute "n" is not working for -k. Dave the Cowardly Marmot
