Re: rc.local mystery executables
On Sat, Aug 16, 2014 at 1:52 AM, Scott Bonds sc...@ggr.com wrote: On Fri, Aug 15, 2014 at 10:50:55AM -0500, Adam Thompson wrote: While a long way from perfect, tools such as chkrootkit and rkhunter might shed some light on your situation. As Giancarlo said, check every machine that's closely interconnected, not just the one compromised server you've noticed. I haven't used them under OpenBSD, so not sure how effective they'll be (both projects claim to support OpenBSD), but they're probably more appropriate than clamscan(1) which looks for mostly MS Windows-based viruses, not rootkits. Thank you for the suggestion. I just ran both chkrootkit and rkhunter. chkrootkit didn't find any matches. rkhunter had a couple warnings but to my eye they checkout out, i.e. warning that pkg_info is a perl script. That said, I'm going to make chkrootkit and rkhunter a regular part of my maintenance regime, perhaps add them as daily cron jobs. Both give warnings that look like false positives, but are really asking you, Is this something you intended, or would have intended had you known the package did it this way? (The warning on pkg_info is one such.) It takes a while to learn to weed through them. (I'm still not very used to it.) Speaking of which, is tripwire still considered useful, if set up right? -- Joel Rees Be careful where you see conspiracy. Look first in your own heart.
Re: rc.local mystery executables
On Fri, Aug 15, 2014 at 11:39 PM, Scott Bonds sc...@ggr.com wrote: [...] Perhaps I should separate the router and 'everything else' roles, so that the router only has builtin OpenBSD software on it, no packages. Strongly encourage you to get a separate box to run the router and firewall on. (Ted, if you read this, do you run firewall on Beagle Boards?) Then again, whatever the exploit, they could probably still use it on the newly separated 'everything else' box. Anyway, I clearly have a lot to learn about security. Actually, many of the exploits will hit high enough speed bumps getting through the router/firewall, if you set it up right, that the exploit would not succeed in dropping actual rootkit. Not to say you don't need something to watch for rootkits, as well, but combining functions makes for a weaker system. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart.
Re: rc.local mystery executables
Yeah it sucks, the miscreants run 24/7 365. My guess is home systems
are targeted a lot because there's only an 'IT Dept' of one.
Lots of good stuff in base and the ports collection. mtree can be
extended to check file integrity for anything you've modified and
other local stuff (something I need to do).
OpenBSD has always rocked for providing very current versions of
snort. barnyard2 compiles cleanly on obsd.
IIRC swatch can email you on log events. i.e. I know I haven't logged
onto the server for 2 weeks, why was there an unsuccessful (or yikes
successful) su/sudo attempt at 0237 when I was sleeping.
Got sagan-1.0.0RC4 set up earlier and was greeted with this alert:
[**] [1001:1] sagan_blacklist: Address found in blacklist [**]
[Classification: Blacklist] [Priority: 1]
2014-08-15 22:58:01 61.174.51.214:1514 - 127.0.0.1:1514 daemon warning
Message: Aug 15 22:57:55.617311 rule 7/(match) block in on rl0:
61.174.51.214.6000 xxx.xxx.xxx.xxx.22: S 1496842240:1496842240(0)
win 16384 [tos 0x20]
And snort (timestamps are messed up):
04/21-15:21:46.67 [**] [1:2100528:6] snort GPL SCAN loopback
traffic [**] [Classification: Potentially Bad Traffic] [Priority: 2]
{UDP} 127.0.0.1:53 - 172.xxx.xxx.xxx:31105
12/30-19:03:17.65 [**] [1:2100528:6] snort GPL SCAN loopback
traffic [**] [Classification: Potentially Bad Traffic] [Priority: 2]
{UDP} 127.0.0.1:53 - 172.xxx.xxx.xxx:3117
So you're not alone. Good Luck
On Thu, Aug 14, 2014 at 8:54 PM, Scott Bonds sc...@ggr.com wrote:
I run an OpenBSD 5.5-stable amd64 server at home. Email, web, etc. Today
I was doing some maintenance and I found my way to /etc/rc.local. When I
opened it I saw this:
$ cat rc.local
# $OpenBSD: rc.local,v 1.44 2011/04/22 06:08:14 ajacoutot Exp $
# Site-specific startup actions, daemons, and other things which
# can be done AFTER your system goes into securemode. For actions
# which should be done BEFORE your system has gone into securemode
# please see /etc/rc.securelevel.
cd /etc;./sfewfesfs
cd /etc;./gfhjrtfyhuf
cd /etc;./rewgtf3er4t
cd /etc;./sdmfdsfhjfe
cd /etc;./gfhddsfew
cd /etc;./ferwfrre
cd /etc;./dsfrefr
I don't remember adding those lines to my rc.local file.
$ cd /etc ls -al ./sfewfesfs
-rwsrwsrwt 1 root wheel 694680 Apr 4 07:47 /etc/sfewfesfs
$ file dsfrefr dsfrefr: ELF 32-bit LSB executable, Intel 80386, version
1, statically linked, stripped
Seems odd to have a bunch of randomly named executibles running at boot.
And that they are compiled for 386 (I'm running amd64), and that they have
suid set, and to root.
$ clamscan *
dsfrefr: OK
ferwfrre: OK
gfhddsfew: OK
gfhjrtfyhuf: OK
rc.local: OK
rewgtf3er4t: OK
sdmfdsfhjfe: OK
sfewfesfs: OK
Scanned directories: 0
Scanned files: 8
Infected files: 0
Data scanned: 3.21 MB
Data read: 3.20 MB (ratio 1.00:1)
Time: 10.842 sec (0 m 10 s)
Hmm, ok let's run one.
$ ./dsfrefr
./dsfrefr[1]: syntax error: `(' unexpected
That's all any of them say when run.
So...have I been p0wned or does anyone know what innocent thing might be
happening here? Please CC sc...@ggr.com on any replies, as I'm not
subscribed to updates from the list.
Re: Generating random.seed for network boot clients
Paul de Weerd wrote, On 08/15/14 14:51: At any rate, this changes that to allow world readable files (still not taking world writable files). We can't check S_IWOTH over tftp, we should probably assume 0777 for files transferred that way. But, if you're trusting the kernel you're getting over tftp, then why the hell are you not trusting random.seed? That attacker that could maybe influence your randomness would NEVER touch your kernel to ensure it only produces well known (to them) randomness. That would be way too easy... Good point. Index: boot.c === RCS file: /cvs/src/sys/stand/boot/boot.c,v retrieving revision 1.43 diff -u -p -r1.43 boot.c --- boot.c 19 Feb 2014 22:02:15 - 1.43 +++ boot.c 15 Aug 2014 21:41:01 - @@ -153,7 +153,7 @@ loadrandom(char *name, char *buf, size_t } if (fstat(fd, sb) == -1 || sb.st_uid != 0 || - (sb.st_mode (S_IWOTH|S_IROTH))) + (sb.st_mode (S_IWOTH))) goto fail; (void) read(fd, buf, buflen); fail: Nonetheless, on a generally secure internal network it's a benefit to have this the extra random source. But if it doesn't exist or it is known to the world, like Theo previously said, it isn't worse. The only downside is if the random.seed was used in a compromise of the PRNG of the client (not sure if that's possible). But then I guess I revert to Paul's point above.
Re: Generating random.seed for network boot clients
Christian Weisgerber wrote, On 08/15/14 18:36: On 2014-08-15, Paul de Weerd we...@weirdnet.nl wrote: What you could do is use the -r option to tftpd(8) to hand out a new file to each client that connects. Or just periodically (like, every hour or every minute, depending on the load of your tftp server) replace it with a new random file. How about making etc/random.seed a named pipe and feeding chunks of /dev/random to it? Something like # cd /tftpboot # mkfifo etc/random.seed # while true; do dd if=/dev/random count=1 etc/random.seed 2/dev/null; done seems to work at first blush. I liked de Weerd's idea using the -r option with tftpd. I was thinking I could use a socket to signal a small script containing nc(1) for the domain socket communication. The script would detect if the requested file was etc/random.seed, and if so, refresh the randomness, otherwise just pass the original request file back (essentially a NOP). Then tftpd would serve up this freshly generated randomness on a per request basis. But shit, Christian's one-liner above works like a charm! I was skeptical at first, but after some testing I'm convinced that it works great with tftpd(8). # cd /tftpboot # mkfifo test.seed # while :; do dd if=/tmp/counter of=test.seed 2/dev/null; done # cnt=0 # cd /tmp # echo $((cnt++)) counter # echo get test.seed\nquit | tftp localhost # cat test.seed 0 # echo $((cnt++)) counter # echo get test.seed\nquit | tftp localhost # cat test.seed 1 # echo $((cnt++)) counter # echo get test.seed\nquit | tftp localhost # cat test.seed 2 # ###DON'T UPDATE COUNTER### echo $((cnt++)) counter # echo get test.seed\nquit | tftp localhost # cat test.seed 2 and you get the picture ...
Why are there NSA, CSIS, and GOOGLE IDs in my ftplist.cgi
I checked out my saved install configurations at http://129.128.5.191/cgi-bin/ftplist.cgi and noticed that at the end of the file there are fields named NSA_ID, CSIS_ID, and GOOGLE_ID. They all sound scary. Each time I refresh the page, only one of the three IDs appear, but they seem to rotate. WTF? Here is a sample of my ftplist.cgi output: # BEGIN http://sys.mokaz.com/pub/OpenBSD/5.5/amd64 http://ftp5.usa.openbsd.org/pub/OpenBSD Redwood City, CA, USA http://ftp3.usa.openbsd.org/pub/OpenBSD Boulder, CO, USA ... http://ftp.hostserver.de/pub/OpenBSD Frankfurt, Germany http://ftp.cc.uoc.gr/mirrors/OpenBSD Heraklion, Greece TZ=US/Arizona method=http NSA_ID=0x177d9eb4802b6efc7d45d76c5743816f7d999c90446855738835bfad5b4b91ee TIME=1408186536 RND_BYTES=0x(LOOONG RANDOM GOODNESS) # END Is the source code for ftplist.cgi and ftpinstall.cgi publicly available? Thanks, Clint
Re: Generating random.seed for network boot clients
On 2014-08-16, Clint Pachl pa...@ecentryx.com wrote: # cd /tftpboot # mkfifo etc/random.seed # while true; do dd if=/dev/random count=1 etc/random.seed 2/dev/null; done # cd /tftpboot # mkfifo test.seed # while :; do dd if=/tmp/counter of=test.seed 2/dev/null; done Careful! dd ... fifo (O_WRONLY) blocks until there is a reader. By contrast, dd ... of=fifo (O_RDWR) does not block and if you run it in a loop, you'll end up with a busy loop. -- Christian naddy Weisgerber na...@mips.inka.de
Re: ulpt/libusb weirdness in -current
On Fri 15/08 20:08, Alessandro DE LAURENZIS wrote: On Fri 15/08 19:17, Antoine Jacoutot wrote: Actually missing! Is it just my system or... Nah, that's not needed. Still scratching my head... Yeah sorry, I have no other idea for now... Still debugging... I tried to revert to hplip 3.14.1 (adapting the port from 5.5), but the behavior is the same. Of course, let me know if I can do anything else (this is a very sensible topic for me, of course). Hello Antoine, Some progresses: I sorted out the things, reistalling from scratch all the packages in cups and hplip ports (with your patch, of course) and now I'm able to install the printer from the CUPS web interface and print too (I verified with the test page and some PDF documents). I really don't understand what was going wrong yesterday, 'cause I repeated the same steps; the only thing that I can confirm is that your patch is working and it is needed. So far, so good. But there is still something weird... When I try to open hp-systray, I receive the following message: warning: No hp: or hpfax: devices found in any installed CUPS queue. Exiting. which is of course a non-sense, given that the printer is installed in CUPS and the queue is correctly responding. If I try to install the printer with hp-setup, the situation is even more obscure; after having found the device, I obtain: Searching... (bus=usb, search=(None), desc=0) warning: /usr/local/share/hplip/plugin.spec file doesn't exists. error: No PPD found for model deskjet_f4200 using old algorithm. error: No appropriate print PPD file found for model deskjet_f4200_series Do you have any idea? How could I proceed in debugging? Thanks a lot for your time. -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
Re: ulpt/libusb weirdness in -current
Some progresses: I sorted out the things, reistalling from scratch all the packages in cups and hplip ports (with your patch, of course) and now I'm able to install the printer from the CUPS web interface and print too (I verified with the test page and some PDF documents). Cool, that's good. I really don't understand what was going wrong yesterday, 'cause I repeated the same steps; the only thing that I can confirm is that your patch is working and it is needed. It's been committed since :-) So far, so good. But there is still something weird... When I try to open hp-systray, I receive the following message: warning: No hp: or hpfax: devices found in any installed CUPS queue. Exiting. Well the HP tools are very very Linux centric; so I am not surprised that there are still dragons in there. Is your printer 'connection' setup as: hp:/usb/... ? which is of course a non-sense, given that the printer is installed in CUPS and the queue is correctly responding. If I try to install the printer with hp-setup, the situation is even more obscure; after having found the device, I obtain: Searching... (bus=usb, search=(None), desc=0) warning: /usr/local/share/hplip/plugin.spec file doesn't exists. error: No PPD found for model deskjet_f4200 using old algorithm. error: No appropriate print PPD file found for model deskjet_f4200_series Do you have any idea? How could I proceed in debugging? Oh that. Well that would require some patching I guess. As mentioned, the HP tools make a lot of assumptions which aren't true on OpenBSD :/ I've never spent too much time trying to fix hp-setup because it tends to break at each update in a different way -- but if that's something users really want, I could have a look when I have time. -- Antoine
Re: Generating random.seed for network boot clients
On 2014-08-16, Christian Weisgerber na...@mips.inka.de wrote: How about making etc/random.seed a named pipe and feeding chunks of /dev/random to it? I've now put this into my /etc/rc.local: --- # Provide fresh random.seed for pxeboot if cd /tftpboot/etc; then rm -f random.seed mkfifo random.seed # do not fill up filesystem if the FIFO disappears # dd of= does not block on open sh -c 'while [ -p random.seed ]; do dd count=1 random.seed; done' \ /dev/random 2/dev/null fi --- * It blocks until random.seed is read. * It doesn't run amok if random.seed is accidentally removed. * It's easy to identify with ps(1). -- Christian naddy Weisgerber na...@mips.inka.de
Re: Generating random.seed for network boot clients
I wonder if there would be some benefit to faking these files from inside the tftp daemon itself..
Re: rc.local mystery executables
On Sat, Aug 16, 2014 at 15:22, Joel Rees wrote: On Fri, Aug 15, 2014 at 11:39 PM, Scott Bonds sc...@ggr.com wrote: [...] Perhaps I should separate the router and 'everything else' roles, so that the router only has builtin OpenBSD software on it, no packages. Strongly encourage you to get a separate box to run the router and firewall on. (Ted, if you read this, do you run firewall on Beagle Boards?) No, I don't think they're useable for that purpose. Only one ethernet, and not very reliable. At least for the Black boards, there's no USB yet, and even on the others, I don't think I'd ever use USB ethernet for something like a firewall that I expect to just work.
Re: Why are there NSA, CSIS, and GOOGLE IDs in my ftplist.cgi
On Sat, Aug 16, 2014 at 04:03, Clint Pachl wrote: I checked out my saved install configurations at http://129.128.5.191/cgi-bin/ftplist.cgi and noticed that at the end of the file there are fields named NSA_ID, CSIS_ID, and GOOGLE_ID. They all sound scary. Each time I refresh the page, only one of the three IDs appear, but they seem to rotate. WTF? Checking to see who's paying attention.
Re: Why are there NSA, CSIS, and GOOGLE IDs in my ftplist.cgi
On Sat, Aug 16, 2014 at 04:03, Clint Pachl wrote: I checked out my saved install configurations at http://129.128.5.191/cgi-bin/ftplist.cgi and noticed that at the end of the file there are fields named NSA_ID, CSIS_ID, and GOOGLE_ID. They all sound scary. Each time I refresh the page, only one of the three IDs appear, but they seem to rotate. WTF? Checking to see who's paying attention. 1 person noticed. Took about 6 years.
Re: Why are there NSA, CSIS, and GOOGLE IDs in my ftplist.cgi
Theo de Raadt wrote: 1 person noticed. Took about 6 years. Clark Kent, you're a real SOB when you're drunk! :) -- Jack Woehr # We commonly say we have no time when, Box 51, Golden CO 80402 # of course, we have all that there is. http://www.softwoehr.com # - James Mason, _The Art of Chess_, 1905
Re: Generating random.seed for network boot clients
This is starting to remind me of Ubuntu's pollen/pollinate services. On Sat, Aug 16, 2014 at 11:31 AM, Theo de Raadt dera...@cvs.openbsd.org wrote: I wonder if there would be some benefit to faking these files from inside the tftp daemon itself..
Re: ulpt/libusb weirdness in -current
On Sat 16/08 15:31, Antoine Jacoutot wrote: But there is still something weird... When I try to open hp-systray, I receive the following message: warning: No hp: or hpfax: devices found in any installed CUPS queue. Exiting. Well the HP tools are very very Linux centric; so I am not surprised that there are still dragons in there. Is your printer 'connection' setup as: hp:/usb/... ? which is of course a non-sense, given that the printer is installed in CUPS and the queue is correctly responding. If I try to install the printer with hp-setup, the situation is even more obscure; after having found the device, I obtain: Searching... (bus=usb, search=(None), desc=0) warning: /usr/local/share/hplip/plugin.spec file doesn't exists. error: No PPD found for model deskjet_f4200 using old algorithm. error: No appropriate print PPD file found for model deskjet_f4200_series Do you have any idea? How could I proceed in debugging? Oh that. Well that would require some patching I guess. As mentioned, the HP tools make a lot of assumptions which aren't true on OpenBSD :/ I've never spent too much time trying to fix hp-setup because it tends to break at each update in a different way -- but if that's something users really want, I could have a look when I have time. Well, I used hp tools in 5.4 and 5.5 and they always worked flawlessly. So it seems related to my update to current... Maybe relate, maybe not: now xsane (and scanimage -L) are much more slow in startup, during the Scan for devices phase, even if the configuration has not been changed (and they used to start instantly when launched through hp-systray GUI). I really don't know if all these observations make any sense... Let me know. -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
PDF FAQ [Was: Donations to OpenBSD]
Greetings. Some way up this thread, I said: On 2014 Aug 14, at 11:21, Norman Gray nor...@astro.gla.ac.uk wrote: On 2014 Aug 14, at 01:10, Worik Stanton worik.stan...@gmail.com wrote: Suggestion: Package the release notes, FAQ and some other documentation into a PDF and sell that at the same price as the CD, from the same place. I'd buy that. It would be better quality than the (often) crap O'Reilly sell, and I buy that. This is potentially quite a good idea. The T-shirts and CDs exist because (a) some people find them useful in themselves, and (b) some people prefer or find it more convenient to buy a physical thing they don't intend to use, as a means of making an indirect donation to the project. This of course is discussed at length in the rest of this thread. There's precedent for such a physical book being sellable. The Python Reference Manual [1] is a dead-tree version of the language and library description also available for free at [2]. There's clearly some story about the various reasons why people buy that, but it's clear that at least some do. I have considered doing so myself -- a paper document is superior to an on-screen one in some circumstances -- but in the end found it more convenient to print out selected sections of the downloaded PDF. Places like lulu.com will put a PDF on paper for you and sell/ship the result. I've no idea of the economic details of that, or alternatives to lulu, but such services do exist. I'm not making any promises here, but given mild encouragement I'd be very willing to take a look at how complicated it would be to turn the existing text or texts into a readable PDF (I've done this sort of thing before, and could probably do it fairly efficiently). After posting that, I received some ... non-discouragement off-list, and that's enough for me. At http://nxg.me.uk/temp/openbsd-faq-suggestion/ you will find, for your delectation and delight: * A PDF of sections 1--5 of the FAQ; * An HTML version of this; * A tarball containing the source of the scripts which generate these from XML originals. The idea of the PDF is that it's something which could potentially be sold on dead trees (which might be useful/attractive for the reasons above). To do this, I took the HTML versions of the FAQ sections, and normalised them into regular XHTML (which makes them processable into other forms). With that done, it was straightforward to transform the result into both HTML for presentation, and into LaTeX for further transformation into PDF. This depends on the xsltproc package, and obviously on LaTeX. The HTML target does things like adding in consistent structuring, generating tables of contents, ensuring that internal cross-references are consistent, and so on. The results should be identical in content, and pretty similar in appearance, to the online versions. The normalisation of the contents consisted in large part of regularising away various bits of cruft used for layout (for example blockquote and table elements (eek!) around pre, which are fiddly to manage and are inevitably inconsistent across the document), making ... and '...' consistent, and a couple of other things discussed in the README in the tarball. The README also contains some notes on the lightweight structuring added to the source files. It would be pretty straightforward to generate a .txt FAQ from these same sources (via *roff). The results here aren't very pretty -- and obviously I've only done the first five sections -- but they're respectable and should show the idea. Even if the PDF idea isn't taken up, this is potentially an alternative way to generate the HTML files, in contrast to hand-editing disconnected .html files. I like the idea of the 'Good Idea Fairy'! This one comes with product. Best wishes, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK
Re: PDF FAQ [Was: Donations to OpenBSD]
On Sat, Aug 16, 2014 at 2:01 PM, Norman Gray nor...@astro.gla.ac.uk wrote: Greetings. Some way up this thread, I said: On 2014 Aug 14, at 11:21, Norman Gray nor...@astro.gla.ac.uk wrote: On 2014 Aug 14, at 01:10, Worik Stanton worik.stan...@gmail.com wrote: Suggestion: Package the release notes, FAQ and some other documentation into a PDF and sell that at the same price as the CD, from the same place. I'd buy that. It would be better quality than the (often) crap O'Reilly sell, and I buy that. This is potentially quite a good idea. The T-shirts and CDs exist because (a) some people find them useful in themselves, and (b) some people prefer or find it more convenient to buy a physical thing they don't intend to use, as a means of making an indirect donation to the project. This of course is discussed at length in the rest of this thread. There's precedent for such a physical book being sellable. The Python Reference Manual [1] is a dead-tree version of the language and library description also available for free at [2]. There's clearly some story about the various reasons why people buy that, but it's clear that at least some do. I have considered doing so myself -- a paper document is superior to an on-screen one in some circumstances -- but in the end found it more convenient to print out selected sections of the downloaded PDF. Places like lulu.com will put a PDF on paper for you and sell/ship the result. I've no idea of the economic details of that, or alternatives to lulu, but such services do exist. I'm not making any promises here, but given mild encouragement I'd be very willing to take a look at how complicated it would be to turn the existing text or texts into a readable PDF (I've done this sort of thing before, and could probably do it fairly efficiently). After posting that, I received some ... non-discouragement off-list, and that's enough for me. At http://nxg.me.uk/temp/openbsd-faq-suggestion/ you will find, for your delectation and delight: * A PDF of sections 1--5 of the FAQ; * An HTML version of this; * A tarball containing the source of the scripts which generate these from XML originals. The idea of the PDF is that it's something which could potentially be sold on dead trees (which might be useful/attractive for the reasons above). To do this, I took the HTML versions of the FAQ sections, and normalised them into regular XHTML (which makes them processable into other forms). With that done, it was straightforward to transform the result into both HTML for presentation, and into LaTeX for further transformation into PDF. This depends on the xsltproc package, and obviously on LaTeX. The HTML target does things like adding in consistent structuring, generating tables of contents, ensuring that internal cross-references are consistent, and so on. The results should be identical in content, and pretty similar in appearance, to the online versions. The normalisation of the contents consisted in large part of regularising away various bits of cruft used for layout (for example blockquote and table elements (eek!) around pre, which are fiddly to manage and are inevitably inconsistent across the document), making ... and '...' consistent, and a couple of other things discussed in the README in the tarball. The README also contains some notes on the lightweight structuring added to the source files. It would be pretty straightforward to generate a .txt FAQ from these same sources (via *roff). The results here aren't very pretty -- and obviously I've only done the first five sections -- but they're respectable and should show the idea. Even if the PDF idea isn't taken up, this is potentially an alternative way to generate the HTML files, in contrast to hand-editing disconnected .html files. I like the idea of the 'Good Idea Fairy'! This one comes with product. Best wishes, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK in the glorious third millemium are usb key as cheap as cd printing ? -- - () ascii ribbon campaign - against html e-mail /\
Re: PDF FAQ [Was: Donations to OpenBSD]
On 14-08-16 01:01 PM, Norman Gray wrote: To do this, I took the HTML versions of the FAQ sections, and normalised them into regular XHTML (which makes them processable into other forms). With that done, it was straightforward to transform the result into both HTML for presentation, and into LaTeX for further transformation into PDF. This depends on the xsltproc package, and obviously on LaTeX. [...] It would be pretty straightforward to generate a .txt FAQ from these same sources (via *roff). I find that this work would be useful to me - there are (admittedly rare) occasions where I want an offline copy of the documentation. But... shouldn't the master copy be in mdoc(7) format? ;-) Now, if anyone actually took that seriously: I believe work on doclifter(1) and docbook2mdoc(1) is already in consideration, perhaps there's an reasonably-automatic way to do the conversion? If not, I certainly don't think it's worth the time to change it by hand. -- -Adam Thompson athom...@athompso.net
Re: PDF FAQ
Hi Adam, Adam Thompson wrote on Sat, Aug 16, 2014 at 03:27:46PM -0500: On 14-08-16 01:01 PM, Norman Gray wrote: To do this, I took the HTML versions of the FAQ sections, and normalised them into regular XHTML (which makes them processable into other forms). With that done, it was straightforward to transform the result into both HTML for presentation, and into LaTeX for further transformation into PDF. This depends on the xsltproc package, and obviously on LaTeX. [...] It would be pretty straightforward to generate a .txt FAQ from these same sources (via *roff). Regarding the OP's mail, TL;DR (and too complicated). I find that this work would be useful to me - there are (admittedly rare) occasions where I want an offline copy of the documentation. But... shouldn't the master copy be in mdoc(7) format? ;-) Now, if anyone actually took that seriously: You'd be surprised to hear that i discussed that very question with Nick@ last year in Toronto, and we both agreed that would be useful. We just didn't come round to it yet. I believe work on doclifter(1) and docbook2mdoc(1) is already in consideration, That would be me. perhaps there's an reasonably-automatic way to do the conversion? Almost certainly. You would have to write a small one-time conversion script in whatever scripting language you like (i'd probably go for Perl if i were to do it). doclifter(1) doesn't help much, actually, because the starting point is not man(7), so docbook2mdoc(1) isn't much use either, for this particular task. If not, I certainly don't think it's worth the time to change it by hand. Well no, some scripting support is certainly required unless you are *very* bored. But that shouldn't be too hard to write. Yours, Ingo
problem with sound card
My sound card can play sound, but can't record it dmesg related to sound card: isapnp0 at isa0 port 0x279: read port 0x203 sb1 at isapnp0 Creative ViBRA16C PnP, CTL0001, , Audio port 0x220/16,0x330/2,0x388/4 irq 5 drq 1,5: dsp v4.13 midi0 at sb1: SB MPU-401 UART audio0 at sb1 opl at sb1 not configured joy0 at isapnp0 Creative ViBRA16C PnP, CTL7001, PNPB02F, Game port 0x200/8 It's ISA sound blaster, I don't know why it's called sb1, not sb0 When I run aucat -o t2.wav, it says snd0: default: failed to open audio device
error during package installation
how to direct ouput by a command to file (so I can report error here) pkg_add nedit t1 doesn't work Thanks!
Re: problem with sound card
does that really help? OpenBSD 5.5 (GENERIC) #276: Wed Mar 5 09:57:06 MST 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Celeron (GenuineIntel 686-class, 128KB L2 cache) 435 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,PERF real mem = 335036416 (319MB) avail mem = 317255680 (302MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 05/19/00, BIOS32 rev. 0 @ 0xf06c0, SMBIOS rev. 2.3 @ 0xf1f50 (45 entries) bios0: vendor Award Software, Inc. version ASUS P3B-F ACPI BIOS Revision 1006 date 05/19/2000 bios0: ASUSTeK Computer INC. P3B-F acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP BOOT acpi0: wakeup devices UAR1(S1) UAR2(S1) PS2K(S1) PS2M(S1) USB0(S1) PCI0(S1) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C3, C2 acpibtn0 at acpi0: PWRB bios0: ROM list: 0xc/0x8000 cpu0 at mainbus0: (uniprocessor) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82443BX AGP rev 0x03 intelagp0 at pchb0 agp0 at intelagp0: aperture at 0xe400, size 0x400 ppb0 at pci0 dev 1 function 0 Intel 82443BX AGP rev 0x03 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 NVIDIA/SGS-Thomson Velocity128 rev 0x22 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) piixpcib0 at pci0 dev 4 function 0 Intel 82371AB PIIX4 ISA rev 0x02 pciide0 at pci0 dev 4 function 1 Intel 82371AB IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: QUANTUM FIREBALL EX6.4A wd0: 16-sector PIO, LBA, 6149MB, 12594960 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 disabled (no drives) uhci0 at pci0 dev 4 function 2 Intel 82371AB USB rev 0x01: irq 12 piixpm0 at pci0 dev 4 function 3 Intel 82371AB Power rev 0x02: SMI iic0 at piixpm0 lm1 at iic0 addr 0x2d: AS99127F rl0 at pci0 dev 10 function 0 Realtek 8139 rev 0x10: irq 10, address 50:a0:00:00:11:ac rlphy0 at rl0 phy 0: RTL internal PHY isa0 at piixpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 isapnp0 at isa0 port 0x279: read port 0x203 sb1 at isapnp0 Creative ViBRA16C PnP, CTL0001, , Audio port 0x220/16,0x330/2,0x388/4 irq 5 drq 1,5: dsp v4.13 midi0 at sb1: SB MPU-401 UART audio0 at sb1 opl at sb1 not configured joy0 at isapnp0 Creative ViBRA16C PnP, CTL7001, PNPB02F, Game port 0x200/8 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 Intel UHCI root hub rev 1.00/1.00 addr 1 vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root scsibus1 at softraid0: 256 targets root on wd0a (a1d9b075f33eba7e.a) swap on wd0b dump on wd0b
Re: error during package installation
Hi, Long Wind wrote on Sun, Aug 17, 2014 at 07:27:09AM +0800: how to direct ouput by a command to file (so I can report error here) pkg_add nedit t1 doesn't work That only catches standard output, not standard error. Both of the following should work: $ pkg_add nedit t1 21 # to the file only $ pkg_add nedit 21 | tee t1 # to the file and to the screen Let me take a blind guess regarding your problem: http://www.openbsd.org/faq/faq15.html#NoFun Yours, Ingo
Re: error during package installation
Thank STeve Andre' I use script method I probably will disappoint Ingo Schwarze, perhaps it's not really error, but it made me feel uneasy: Error from http://ftp.sunet.se/pub/os/OpenBSD/5.5/packages/i386/quirks-1.113.tgz Redirected to http://211.167.105.78:82/1Q2W3E4R5T6Y7U8I9O0P1Z2X3C4V5B/ftp.sunet.se/pub/os/OpenBSD/5.5/packages/i386/quirks-1.113.tgz I often see msg like above during installation BTW what's quirks anyway? I often see it Thanks!
Re: error during package installation
On Sat, Aug 16, 2014 at 5:07 PM, Long Wind longwind2...@gmail.com wrote: Thank STeve Andre' I use script method I probably will disappoint Ingo Schwarze, perhaps it's not really error, but it made me feel uneasy: Error from http://ftp.sunet.se/pub/os/OpenBSD/5.5/packages/i386/quirks-1.113.tgz Redirected to http://211.167.105.78:82/1Q2W3E4R5T6Y7U8I9O0P1Z2X3C4V5B/ftp.sunet.se/pub/os/OpenBSD/5.5/packages/i386/quirks-1.113.tgz That's presumably just the nature of how that site handles the mirror, via a redirect among their servers. With signed packages, you can be confident that an interposer can't use that subvert your pkg_add by replacing the package files. BTW what's quirks anyway? I often see it It's a package used by the package system itself. c.f pkg_info quirks Philip Guenther
Re: problem with sound card
On 08/16/14 19:30, Long Wind wrote: does that really help? OpenBSD 5.5 (GENERIC) #276: Wed Mar 5 09:57:06 MST 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Celeron (GenuineIntel 686-class, 128KB L2 cache) 435 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,PERF real mem = 335036416 (319MB) avail mem = 317255680 (302MB) [snip] Yes, it can at times. I have seen cases where something you wouldn't have expected causing problems elsewhere. Also, things like bios levels can impact things. Given how big the dmesg data is, it's always reasonable to post it. --STeve Andre'
