Re: computer hangs after varying amount of data is received from network via ssh
On Wed, Oct 13, 2010 at 8:59 PM, Nick Holland n...@holland-consulting.net wrote: On 10/13/10 17:25, Robert wrote: On Wed, 13 Oct 2010 16:55:18 -0400 Ted Unangst ted.unan...@gmail.com wrote: can be done about it, and 10 year old quirky PC hardware doesn't attract a of interest... As long as it's on [1] I hope it does? I guess I'm not the only one who uses a Pentium 4 (or older stuff) for firewalls and other systems, since they are very cheap to buy and replace, and are more than sufficient (speed) for a lot of tasks. regards, Robert [1] http://www.openbsd.org/i386.html There are big differences between well-designed hardware, poorly designed and implemented hardware, hardware is working properly and hardware that is malfunctioning. A lot of hardware out there was tested with Windows-of-the-Day (and maybe the day before) and that's it. Anything else it works with, great, but it was by luck, not design. A lot of early AMD stuff was junk. I'm not talking about the AMD chips themselves, I'm talking about the REST of the computer. I've got a few AMD K6 systems, and NONE of them can build from source at the rated speed with OpenBSD. They'll run the OS just fine, but they can't build, giving sig11's at random places during the process. Replace the RAM with stuff that has worked well in 133MHz bus machines, same thing. Slow down the bus speed, increase the multiplier, and suddenly they work fine. I don't think that's an OpenBSD problem, and I really don't want developers fighting with that. I have heard reports of these kinds of problems extending well into the Athlon days... In your case, though, yes, I'd look closely at your hardware. Not sure why you have both a 150G disk and a 15G disk...double your chances of disk failure taking your system out...for 10% more storage. I also see re2 is on irq12. That's the PS/2 mouse IRQ. Sure, you don't have a mouse on your machine, maybe you have the mouse port off in the BIOS...but I'd be completely unsurprised if your HW mfg screwed the pooch and didn't really disconnect the PS/2 hardware from IRQ controller, and that could be causing some of your issues there (twist knobs in the system BIOS, you can probably fix this). And I'd not be surprised in the least if BOTH were problems for you... Nick. Actually the same issue occurred previously when the only difference was that I had configured re0 as the active interface. I thought the fact that it was using the same irq as pciide1 might be the source of the issue. Most recently, I have tried extracting the NIC in question. The only remaining NIC is now using irq 10 (along with pciide1.) Similar issues occurred. I list here the output - similar sequences have been listed many times, all values aside from c_bcount, c_skip, and possibly cn vary. pciide1:1:0: bus-master DMA error: missing interrupt, status=0x21 wd1a: device timeout writing fsbn 581104768 of 5811047680581104799 (wd1 bn 581184768; cn 576492 tn 13 sn 13), retrying wd1(pciide1:1:0): timeout type: ata c_bcount: 16384 c_skip: 0 I am going to see if I can eliminate the old PATA drive and associated controller / driver from the picture with hardware I have available. -- Young man, in mathematics you don't understand things, you just get used to them. - John von Neumann
Re: Force passwordcheck in login.conf
Brad Tilley brad at 16systems.com writes: I was experimenting with a program to meet PCI DSS 1.2 password length and content/complexity requirements and integrating it with login.conf for users who have shell access to OpenBSD systems. It seems to work as expected, but I wanted to run my configuration by misc. I appended the following two lines to the end of both default and staff in login.conf. Look OK? :passwordcheck=/path/to/program:\ :passwordtries=0: I understand that it would be easy (and redundant) to use minpasswordlen to meet the length requirement, but it's easy to check that in the program itself. Brad We are currently being reviewed for PCI DSS compliance, and the big problems we have right now with the combination of PCI DSS and OpenBSD is the following PCI DSS requirements: 8.5.12 Password history check - you may not use the last 4 passwords. 8.5.13 Lockout after 6 failed attempts - OpenBSD does not lock accounts automatically. 8.5.14 If 8.5.13 takes affect, the account must be locked for at least 30 minutes. How have you addressed these requirements? I'm starting to think we need a RADIUS solution, which seems a bit redundant working with OpenBSD... Regards, Leif
Re: USB devices don't attach when urtw is under load
On Thu, Oct 14, 2010 at 1:52 AM, Jacob Meuser jake...@sdf.lonestar.org wrote: On Thu, Oct 14, 2010 at 12:33:34AM +0200, ??? ??? wrote: % ps -akx | grep usb B B 8 ?? B DK B B B 0:00.26 (usbtask) B 7243 p1 B S+ B B B 0:00.01 grep usb % top -S -n 200 | grep usb B B 8 root B B B -6 B B 0 B B 0K B 19M idle B B B usbsyn B B 0:00 B 0.00% usbtask usbsyn - there's a synchronous usb transfer not finishing. B does this recover (i.e. usbtask thread is not waiting in usbsyn) when you remove the device? After urtw device removal: % top -S -n 200 | grep usb 8 root 1000K 19M sleep/0 usbtsk0:00 0.00% usbtask Then, after some time (not immediately on plugging in) it reverts to: % top -S -n 200 | grep usb 8 root -600K 19M idle usbsyn0:00 0.00% usbtask does this happen with all usb devices? With the rest of devices everything is OK. Actually I'm using this dongle because booting proccess stopped on trying to attach the WiMax part on Intel Link 5150. While that device is connected via MiniPCIe, the WiMax part connects to the USB bus, so I think that could be somehow connected. In 4.7 there were no issues with Intel device, and urtw was faulty, but didn't give these problems. B does it happen in all usb ports? Yes. Regardless of usb port it attaches to the same EHCI hub and behaves the same way. Don't know whether it is somehow important or not, but power over usb works for newly plugged devices that are not attached to the system. -- Dmitrij D. Czarkoff
Urgent: Mise à jour de votre compte
Mettre a jour votre Carte Credit en ligne Cher Client Notre salutations Nous Vous Informons Que :Votre Carte Bancaire Sera suspendue , pour la remarque d'un problC)me administratif .Pour proteger la votre et la mettre a jour, Cliquez ici , et vous devez bien completer les informations indiquC)es .Merci de votre confiance C votre Banque La Banque Postale Libre rC)ponse 83130 51049 ChClons en Champagne Cedex Cliquez ici pour mettre a jour votre carte crC)dit. ConformC)ment C la loi du 6 janvier 1978, vous disposez d'un droit d'accC(s, de rectification et d'opposition aux informations vous concernant lequel s'exercera auprC(s de la Banque Postale. .
Re: Wireless Network GUI
On Wed, 13 Oct 2010, Christiano F. Haesbaert wrote:
From: Christiano F. Haesbaert haesba...@haesbaert.org
To: OpenBSD Questions misc@openbsd.org
Date: Wed, 13 Oct 2010 17:17:16
Subject: Re: Wireless Network GUI
I use this silly script for wireless if someone is interested:
http://github.com/haesbaert/scripts/blob/master/wifi
Pau Amaro-Seoane's wifiprobe script, posted to this mailing list in
2007, is useful. See:
http://marc.info/?l=openbsd-miscm=119442609818795w=2
http://marc.info/?l=openbsd-miscm=119611252029773w=2
Also see the undeadly article from D. Adam Karin:
http://undeadly.org/cgi?action=articlesid=20071224164233
which is shows a useful method of connecting to known wireless
networks at boot time.
Here at work I can often see several available wireless connection
points. So I've tweaked the above script to connect to the one with
the strongest signal. Here's what I've run on my venerable T23
Thinkpad running OpenBSD4.7. It's a shell archive. Note you'll
need to make the /etc/rc.wireless script executable.
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering sh file. Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# netstart.diffs
# rc.wireless
# rc.wireless.conf
#
echo x - netstart.diffs
sed 's/^X//' netstart.diffs 'END-of-netstart.diffs'
X--- netstart.orig Thu Mar 18 02:31:37 2010
X+++ netstart Tue Aug 31 12:42:08 2010
X@@ -174,6 +174,12 @@
X # Re-read /etc/rc.conf
X . /etc/rc.conf
X
X+# Wireless configuration, if present and known.
X+if [ -f /etc/rc.wireless -a -x /etc/rc.wireless \
X+ -a X$1 = Xautoboot ] ; then
X+ /etc/rc.wireless
X+fi
X+
X # If we were invoked with a list of interface names, just reconfigure these
X # interfaces (or bridges) and return.
X if [ $1x = autobootx ]; then
END-of-netstart.diffs
echo x - rc.wireless
sed 's/^X//' rc.wireless 'END-of-rc.wireless'
X#!/bin/sh
X
X# This script is executed by /etc/netstart when booting. It
X# does the following:
X#
X# (1) extracts wifi card DHCP parameters from
X# /etc/rc.wireless.conf
X#
X# (2) Performs a wifi scan looking for available wireless networks
X#
X# (3) Compares available wireless networks with those preconfigured
X# in /etc/rc.wireless.conf
X#
X# (4) Stores the details for any known network in /etc/hostname.if.
X# If there's more than one network, the one with the strongest
X# signal is chosen.
X#
X# This script can also be used in stand-alone mode,
X# /etc/rc.wireless followed by sh /etc/netstart {interface-name}.
X# So for removable wifi devices this script could form part of a
X# hotplugd script to connect to known wifi networks.
X
XIFS='
X'
X
X# Commands we'll use.
Xcp=/bin/cp
Xecho=/bin/echo
Xifconfig=/sbin/ifconfig
Xmktemp=/usr/bin/mktemp
Xrm=/bin/rm
Xsed=/usr/bin/sed
Xsort=/usr/bin/sort
X
X# Make sure we have a configuration file...
XCONF=/etc/rc.wireless.conf
X[ -r $CONF ] || exit 1
X
X# ...that contains an interface name...
XIFNAME=$($sed -ne 's/^#wifi[[:space:]]IFNAME=\(.*\)$/\1/p' $CONF)
X[ -n $IFNAME ] || exit 1
X
X# ...that's plugged in.
X$ifconfig $IFNAME /dev/null 21 || exit 1
X
X# Reset the wifi device if there's a command to do this.
XRESET=$($sed -ne 's/^#wifi[[:space:]]RESET=\(.*\)$/\1/p' $CONF)
X[ -n $RESET ] { $ifconfig $IFNAME $RESET /dev/null 21; }
X
X# If present, note the wifi device's MAC address. It isn't crucial
X# that we have this.
XMAC_ADDR=$($sed -ne 's/^#wifi[[:space:]]MAC_ADDR=\(.*\)$/\1/p' $CONF)
X
X# Set DHCP parameters. Use default values if nothing is set in our
X# configuration file.
XDHCP=$($sed -ne 's/^#wifi[[:space:]]DHCP=\(.*\)$/\1/p' $CONF)
XDHCP=${DHCP:-dhcp NONE NONE NONE}
X
X# Delete any existing hostname.if file.
XHFILE=/etc/hostname.$IFNAME
X$rm -fP $HFILE
X
X# Temporary file. Note the permissions (-rw---) on this file
X# are *exactly* as required.
XTFILE=$($mktemp)
X
X# Wireless scan picking out any access points known to us.
X$ifconfig $IFNAME scan | \
X$sed -ne 's/^.*\(..:..:..:..:..:..\) \([0-9]*\).*$/\1 \2/p' | \
Xwhile read MAC STRENGTH
Xdo
X. $CONF {
X
XDATA=$STRENGTH
X
X[ -n $NWID ]DATA=$DATA nwid \$NWID\
X
X[ -n $BSSID ] DATA=$DATA bssid $BSSID
X
X[ -n $CHAN ]DATA=$DATA chan $CHAN
X
X[ -n $NWKEY ] DATA=$DATA nwkey $NWKEY
X
X[ -n $WPAKEY ] DATA=$DATA wpa wpask $WPAKEY
X
X$echo $DATA $TFILE
X}
Xdone
X
X# Make sure our temporary file gets deleted.
Xtrap $rm -fP $TFILE; trap - EXIT ERR HUP INT TERM
X
X# Check we have at least one known access point.
X[ -s $TFILE ] || exit 0
X
X# Pick out the access point with the strongest signal.
XDATA=$($sort -n -r $TFILE | $sed -ne 's/^[0-9]* \(.*\)$/\1/p' -e 1q)
X
X# Finally set up our hostname.if file...
X$echo $DHCP $DATA $TFILE
X
X# ...and copy it to the right place.
X[ -s $TFILE ] $cp -p
Re: Force passwordcheck in login.conf
Leif Blixt wrote: Brad Tilley brad at 16systems.com writes: I was experimenting with a program to meet PCI DSS 1.2 password length and content/complexity requirements and integrating it with login.conf for users who have shell access to OpenBSD systems. It seems to work as expected, but I wanted to run my configuration by misc. I appended the following two lines to the end of both default and staff in login.conf. Look OK? :passwordcheck=/path/to/program:\ :passwordtries=0: I understand that it would be easy (and redundant) to use minpasswordlen to meet the length requirement, but it's easy to check that in the program itself. Brad We are currently being reviewed for PCI DSS compliance, and the big problems we have right now with the combination of PCI DSS and OpenBSD is the following PCI DSS requirements: 8.5.12 Password history check - you may not use the last 4 passwords. 8.5.13 Lockout after 6 failed attempts - OpenBSD does not lock accounts automatically. 8.5.14 If 8.5.13 takes affect, the account must be locked for at least 30 minutes. I concluded the same for requirement 8. See my rough notes here. I plan to add to that page as I do more testing: http://16systems.com/OpenBSD/pci.html How have you addressed these requirements? I'm starting to think we need a RADIUS solution, which seems a bit redundant working with OpenBSD... Regards, Leif RADIUS may do it if the backend can enforce those things (I don't know enough about this to comment, but OpenLDAP may work). If that cannot do it, read Appendix B of the PCI DSS carefully. They allow compensating controls when the requirements cannot be followed precisely. Brad
Re: Force passwordcheck in login.conf
Leif Blixt wrote: Hi! We have just figured out a different approach, and will discuss our new idea with our QSA tomorrow. The idea is to completely turn of the possibility to log in with passwords, and to use SSH key pairs with long and good passphrases instead. It will lead to more work with administrating accounts and there is a small problem on how to distribute the public key to all servers, but we don't have to set up a RADIUS server just yet! I will let you know what the response from our QSA is. /Leif Can you do that? I think local logon would still be an issue, at least the way I read it. Anyone in front of the machine at a console would be subject to the requirements. Brad
Re: Force passwordcheck in login.conf
Well, I don't think so. You only need to logon to the console when you have big problems, and we just have set a really long and complicated password for the root user and stored it away for emergency use in a safe. You still have the external shell protection by restricting who can access the server room. All other users must use sudo anyway, so you don't need the root password on a daily basis, and that's enough for PCI DSS. /Leif -Original Message- From: Brad Tilley [mailto:b...@16systems.com] Sent: den 14 oktober 2010 14:09 To: Leif Blixt; openbsd-misc Subject: Re: Force passwordcheck in login.conf Leif Blixt wrote: Hi! We have just figured out a different approach, and will discuss our new idea with our QSA tomorrow. The idea is to completely turn of the possibility to log in with passwords, and to use SSH key pairs with long and good passphrases instead. It will lead to more work with administrating accounts and there is a small problem on how to distribute the public key to all servers, but we don't have to set up a RADIUS server just yet! I will let you know what the response from our QSA is. /Leif Can you do that? I think local logon would still be an issue, at least the way I read it. Anyone in front of the machine at a console would be subject to the requirements. Brad
Re: Force passwordcheck in login.conf
Hi! We have just figured out a different approach, and will discuss our new idea with our QSA tomorrow. The idea is to completely turn of the possibility to log in with passwords, and to use SSH key pairs with long and good passphrases instead. It will lead to more work with administrating accounts and there is a small problem on how to distribute the public key to all servers, but we don't have to set up a RADIUS server just yet! I will let you know what the response from our QSA is. /Leif -Original Message- From: Brad Tilley [mailto:b...@16systems.com] Sent: den 14 oktober 2010 13:36 To: Leif Blixt; openbsd-misc Subject: Re: Force passwordcheck in login.conf Leif Blixt wrote: Brad Tilley brad at 16systems.com writes: I was experimenting with a program to meet PCI DSS 1.2 password length and content/complexity requirements and integrating it with login.conf for users who have shell access to OpenBSD systems. It seems to work as expected, but I wanted to run my configuration by misc. I appended the following two lines to the end of both default and staff in login.conf. Look OK? :passwordcheck=/path/to/program:\ :passwordtries=0: I understand that it would be easy (and redundant) to use minpasswordlen to meet the length requirement, but it's easy to check that in the program itself. Brad We are currently being reviewed for PCI DSS compliance, and the big problems we have right now with the combination of PCI DSS and OpenBSD is the following PCI DSS requirements: 8.5.12 Password history check - you may not use the last 4 passwords. 8.5.13 Lockout after 6 failed attempts - OpenBSD does not lock accounts automatically. 8.5.14 If 8.5.13 takes affect, the account must be locked for at least 30 minutes. I concluded the same for requirement 8. See my rough notes here. I plan to add to that page as I do more testing: http://16systems.com/OpenBSD/pci.html How have you addressed these requirements? I'm starting to think we need a RADIUS solution, which seems a bit redundant working with OpenBSD... Regards, Leif RADIUS may do it if the backend can enforce those things (I don't know enough about this to comment, but OpenLDAP may work). If that cannot do it, read Appendix B of the PCI DSS carefully. They allow compensating controls when the requirements cannot be followed precisely. Brad
Re: which monitoring do you use (on OpenBSD)
Hi, On Sat, 14.08.2010 at 23:49:49 -0700, Bryan Irvine sparcta...@gmail.com wrote: understand. Also, the OP wanted something that he can run on OpenBSD and Zenoss runs on Linux. hmmm from my perspective, Zenoss looks like an ordinary Zope application, and should therefore run on OpenBSD as well. Kind regards, --Toni++
Re: Force passwordcheck in login.conf
Leif Blixt wrote: Well, I don't think so. You only need to logon to the console when you have big problems, and we just have set a really long and complicated password for the root user and stored it away for emergency use in a safe. You still have the external shell protection by restricting who can access the server room. All other users must use sudo anyway, so you don't need the root password on a daily basis, and that's enough for PCI DSS. /Leif Requirement 8.5 applies to non-consumer users and administrators I would assume that means root at a local console. Let me know what your QSA determines. It seems some of this is open to interpretation and depends on the opinion of the QSA. Brad -Original Message- From: Brad Tilley [mailto:b...@16systems.com] Sent: den 14 oktober 2010 14:09 To: Leif Blixt; openbsd-misc Subject: Re: Force passwordcheck in login.conf Leif Blixt wrote: Hi! We have just figured out a different approach, and will discuss our new idea with our QSA tomorrow. The idea is to completely turn of the possibility to log in with passwords, and to use SSH key pairs with long and good passphrases instead. It will lead to more work with administrating accounts and there is a small problem on how to distribute the public key to all servers, but we don't have to set up a RADIUS server just yet! I will let you know what the response from our QSA is. /Leif Can you do that? I think local logon would still be an issue, at least the way I read it. Anyone in front of the machine at a console would be subject to the requirements. Brad
Re: Force passwordcheck in login.conf
On Wed, Oct 13, 2010 at 09:09:29AM +, Leif Blixt wrote: Brad Tilley brad at 16systems.com writes: I was experimenting with a program to meet PCI DSS 1.2 password length and content/complexity requirements and integrating it with login.conf for users who have shell access to OpenBSD systems. It seems to work as expected, but I wanted to run my configuration by misc. I appended the following two lines to the end of both default and staff in login.conf. Look OK? :passwordcheck=/path/to/program:\ :passwordtries=0: I understand that it would be easy (and redundant) to use minpasswordlen to meet the length requirement, but it's easy to check that in the program itself. Brad We are currently being reviewed for PCI DSS compliance, and the big problems we have right now with the combination of PCI DSS and OpenBSD is the following PCI DSS requirements: 8.5.12 Password history check - you may not use the last 4 passwords. 8.5.13 Lockout after 6 failed attempts - OpenBSD does not lock accounts automatically. 8.5.14 If 8.5.13 takes affect, the account must be locked for at least 30 minutes. How have you addressed these requirements? I'm starting to think we need a RADIUS solution, which seems a bit redundant working with OpenBSD... Locking out accounts is actually fairly easy to do if you wrap /usr/libexec/auth/login_whatever. Read the AUTHENTICATION section of login.conf(5). Joachim
Re: iked(8) and ikectl(8)
Hi, On Thu, 03.06.2010 at 23:06:58 +0200, Reyk Floeter r...@openbsd.org wrote: IPsec. In difference to isakmpd(8), which supports the ISAKMP/Oakley a.k.a. IKEv1 protocol, iked(8) only supports the IKEv2 protocol at present. The IKEv2 protocol in RFC 4306 has been simplified and provides many benefits over ISAKMP/IKEv1. this means... (1) that only either iked OR isakmpd can run on one box? (2) on one IP, but share the same box? (3) or that iked has a dispatch mechanism to forward IKEv1 connections to a bystanding isakmpd, and cooperate with it to allow for using both types of connections on one IP? My guess is that it's (1), but my preference would be (3), of course. -- Kind regards, --Toni++
FW: Force passwordcheck in login.conf
For 8.5.12 see login.conf man page, look for passwordcheck. You will have to write (or find) a program that keeps track of previously used passwords. I just stored a hash of them in a file and have it check to see if the new password hash matches any of the old 4 password hashes. for 8.5.13 see login.conf man page, look for auth. You will (again) have to write a program that does this. In this case, you will be writing a new login authentication method. I haven't figured out how to integrate this with ssh, but in my case that doesn't apply as I disabled password login into ssh and everyone uses keys. Sadly, when I did all of this it was for work so the place I work owns the code and I have not been given permission to give that code away. I wrote mine in python because I know and understand python, but it could probably be done using any language. s We are currently being reviewed for PCI DSS compliance, and the big problems we have right now with the combination of PCI DSS and OpenBSD is the following PCI DSS requirements: 8.5.12 Password history check - you may not use the last 4 passwords. 8.5.13 Lockout after 6 failed attempts - OpenBSD does not lock accounts automatically. 8.5.14 If 8.5.13 takes affect, the account must be locked for at least 30 minutes. How have you addressed these requirements? I'm starting to think we need a RADIUS solution, which seems a bit redundant working with OpenBSD... Regards, Leif
Re: FW: Force passwordcheck in login.conf
Stuart VanZee wrote: For 8.5.12 see login.conf man page, look for passwordcheck. You will have to write (or find) a program that keeps track of previously used passwords. I just stored a hash of them in a file and have it check to see if the new password hash matches any of the old 4 password hashes. I considered that as a possible solution as well, but it seems that approach would weaken the security of the passwords, especially if you just use an unsalted hash (md5 or sah1) to store them. Brad
machine-dependent tweaks to /usr/src/etc
On Wed, 2010-10-13 at 19:47 -0600, Theo de Raadt wrote: There has been talk about going thourgh /usr/src/etc and building machine-dependent (that means architecture-dependent for those of you who are not on The Team) variations for this. People who dug into this got scared and didn't finish. We'd be willing to look at things other people start for this... and then provide a long series of comments... if someone has the staying power... Perhaps lower hanging fruit would be for those that regularly tweak /etc to occasionally send in sanitized diffs against the originals with comments as to why the changes were made. Changes that appear for many people probably should eventually go into the FAQ. (Sorry, I don't have any tweaks... 4.7 required no tweaks outside of turning on IP forwarding in /etc/sysctl.conf...) Thanks, Chris Dukes
Re: FW: Force passwordcheck in login.conf
On Thu, Oct 14, 2010 at 10:16:12AM -0400, Brad Tilley wrote: Stuart VanZee wrote: For 8.5.12 see login.conf man page, look for passwordcheck. You will have to write (or find) a program that keeps track of previously used passwords. I just stored a hash of them in a file and have it check to see if the new password hash matches any of the old 4 password hashes. I considered that as a possible solution as well, but it seems that approach would weaken the security of the passwords, especially if you just use an unsalted hash (md5 or sah1) to store them. You could use blowfish to store them; the code already exists in the openbsd base. Storing multiple previous passwords has always seemed gratuitous to me, but we're not discussing technical merits, just technical solutions to management fiats... Brad
Cher Client de La Banque Postale : Attention! Votre Compte � ete limite!
Les informations concernant votre compte: Cher Client de La Banque Postale : Attention! Votre Compte ` ete limite! Dans le cadre de nos mesures de sicuriti, nous procedons regulierement ` la virification du bien jtre de nos clients .Postale d'apprendre recemment Vous ont contacte apres avoir releve un probleme sur votre Account.We demande des informations Aupres de vous pour la raison suivante: Notre systeme a detecte charges inhabituelles une carte de credit liee ` votre Compte La Banque Postale. Cliquez Ici pour activer votre compte Cordialement, La Banque Postale Email ID: 5138-8872 Departement de l'examen des comptes de La Banque Postale. Le Corp Copyright 1999-2010 La Banque Postale. Tous droits reserves.
Re: computer hangs after varying amount of data is received from network via ssh
On 2010-10-13, Robert Halberg robert.halb...@gmail.com wrote: bios0: vendor Award Software, Inc. version ASUS A7V-E ACPI BIOS Revision 1002D date 03/08/2001 bios0: ASUSTeK Computer INC. A7V-E apm0 at bios0: Power Management spec V1.2 (BIOS management disabled) You could try boot -c, disable apm and quit, preferably with 4.8 or -current. Might help, might not. There are also newer bioses available, there's a chance they may help, but there's also a chance you end up with a dead motherboard by attempting to flash. From what I remember some of those early VIA KT chipsets had pretty broken PCI implementations...
Re: Force passwordcheck in login.conf
On 2010-10-13, Brad Tilley b...@16systems.com wrote: Mark Romer wrote: use passwdqc it is in packages. in login.conf under default I have: :minpasswordlen=12:\ :login-tries=4:\ :passwordtries=3:\ :passwordcheck=/usr/local/libexec/passwdqc -3 12 Mark I've heard complaints that it is too stringent (I tend to agree, no offense to Solar). PCI DSS 1.2 only requires numbers and alphabetic chars in the password. So, letmein123 meets the requirement. See passwdqc.conf(5).
Re: Trouble with FTP install on virtual machine
On 09/15/2010 07:33 PM, li...@telus.net wrote: I hope it's not inappropriate to ask about VM's in this forum. If anyone cares to offer some advice, here's what I'm having trouble with: I've created a virtual computer on Windows Hyper-V Server 2008 R2. I'm trying to install -current via FTP or HTTP. I can boot from either floppy48.fs or cd48.iso. The virtual NIC is detected as de0. Basic network functionality seems to be working. I can ping hosts by name, for example. I can proceed through the installation, partition the virtual disk and so on, until I get about this far: Location of sets? (cd disk ftp http or 'done') [cd] ftp HTTP/FTP proxy URL? (e.g. 'http://proxy:8800', or 'none') [none] Server? (hostname, list#, 'done' or '?') [ftp.OpenBSD.org] ftp5.usa.openbsd.org Server directory? [pub/OpenBSD/snapshots/i386] Login? [anonymous] Select sets by entering a set name, a file name pattern or 'all'. De-select sets by prepending a '-' to the set name, file name pattern or 'all'. Selected sets are labelled '[X]'. [X] bsd[X] etc48.tgz [X] game48.tgz [X] xfont48.tgz [X] bsd.rd [X] misc48.tgz [X] xbase48.tgz[X] xserv48.tgz [ ] bsd.mp [X] comp48.tgz [X] xect48.tgz [X] xbase48.tgz[X] man48.tgz [X] xshare48.tgz Set names(s)? (or 'abort' or 'done') [done] bsd 7% |**| 677 KB - stalled - I've tried this with a few different mirrors. Sometimes it got a bit farther before stalling. Sometimes it times out completely. I'm guessing that the 'legacy' virtual NIC (de0) is at fault, but I don't know what (if anything) I might do about it. I can see from searching online that other people have succeeded with OpenBSD on virtual machines. Has anyone here tried on a Hyper-V server? Any advice would be appreciated. Thanks, Richard Koett. Have you tried install48.iso (which includes the sets)? You should be able to get OpenBSD installed correctly, one that's done, you can test the network properly.
Re: snapshot packages?
On Oct 14 15:18:49, frantisek holop wrote: hmm, on Thu, Oct 14, 2010 at 03:02:42PM +0200, Jan Stary said that Snapshots and snapshot packages move forward all the time, unlike your installed system. If you have a system that provides libcurses.so.10.0, and (a new version of) a package comes out that requires libcurses.so.11.0, there is simply no way to upgrade the package, because your system does not meet the package's requirements. That's exactly what pkg_add is telling you. at the time of writing i was using the latest OS snapshot.. as far as i know snapshot packages are compiled on snapshot systems. i am curious how can i get bad major errors from packages on the latest snapshot. i simply expected the oct 9/10 snapshot packages to match with the oct 6 system snapshot. That exactly is your wrong expectation. what is the good one then? if i cannot expect the latest system snapshot to use the latest package snapshots, how is one supposed to keep using -current? The only point in time when the base system, ports and packages are guaranteed to be in sync is a release. I cannot be bothered to find this in the faq somewhere. i have been using -current exactly like this for more than 10 years. 1. install snaphost, 2. install snapshot packages. 99% of the time this worked great. Exactly. That's what I am doing too. You just hit the case when a package (built on 10/9) requires a library which a sytem built on 10/6 does not have. So what?
EuroBSDCon 2011 Call for Proposals
EuroBSDCon 2011 === EuroBSDCon is the European technical conference for users and developers on BSD based systems. The EuroBSDCon 2011 conference will be held in the Netherlands from thursday 6 october 2011 to sunday 9 october 2011, with tutorials on thursday and friday and talks on saturday and sunday. Call for Proposals -- The EuroBSDCon conference is inviting developers and users of BSD based systems to submit innovative and original papers not submitted to other European conferences on BSD related topics. Topics of interest to the conference include, but are not limited to applications, architecture, implementation, performance and security of BSD based operating systems, as well as topics concerning the economic or organizational aspects of BSD use. Presentations are expected to be 45 or 90 minutes, please indicate the approximate time slot size when submitting your abstract. Call for Tutorial Proposals --- The EuroBSDCon conference is inviting qualified practitioners in their field to submit proposals for half or full day tutorials on topics relevant to development, implementation and use of BSD based systems. Submission address -- Proposals should be submitted by email to submiss...@eurobsdcon.org Important dates --- The EuroBSDCon conference is accepting abstracts and tutorial proposals until May 15th, 2011. Other important dates will be announced soon at the conference website http://2011.eurobsdcon.org/
Trouble getting groups through ypldap
I'm attempting to setup OpenLDAP, Samba and ypldap on 4.7. OpenLDAP is
up and running along with Samba, and I've used the smbldap tools to
populate the directory.
I'm having trouble getting the full list of LDAP groups with getent.
At first I ran getent group and didn't see any of the LDAP groups.
Then I noticed that the ypldap.conf example uses basedn
ou=Users,dc=domain,dc=tld, so I changed it to basedn
dc=domain,dc=tld. Now getent group shows only the first of the LDAP
groups:
# getent group
...
nogroup:*:32766
nobody:*:32767
_openldap:*:544
_dbus:*:572
_avahi:*:629
_avahi-autoipd:*:630
_cups:*:541
Domain Admins:*:512:root
I ran the equivalent search that ypldap was doing (based on watching
OpenLDAP in the foreground) and got the full list of groups. So it
looks like something between OpenLDAP and ypldap isn't working quite
right. I looked at the changes to ypldap since 4.7 and there doesn't
seem to be anything relevant.
I'm out of ideas for troubleshooting short of trying a snapshot, which
I'll try later today.
Any ideas where to look next?
Here's my ypldap.conf:
domain pmh.org
interval 30
provide map passwd.byname
provide map passwd.byuid
provide map group.byname
provide map group.bygid
directory ldap.pmh.org {
binddn cn=Manager,dc=pmh,dc=org
bindcred secret
# basedn ou=Users,dc=pmh,dc=org
basedn dc=pmh,dc=org
passwd filter (objectClass=posixAccount)
attribute name maps to uid
fixed attribute passwd *
attribute uid maps to uidNumber
attribute gid maps to gidNumber
attribute gecos maps to cn
attribute home maps to homeDirectory
fixed attribute shell loginShell
fixed attribute change 0
fixed attribute expire 0
fixed attribute class ldap
group filter (objectClass=posixGroup)
attribute groupname maps to cn
fixed attribute grouppasswd *
attribute groupgid maps to gidNumber
list groupmembers maps to memberUid
}
And dmesg:
OpenBSD 4.7 (GENERIC) #558: Wed Mar 17 20:46:15 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III (GenuineIntel 686-class, 128KB L2 cache) 898 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXS
R,SSE
real mem = 266694656 (254MB)
avail mem = 249700352 (238MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 08/23/01, BIOS32 rev. 0 @ 0xfda74, SMBIOS
rev. 2.3 @ 0xf0ff0 (49 entries)
bios0: vendor Intel Corp. version CB81010A.15A.0026.P05.0108230926 date 08/23/
2001
bios0: Gateway E-1600
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
acpi at bios0 function 0x0 not configured
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf3370/144 (7 entries)
pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82371FB ISA rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0xc000 0xcc000/0x1000 0xcd000/0x1000
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82810E Host rev 0x03
vga1 at pci0 dev 1 function 0 Intel 82810E Video rev 0x03
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0xf800, size 0x400
ppb0 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0x02
pci1 at ppb0 bus 1
fxp0 at pci1 dev 8 function 0 Intel 82562 rev 0x01, i82562: irq 5, address 00:
03:47:a3:9b:b8
inphy0 at fxp0 phy 1: i82562ET 10/100 PHY, rev. 0
ichpcib0 at pci0 dev 31 function 0 Intel 82801BA LPC rev 0x02: 24-bit timer at
3579545Hz
pciide0 at pci0 dev 31 function 1 Intel 82801BA IDE rev 0x02: DMA, channel 0 w
ired to compatibility, channel 1 wired to compatibility
atapiscsi0 at pciide0 channel 0 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: LG, CD-ROM CRD-8483B, 1.06 ATAPI 5/cdrom removab
le
cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
wd0 at pciide0 channel 1 drive 0: Maxtor 2F040L0
wd0: 16-sector PIO, LBA, 39205MB, 80293248 sectors
wd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 5
uhci0 at pci0 dev 31 function 2 Intel 82801BA USB rev 0x02: irq 10
ichiic0 at pci0 dev 31 function 3 Intel 82801BA SMBus rev 0x02: irq 9
iic0 at ichiic0
admtm0 at iic0 addr 0x2d: adm1025
spdmem0 at iic0 addr 0x50: 256MB SDRAM non-parity PC133CL3
auich0 at pci0 dev 31 function 5 Intel 82801BA AC97 rev 0x02: irq 9, ICH2 AC97
ac97: codec id 0x4352594d (Cirrus Logic CS4201 rev 5)
ac97: codec features 20 bit DAC, 18 bit ADC, Crystal Semi 3D
audio0 at auich0
isa0 at ichpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: 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
midi0 at pcppi0: PC speaker
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
Re: Auto Logout Idle Users
Brad Tilley wrote: I created the file /etc/profile to force sh and ksh to logout users after a certain period of idleness: $ cat /etc/profile # Force sh and ksh to logout idle users after 15 minutes # Prevent normal users from disabling this setting readonly TMOUT=900 export TMOUT That works great. I've tried to do the same to the other default shell in base (csh). I added 'set autologout=15' to /etc/csh.cshrc and then to /etc/csh.login as well (I'm turning knobs like a good clueless user). I then read the csh man page, but saw no mention of autologout. Perhaps the OpenBSD version of csh does not support this? Is there a way to do this with csh? If not, I'll need to remove access to the shell. Replying to myself. I can't seem to make csh auto logout inactive users. So I did this: rm /bin/csh cp /bin/ksh /bin/csh Any good reason to not do this? Brad
Re: Auto Logout Idle Users
Any good reason to not do this? They're not the same shell. I can't think of any security reasons because I'm not familiar with the code but as far as logs and noise factor I imagine it would go up or various things might start breaking that depend on csh.
Re: Auto Logout Idle Users
Adam M. Dutko wrote: Any good reason to not do this? They're not the same shell. Yes, I know that part :) I can't think of any security reasons because I'm not familiar with the code but as far as logs and noise factor I imagine it would go up or various things might start breaking that depend on csh. Base seems to only have two shells as ksh and sh have the same md5 checksum. I'm hoping csh is only included for historical reasons or in honor of Bill Joy or something such as that. Brad
Re: Auto Logout Idle Users
On Oct 14 15:28:20, Brad Tilley wrote: Brad Tilley wrote: I created the file /etc/profile to force sh and ksh to logout users after a certain period of idleness: Why do you want to logout idle users? There is sysutils/idled if you need it. $ cat /etc/profile # Force sh and ksh to logout idle users after 15 minutes # Prevent normal users from disabling this setting readonly TMOUT=900 export TMOUT That works great. I've tried to do the same to the other default shell in base (csh). I added 'set autologout=15' to /etc/csh.cshrc and then to /etc/csh.login as well (I'm turning knobs like a good clueless user). I then read the csh man page, but saw no mention of autologout. Perhaps the OpenBSD version of csh does not support this? Is there a way to do this with csh? If not, I'll need to remove access to the shell. Why? Replying to myself. I can't seem to make csh auto logout inactive users. So I did this: rm /bin/csh cp /bin/ksh /bin/csh lol wut? Any good reason to not do this? You just forced your csh users to use ksh. Why do you want them to hate you? Why don't you also 'mv /bin/rm /bin/ls' while you are at it? Base seems to only have two shells as ksh and sh have the same md5 checksum. And the same inode number. I'm hoping csh is only included for historical reasons or in honor of Bill Joy or something such as that. Or maybe to be used by the thousands of people that want to use it.
Re: Auto Logout Idle Users
Jan Stary wrote: Why do you want to logout idle users? There is sysutils/idled if you need it. I'm experimenting with getting an OpenBSD base system to meet the PCI DSS requirements. I'm trying to avoid using any software outside the base system. rm /bin/csh cp /bin/ksh /bin/csh You just forced your csh users to use ksh. Why do you want them to hate you? It's just a shell, they'll get over it. Why don't you also 'mv /bin/rm /bin/ls' while you are at it? Not a very similar comparison.
Re: Auto Logout Idle Users
rm /bin/csh cp /bin/ksh /bin/csh You just forced your csh users to use ksh. Why do you want them to hate you? It's just a shell, they'll get over it. Remove it from /etc/shells instead. Replacing csh with ksh is evil, and I don't mean that in a good way. -- Darrin Chandler| Phoenix BSD User Group | MetaBUG dwchand...@stilyagin.com | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: Auto Logout Idle Users
On Oct 14 17:01:30, Brad Tilley wrote: Jan Stary wrote: Why do you want to logout idle users? There is sysutils/idled if you need it. I'm experimenting with getting an OpenBSD base system to meet the PCI DSS requirements. Does PCI DSS require you to log users out? I'm trying to avoid using any software outside the base system. rm /bin/csh cp /bin/ksh /bin/csh You just forced your csh users to use ksh. Why do you want them to hate you? It's just a shell, they'll get over it. Unbelievable.
Re: Auto Logout Idle Users
On Thu, Oct 14, 2010 at 4:01 PM, Brad Tilley b...@16systems.com wrote: Jan Stary wrote: Why do you want to logout idle users? There is sysutils/idled if you need it. I'm experimenting with getting an OpenBSD base system to meet the PCI DSS requirements. I'm trying to avoid using any software outside the base system. rm /bin/csh cp /bin/ksh /bin/csh You just forced your csh users to use ksh. Why do you want them to hate you? It's just a shell, they'll get over it. Also their scripts, and transparently... Why don't you also 'mv /bin/rm /bin/ls' while you are at it? Not a very similar comparison.
Licitaciones Públicas de Adquisiciones en México D.F., 27 de Octubre
[IMAGE] !Promociones Especiales para Grupos! Mayores informes responda este correo electrsnico con los siguientes datos. Empresa: Nombre: Telifono: Email: Nzmero de Interesados: Y en breve le haremos llegar la informacisn completa del evento. O bien comunmquense a nuestros telifonos un ejecutivo con gusto le atendera Tels. (33) 8851-2365, (33)8851-2741. Copyright (C) 2010, PMS Capacitacisn Efectiva de Mixico S.C. Derechos Reservados. PMS de Mixico, El logo de PMS de Mixico son marcas registradas. ADVERTENCIA PMS de Mixico no cuenta con alianzas estratigicas de ningzn tipo dentro de la Republica Mexicana. NO SE DEJE ENGAQAR - DIGA NO A LA PIRATERIA. Todos los logotipos, marcas comerciales e imagenes son propiedad de sus respectivas corporaciones y se utilizan con fines informativos solamente. Este Mensaje ha sido enviado a misc@openbsd.org como usuario de Pms de Mixico o bien un usuario le refiris para recibir este boletmn. Como usuario de Pms de Mixico, en este acto autoriza de manera expresa que Pms de Mixico le puede contactar vma correo electrsnico u otros medios. Si usted ha recibido este mensaje por error, haga caso omiso de el y reporte su cuenta respondiendo este correo con el subject BAJA Unsubscribe to this mailing list, reply a blank message with the subject UNSUBSCRIBE BAJA Tenga en cuenta que la gestisn de nuestras bases de datos es de suma importancia y no es intencisn de la empresa la inconformidad del receptor. [demime 1.01d removed an attachment of type image/jpeg which had a name of =?windows-1252?Q?licitaciones_p=FAblicas.jpg?=]
Re: Auto Logout Idle Users
On 10/14/2010 05:08 PM, Darrin Chandler wrote: rm /bin/csh cp /bin/ksh /bin/csh You just forced your csh users to use ksh. Why do you want them to hate you? It's just a shell, they'll get over it. Remove it from /etc/shells instead. Replacing csh with ksh is evil, and I don't mean that in a good way. I thought about doing that too. I need to test it more to see what happens when ksh is the shell and the user executes csh manually. I suppose ksh will still honor TMOUT in that case. Brad
Re: Auto Logout Idle Users
On 10/14/2010 05:13 PM, Jan Stary wrote: On Oct 14 17:01:30, Brad Tilley wrote: Jan Stary wrote: Why do you want to logout idle users? There is sysutils/idled if you need it. I'm experimenting with getting an OpenBSD base system to meet the PCI DSS requirements. Does PCI DSS require you to log users out? After 15 minutes of inactivity, users must re-enter the password. Something such as that. I'm trying to avoid using any software outside the base system. rm /bin/csh cp /bin/ksh /bin/csh You just forced your csh users to use ksh. Why do you want them to hate you? It's just a shell, they'll get over it. Unbelievable. I'm not actually doing this to users on an existing system. I'm just experimenting. Thinking out loud about the issues before having to deal with it.
Atención Almacenistas: Seminario de Actualización este 25 de Octubre.
[IMAGE] Duracisn: 10 Horas de entrenamiento. Presentado por nuestro experto consultor: Lic. Gerardo Coronado L. !Promociones Especiales para Grupos! Mayores informes responda este correo electrsnico con los siguientes datos. Empresa: Nombre: Telifono: Email: Nzmero de Interesados: Y en breve le haremos llegar la informacisn completa del evento. O bien comunmquense a nuestros telifonos un ejecutivo con gusto le atendera Tels. (33) 8851-2365, (33)8851-2741. Copyright (C) 2010, PMS Capacitacisn Efectiva de Mixico S.C. Derechos Reservados. PMS de Mixico, El logo de PMS de Mixico son marcas registradas. ADVERTENCIA PMS de Mixico no cuenta con alianzas estratigicas de ningzn tipo dentro de la Republica Mexicana. NO SE DEJE ENGAQAR - DIGA NO A LA PIRATERIA. Todos los logotipos, marcas comerciales e imagenes son propiedad de sus respectivas corporaciones y se utilizan con fines informativos solamente. Este Mensaje ha sido enviado a misc@openbsd.org como usuario de Pms de Mixico o bien un usuario le refiris para recibir este boletmn. Como usuario de Pms de Mixico, en este acto autoriza de manera expresa que Pms de Mixico le puede contactar vma correo electrsnico u otros medios. Si usted ha recibido este mensaje por error, haga caso omiso de el y reporte su cuenta respondiendo este correo con el subject BAJAASISTENTES Unsubscribe to this mailing list, reply a blank message with the subject UNSUBSCRIBE BAJAASISTENTES Tenga en cuenta que la gestisn de nuestras bases de datos es de suma importancia y no es intencisn de la empresa la inconformidad del receptor. [demime 1.01d removed an attachment of type image/jpeg which had a name of almacenes.jpg]
Re: Auto Logout Idle Users
On Thu, 14 Oct 2010 18:17:23 -0400 Brad Tilley b...@16systems.com wrote: On 10/14/2010 05:08 PM, Darrin Chandler wrote: rm /bin/csh cp /bin/ksh /bin/csh You just forced your csh users to use ksh. Why do you want them to hate you? It's just a shell, they'll get over it. Remove it from /etc/shells instead. Replacing csh with ksh is evil, and I don't mean that in a good way. I thought about doing that too. I need to test it more to see what happens when ksh is the shell and the user executes csh manually. I suppose ksh will still honor TMOUT in that case. Brad Don't mean to complicate things for you, but just thought I should mention that if the user does: # exec /bin/csh Then csh takes over ksh's active process, and even though the TMOUT variable is still there, csh doesn't honor it, and ksh is no longer around to object. -Ben -- be...@bendtel.com
Re: Trouble getting groups through ypldap
It could be the groups your missing have no members, which fails to output the
group. You can confirm this my adding a user to one of the groups, and see if
the group is displayed. This following change, rather than skipping output of
the group, outputs group with a null list of members.
Regards
Nigel Taylor
$ cvs -R -q -d /cvs diff -u
Index: ldapclient.c
===
RCS file: /cvs/src/usr.sbin/ypldap/ldapclient.c,v
retrieving revision 1.14
diff -u -r1.14 ldapclient.c
--- ldapclient.c6 Jun 2009 05:02:58 - 1.14
+++ ldapclient.c5 Jul 2009 18:18:35 -
@@ -611,7 +611,7 @@
}
} else if (idm-idm_list F_LIST(i)) {
if (aldap_match_entry(m, attrs[j++],
ldap_attrs) == -1)
- goto next_grpentry;
+ continue;
if (ldap_attrs[0] == NULL)
goto next_grpentry;
for (k = 0; k = 0 ldap_attrs[k] != NULL;
k++) {
On 10/14/10 20:15, John Danks wrote:
I'm attempting to setup OpenLDAP, Samba and ypldap on 4.7. OpenLDAP is
up and running along with Samba, and I've used the smbldap tools to
populate the directory.
I'm having trouble getting the full list of LDAP groups with getent.
At first I ran getent group and didn't see any of the LDAP groups.
Then I noticed that the ypldap.conf example uses basedn
ou=Users,dc=domain,dc=tld, so I changed it to basedn
dc=domain,dc=tld. Now getent group shows only the first of the LDAP
groups:
# getent group
...
nogroup:*:32766
nobody:*:32767
_openldap:*:544
_dbus:*:572
_avahi:*:629
_avahi-autoipd:*:630
_cups:*:541
Domain Admins:*:512:root
I ran the equivalent search that ypldap was doing (based on watching
OpenLDAP in the foreground) and got the full list of groups. So it
looks like something between OpenLDAP and ypldap isn't working quite
right. I looked at the changes to ypldap since 4.7 and there doesn't
seem to be anything relevant.
I'm out of ideas for troubleshooting short of trying a snapshot, which
I'll try later today.
Any ideas where to look next?
Here's my ypldap.conf:
domain pmh.org
interval 30
provide map passwd.byname
provide map passwd.byuid
provide map group.byname
provide map group.bygid
directory ldap.pmh.org {
binddn cn=Manager,dc=pmh,dc=org
bindcred secret
# basedn ou=Users,dc=pmh,dc=org
basedn dc=pmh,dc=org
passwd filter (objectClass=posixAccount)
attribute name maps to uid
fixed attribute passwd *
attribute uid maps to uidNumber
attribute gid maps to gidNumber
attribute gecos maps to cn
attribute home maps to homeDirectory
fixed attribute shell loginShell
fixed attribute change 0
fixed attribute expire 0
fixed attribute class ldap
group filter (objectClass=posixGroup)
attribute groupname maps to cn
fixed attribute grouppasswd *
attribute groupgid maps to gidNumber
list groupmembers maps to memberUid
}
And dmesg:
OpenBSD 4.7 (GENERIC) #558: Wed Mar 17 20:46:15 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III (GenuineIntel 686-class, 128KB L2 cache) 898 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXS
R,SSE
real mem = 266694656 (254MB)
avail mem = 249700352 (238MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 08/23/01, BIOS32 rev. 0 @ 0xfda74,
SMBIOS
rev. 2.3 @ 0xf0ff0 (49 entries)
bios0: vendor Intel Corp. version CB81010A.15A.0026.P05.0108230926 date
08/23/
2001
bios0: Gateway E-1600
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
acpi at bios0 function 0x0 not configured
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf3370/144 (7 entries)
pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82371FB ISA rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0xc000 0xcc000/0x1000 0xcd000/0x1000
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82810E Host rev 0x03
vga1 at pci0 dev 1 function 0 Intel 82810E Video rev 0x03
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0xf800, size 0x400
ppb0 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0x02
pci1 at ppb0 bus 1
fxp0 at pci1 dev 8 function 0 Intel 82562 rev 0x01, i82562: irq 5, address
00:
03:47:a3:9b:b8
inphy0 at fxp0 phy 1: i82562ET 10/100 PHY, rev. 0
ichpcib0 at pci0 dev 31 function 0 Intel 82801BA LPC rev 0x02:
Re: Auto Logout Idle Users
On 10/14/2010 06:45 PM, Ben Niccum wrote: I thought about doing that too. I need to test it more to see what happens when ksh is the shell and the user executes csh manually. I suppose ksh will still honor TMOUT in that case. Brad Don't mean to complicate things for you, but just thought I should mention that if the user does: # exec /bin/csh Then csh takes over ksh's active process, and even though the TMOUT variable is still there, csh doesn't honor it, and ksh is no longer around to object. -Ben Great point. That's precisely the sort of thing I'd like to have thought about. Much of the compliance efforts may look good on paper, but have no impact on actual usage or may be trivially circumvented as you point out. So while disabling a shell may get a check mark during PCI compliance efforts, that may be all you end up with. Brad
Re: Auto Logout Idle Users
Much of the compliance efforts may look good on paper, but have no impact on actual usage or may be trivially circumvented or even worse, will likely end up compromising security in case somebody aiming for hardening manipulates the system without fully understanding the consequences.
Re: Trouble getting groups through ypldap
On Thu, Oct 14, 2010 at 2:38 PM, Nigel Taylor njtay...@asterisk.demon.co.uk wrote: It could be the groups your missing have no members, which fails to output the group. You can confirm this my adding a user to one of the groups, and see if the group is displayed. This following change, rather than skipping output of the group, outputs group with a null list of members. Thanks, that was the problem. Adding a member to the groups made them show up through getent.
Re: Auto Logout Idle Users
2010/10/13 Brad Tilley b...@16systems.com: That works great. I've tried to do the same to the other default shell in base (csh). I added 'set autologout=15' to /etc/csh.cshrc and then to /etc/csh.login as well (I'm turning knobs like a good clueless user). I then read the csh man page, but saw no mention of autologout. Perhaps the OpenBSD version of csh does not support this? Is there a way to do this with csh? If not, I'll need to remove access to the shell. I know that TCSH have the autologout feature. Deveolpers, just for curiosity (no flame war please): There is any problem IF the tcsh replaces the csh on the base system? Thanks, Mosconi
