Nmap No buffer space available
# pfctl -F all && pfctl -d # nmap -vv -sP '0.0.0.*' Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-04-15 01:58 UCT sendto in send_ip_packet: sendto(3, packet, 40, 0, 62.201.118.82, 16) => No buffer space available Sleeping 15 seconds then retrying openbsd 3.7 over a pppoe conection. I seacrhed google and find many people with the same problem. But no answer. Is there any fix of using nmap on openbsd through a ppp conection or I m just loosing my time and nmap will not work as usuall? Anyone that using nmap over pppoe link succesfully on openbsd and has any suggestions? Thanks Chris
Re: When would you NOT use OpenBSD?
Lars Hansson wrote: On Wednesday 05 April 2006 06:25, Miles Keaton wrote: When would you NOT use OpenBSD? When you run applications that *REALLY* needs SMP, not that there are a lot of those. Or when your application simply do not run on OpenBSD for some reason. When would you choose one of the other *nix over OpenBSD? When they're more suitable for the task. Not that it has ever been the case for me. Is OpenBSD appropriate for a busy webserver or super-loaded database server? Webserver yes. "Super-loaded" MySql server? Dunno, depends on how much MySql sucks these days. I've seen old "O.S. shootouts" benchmarks comparing O.S.'s and often showing Linux or FreeBSD excelling at webserving or database-performance, but I don't know if that's just old data or the benchmarkers didn't have OpenBSD tweaked right. Benchmarks are like assholes, everyone has one but you're better off only minding your own. Lars Hansson Loved the last one so I wanna add that I m comming from a Linux background, used freebsd for years, I m gonna never regret I found OpenBsd in the way. My Last Linux box (Suse) was the day I found my router in my office with a kernel panic message after 1 year working fine patched up as always. In the same box without any hardware changes I run now an Openbsd Webserver from then till now holding more than 30 domain names some with lot of traffic almost unpatched and unupdated (3.2 stable). I bet if I left it there unpatched for the next 5 years I will not wake up one morning and find it down if will be no hardware problem. And yes thats not the proper way to go as an administrator but thats what I like on Openbsd. Very glad for the $1 from mozzila I hope We can do that too one day. -Chris. PS. Yes When I want to play Fancy Games and just kill my time I have no prob using Windows. I had even a Game Server in Openbsd and it wasn t never down.
openssh public auth and permissions
OpenBSD 3.7 GENERIC#0 i386 OpenSSH_4.1, OpenSSL 0.9.7d Doing public authentication for a user with example home directory: /var/www/home/myhomedir if there is no public read permissions for home directory example home is set 0751 rwxrwx--x or even 1711 or 1751 the daemon fails reading the file in ~/.ssh/authorized__keys even if the dir .ssh is chmod 755 and the file has world read permissions. The public authentication fails with the error permission denied to read the above file in /var/log/authlog and ssh requests a password. Can u please tell me why Openssh needs read permissions to home + home dir other than x to read a specified world readable file? Any workaround or an answer to this? -Chris
Re: php in cgi mode & suphp missing(?) from packages
Adam wrote: Php in CGI mode makes no sense. Php is beloved of his speed against perl for example which is a powerful alternative. We are not going to discuss this here at misc Perl vs PHP so leave with it or change to perl. Php CGI is buggy slow and has many problems to accomplish some tasks thats trivial otherwise. This is of course complete nonsense. PHP may be beloved by some people, but it has nothing to do with speed. Running PHP as a CGI is simple and has no buggy problems or anything else. Its just like running perl as a CGI instead of using mod_perl, or python as a CGI instead of mod_python. I have tried it and php as module is sunificaly faster than as cgi. And second is even faster if it compiled direct into apache and not as module. As for the buggy problems may be I wasnt clear.. Most using php they use scripts already writen and there is problems geting these scripts function as some paths and settings must be altered if you use php as CGI. 2) Why doesn't OBSD have a package for php that includes the CGI version? Not ported as others told u. I don't think there are many that they go this way so probably is no need Uh, its enabled if you installed it through ports/packages. Just stick #!/usr/local/bin/php up at the top of your script, and you have a PHP cgi script just like you would with any other language. There is no /usr/local/bin/php executable in default chrooted openbsd php install or I m blind? If you are speaking of moving this to /var/www /usr/local/bin/php that was the whole point security. Anyway I use php many years in a production enviroment as apache module. Have tried the CGI thing my opinion is just that is a second option for apache and I see no reason to do it in openbsd. Adam Do not cc me I hate that. -Chris
Re: php in cgi mode & suphp missing(?) from packages
Anon wrote: Hello :) My questions can be summarised as : 1) What is the easiest way to install php in CGI mode on OBSD? Php in CGI mode makes no sense. Php is beloved of his speed against perl for example which is a powerful alternative. We are not going to discuss this here at misc Perl vs PHP so leave with it or change to perl. Php CGI is buggy slow and has many problems to accomplish some tasks thats trivial otherwise. 2) Why doesn't OBSD have a package for php that includes the CGI version? Not ported as others told u. I don't think there are many that they go this way so probably is no need 3) Why doesn't OBSD have a suphp package? Is there any special reason? Not ported. I think is crap. My opinion: I can not trust a uid 0 program in my chroot apache to provide security and have it help others may be break out of the jail. I ask these questions because suphp (http://www.suphp.net) is a program that switches the uid of php scripts run under apache, so they run as uid of the script owner instead of uid of the webserver. This makes it similar to SuEXEC, a very well known security program that does the same thing for perl scripts, and is included in the OBSD system. I find it critical to have as a security tool, because without it any local user can use php scripts to send mail as 'nobody' or 'www' - without much in the way of logs, and they can also browse the files of other users via scripts... and generally do a lot of things they should not be able to do. I trust my chrooted apache environment on openbsd much more than the suphp package. As OBSD is focused on security, it makes a lot of sense to me that OBSD would at least include the CGI version of PHP in its php-core packages, and preferably have a suphp package too. Thats why apache is chrooted by default in openbsd oposition to a linux system that uses suphp or cgi but is insecure in most cases and by default. Now, I realise that suphp is mainly made for linux - but I do think it should be ported for OBSD, because, frankly, without it, allowing local users to run php scripts on your webserver is a very insecure idea. Lots of people run webservers on OBSD (like myself) and we're concerned that OBSD provides no obvious way to remedy this exploit-waiting-to-happen. having mini_sendmail for mail and no shell executables in /var/www as is by default or have only some mandatory safe sh script is the secure way to go. It'd be consistent with your policy of including suexec to also include suphp. I'm trying to go with the OBSD guide's advice and only use the packages, but this is difficult when there are (imho) essential tools (and even the things they depend on) which aren't available as packages :-( Good luck Suggestions would be very welcome :) -Chris
