Re: partly resolved: Re: nut problems, was Re: Can't believe I'm asking this... What's a serial port on an OpenBSD system?
On Mon, 13 Feb 2006 18:58:19 +, Stuart Henderson wrote: > > seems like NUT permissions (it has it's own usernames/passwords > to e.g. allow monitoring a UPS without allowing shutdowns) rather > than anything on the UPS. carefully check configs/docs. > Because the error comes from upsmon rather than upsd or the driver itself? Makes sense. One thing I hadn't done was change the ownership on the serial port. But by your logic, if this was a problem, the driver should have complained. It didn't, and changing the ownership made no difference that I can see. So I'm still looking. This'll likely take a while. Thanks! -- David Benfell, LCP [EMAIL PROTECTED] --- Resume available at http://www.parts-unknown.org/
partly resolved: Re: nut problems, was Re: Can't believe I'm asking this... What's a serial port on an OpenBSD system?
On Mon, 13 Feb 2006 10:10:57 -0800, David Benfell wrote: > > > So I tried running the driver in debug mode... > > > cyberpower -a lupin1500AVR -u nutmon -D ^ This appears to be key. Apparently even adding a user directive to ups.conf is insufficient. Modifying rc.local to run upsdrvctl with the -u option seems to resolve the problem. I still see: Feb 13 10:37:54 lupin ntpd[24521]: ntpd [EMAIL PROTECTED] Wed Mar 24 05:29:33 MST 2004 (1) Feb 13 10:37:54 lupin ntpd[24521]: precision = 1.000 usec Feb 13 10:37:55 lupin ntpd[24521]: frequency initialized 371.616 PPM from /etc/ntp.drift Feb 13 10:37:57 lupin cyberpower[1459]: Startup successful Feb 13 10:37:57 lupin upsd[1891]: Connected to UPS [lupin1500AVR]: cyberpower-tty01 Feb 13 10:37:57 lupin upsd[17855]: Startup successful Feb 13 10:37:57 lupin upsmon[5434]: Startup successful Feb 13 10:37:57 lupin upsd[17855]: Connection from 127.0.0.1 Feb 13 10:37:57 lupin upsd[17855]: Client [EMAIL PROTECTED] logged into UPS [lupin1500AVR] Feb 13 10:37:57 lupin upsmon[31324]: Master privileges unavailable on UPS [EMAIL PROTECTED] Feb 13 10:37:57 lupin upsmon[31324]: Reason: Access denied This UPS is about 2 years old, but fairly substantial -- I can generally go at least 1-1/2 hours on its battery. I had the impression it has fairly high-end capabilities. Am I missing something else that would cause "master privileges" to be "unavailable?" -- David Benfell, LCP [EMAIL PROTECTED] --- Resume available at http://www.parts-unknown.org/
nut problems, was Re: Can't believe I'm asking this... What's a serial port on an OpenBSD system?
lues, and multiply by 3. DEADTIME 15 # -- # POWERDOWNFLAG - Flag file for forcing UPS shutdown on the master system # # upsmon will create a file with this name in master mode when it's time # to shut down the load. You should check for this file's existence in # your shutdown scripts and run 'upsdrvctl shutdown' if it exists. # # See the shutdown.txt file in the docs subdirectory for more information. POWERDOWNFLAG /etc/killpower # -- # NOTIFYMSG - change messages sent by upsmon when certain events occur # # You can change the stock messages to something else if you like. # # NOTIFYMSG "message" # # NOTIFYMSG ONLINE "UPS %s is getting line power" # NOTIFYMSG ONBATT "Someone pulled the plug on %s" # # Note that %s is replaced with the identifier of the UPS in question. # # Possible values for : # # ONLINE : UPS is back online # ONBATT : UPS is on battery # LOWBATT : UPS has a low battery (if also on battery, it's "critical") # FSD : UPS is being shutdown by the master (FSD = "Forced Shutdown") # COMMOK : Communications established with the UPS # COMMBAD : Communications lost to the UPS # SHUTDOWN : The system is being shutdown # REPLBATT : The UPS battery is bad and needs to be replaced # NOCOMM : A UPS is unavailable (can't be contacted for monitoring) # -- # NOTIFYFLAG - change behavior of upsmon when NOTIFY events occur # # By default, upsmon sends walls (global messages to all logged in users) # and writes to the syslog when things happen. You can change this. # # NOTIFYFLAG [+][+] ... # # NOTIFYFLAG ONLINE SYSLOG # NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC # # Possible values for the flags: # # SYSLOG - Write the message in the syslog # WALL - Write the message to all users on the system # EXEC - Execute NOTIFYCMD (see above) with the message # IGNORE - Don't do anything # # If you use IGNORE, don't use any other flags on the same line. NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC NOTIFYFLAG FSD SYSLOG+WALL+EXEC NOTIFYFLAG COMMOK SYSLOG+WALL+EXEC NOTIFYFLAG COMMBAD SYSLOG+WALL+EXEC NOTIFYFLAG SHUTDOWN SYSLOG+WALL+EXEC NOTIFYFLAG REPLBATT SYSLOG+WALL+EXEC NOTIFYFLAG NOCOMM SYSLOG+WALL+EXEC # -- # RBWARNTIME - replace battery warning time in seconds # # upsmon will normally warn you about a battery that needs to be replaced # every 43200 seconds, which is 12 hours. It does this by triggering a # NOTIFY_REPLBATT which is then handled by the usual notify structure # you've defined above. # # If this number is not to your liking, override it here. RBWARNTIME 43200 # -- # NOCOMMWARNTIME - no communications warning time in seconds # # upsmon will let you know through the usual notify system if it can't # talk to any of the UPS entries that are defined in this file. It will # trigger a NOTIFY_NOCOMM by default every 300 seconds unless you # change the interval with this directive. NOCOMMWARNTIME 300 # -- # FINALDELAY - last sleep interval before shutting down the system # # On a master, upsmon will wait this long after sending the NOTIFY_SHUTDOWN # before executing your SHUTDOWNCMD. If you need to do something in between # those events, increase this number. Remember, at this point your UPS is # almost depleted, so don't make this too high. # # Alternatively, you can set this very low so you don't wait around when # it's time to shut down. Some UPSes don't give much warning for low # battery and will require a value of 0 here for a safe shutdown. # # Note: If FINALDELAY on the slave is greater than HOSTSYNC on the master, # the master will give up waiting for the slave to disconnect. FINALDELAY 5 -- David Benfell, LCP [EMAIL PROTECTED] --- Resume available at http://www.parts-unknown.org/
Can't believe I'm asking this... What's a serial port on an OpenBSD system?
ra-DMA mode 5 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: <, CD-ROM CMD5X11, 1.06> SCSI0 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 4 auvia0 at pci0 dev 17 function 5 "VIA VT8233 AC97" rev 0x50: irq 5 ac97: codec id 0x49434552 (ICEnsemble VIA VT1616i) ac97: codec features headphone, 18 bit DAC, 18 bit ADC, KS Waves 3D audio0 at auvia0 isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: spkr0 at pcppi0 sysbeep0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 it0 at isa0 port 0x290/8: IT87 npx0 at isa0 port 0xf0/16: using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 biomask ff65 netmask ff65 ttymask ffe7 pctr: user-level cycle counter enabled dkcsum: wd0 matches BIOS drive 0x80 root on wd0a rootdev=0x0 rrootdev=0x300 rawdev=0x302 uaudio0 at uhub0 port 1 configuration 1 interface 1: Logitech Camera, rev 1.00/1.00, addr 2 uaudio0: audio rev 1.00, 5 mixer controls audio1 at uaudio0 dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state I am really utterly clueless as to what of this is a serial port. But there are two of them on the back of the system. Help! Thanks! -- David Benfell, LCP [EMAIL PROTECTED] --- Resume available at http://www.parts-unknown.org/
need help with pf tcpdump
Hello all, I'm trying to debug my packet filtering rules. The problem is that messages sent from my internal network are not getting through to the SMTP host on my OpenBSD 3.8-CURRENT system. The only output I'm getting from tcpdump is: Feb 06 00:56:09.237698 0:3:93:eb:21:f2 0:a0:cc:65:ba:d0 0800 74: 192.168.18.47.65248 > 192.168.19.242.25: S 3208584508:3208584508(0) win 65535 (DF) Feb 06 00:56:09.237735 0:a0:cc:65:ba:d0 0:3:93:eb:21:f2 0800 58: 192.168.19.242.25 > 192.168.18.47.65248: S 3124286715:3124286715(0) ack 3208584509 win 0 (DF) [tos 0x10] Feb 06 00:56:09.238491 0:3:93:eb:21:f2 0:a0:cc:65:ba:d0 0800 60: 192.168.18.47.65248 > 192.168.19.242.25: . ack 1 win 65535 (DF) Feb 06 00:56:09.954495 0:3:93:eb:21:f2 0:a0:cc:65:ba:d0 0800 74: 192.168.18.47.65249 > 192.168.19.242.25: S 2319452229:2319452229(0) win 65535 (DF) Feb 06 00:56:09.954545 0:a0:cc:65:ba:d0 0:3:93:eb:21:f2 0800 58: 192.168.19.242.25 > 192.168.18.47.65249: S 2347749644:2347749644(0) ack 2319452230 win 0 (DF) [tos 0x10] Feb 06 00:56:09.955300 0:3:93:eb:21:f2 0:a0:cc:65:ba:d0 0800 60: 192.168.18.47.65249 > 192.168.19.242.25: . ack 1 win 65535 (DF) 192.168.19.242 is the OpenBSD system. 192.168.18.47 is my laptop. Beyond that, I have no clue what this means. And all I know is that the SMTP logs show on the OpenBSD system show no sign of contact. On the laptop: 2006-02-06 00:56:08.528514500 starting delivery 812: msg 36185520 to remote [EMAIL PROTECTED] 2006-02-06 00:56:08.528522500 status: local 0/10 remote 3/20 2006-02-06 00:56:08.528523500 starting delivery 813: msg 36182781 to remote [EMAIL PROTECTED] 2006-02-06 00:56:08.528527500 status: local 0/10 remote 4/20 2006-02-06 01:00:39.530878500 delivery 810: deferral: Connected_to_192.168.19.242_but_connection_died._(#4.4.2)/ 2006-02-06 01:00:39.530885500 status: local 0/10 remote 3/20 Both systems are running qmail. A copy of my /etc/pf.conf is attached. -- David Benfell, LCP [EMAIL PROTECTED] --- Resume available at http://www.parts-unknown.org/ # $OpenBSD: pf.conf,v 1.19 2003/03/24 01:47:28 ian Exp $ # # See pf.conf(5) and /usr/share/pf for syntax and examples. # Required order: options, normalization, queueing, translation, filtering. # Macros and tables may be defined and used anywhere. # Note that translation rules are first match while filter rules are last match. # Macros: define common values, so they can be referenced and changed easily. #ext_if="ext0" # replace with actual external interface name i.e., dc0 ext_if="xl0" #int_if="int0" # replace with actual internal interface name i.e., dc1 int_if="dc0" dmz_if="sf3" pub_if="sf0" lupin_if="sf1" #internal_net="10.1.1.1/8" internal_net="192.168.18.1/24" external_addr="66.93.170.242" routable_subnet="66.93.170.241/28" dmz_net="192.168.19.0/24" dmz_addr="192.168.19.242" mta_ad = "192.168.19.242" mta_pt = "25" dhcp_net="192.168.20.0/24" lupin_net="192.168.100.0/24" public_admin_net="192.168.17.0/24" starshine="216.240.40.161/27" allowed_nets="{ $starshine, $dmz_net, $internal_net }" trusted_external="{ 12.22.55.0/24 24.23.206.48/32 64.0.0.0/4 134.154.0.0/16 216.240.40.161/27 166.154.0.0/16 166.147.140.0/24 198.144.195.188/32 4.4.0.0/16 207.47.24.0/24 208.54.15.0/24 209.172.123.0/24 }" # DoubletreeKing's Head Local CSU Hayward starshine.org Verizon Wireless earth_ext="66.93.170.243" earth_dmz="192.168.19.243" earth_int="192.168.18.43" dnscache="192.168.19.4" kindling_ext="66.93.170.244" kindling_int="192.168.19.244" home_ext="66.93.170.245" home_int="192.168.18.44" raven_ext="66.93.170.246" raven_int="192.168.18.45" lair_ext="66.93.170.247" lair_int="192.168.18.46" thunder_ext="66.93.170.248" thunder_int="192.168.18.47" lupin_ext="66.93.170.254" non_routable="{ 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 }" macintoshes="{ $lair_ext, $lair_int, $thunder_ext, $thunder_int }" linux_pcs="{ $dnscache, $kindling_ext, $kindling_int, $home_ext, $home_int, $raven_ext, $raven_int }" auth_local="{ $lair_ext, $lair_int, $thunder_ext, $thunder_int \ $earth_ext, $earth_dmz, $dnscache, $kindling_ext, $kindling_int, $home_ext, $home_int, $raven_ext, $raven_int }" lupin_router="192.168.100.1" lupin_net="192.168.100.0/24" dmz_services="port { smtp, pop3, http, ftp-data, ftp, domain, ntp }" tcp_udp="proto { tcp, udp }" in_out="{ in, out }" # Tables: similar to macros, but more flexible for many addresses. #table { 10.0.0.0/8, !10.1.0.0/16, 192.168.0.0/24, 192.168.1.18 } # Optio
Re: pf by mac address?
On Mon, 23 Jan 2006 10:49:32 +0100, viq wrote: > > How about a different approach? Limit everyone by default, and then remove > limits via authpf. As someone somewhere said, ssh can be made into > "double-click here to be able to surf" ;) > *This* seems like it could work. I will look into it further. Thanks! -- David Benfell, LCP [EMAIL PROTECTED] --- Resume available at http://www.parts-unknown.org/
pf by mac address?
Hello all, Perhaps I'm looking for this the wrong way. My local network now (and hopefully temporarily) includes hostile users. I may need to exercise controls on their Internet usage by machine. Now, I can certainly tell dhcpd to give certain machines certain IP addresses by reference to their MAC address. But that won't stop these users from allocating their own IP address and essentially bypassing dhcpd. The environment includes a lot of wireless -- most users connect this way. So I'm thinking I'd like to be able to write packet filter rules based on MAC address. I'm not necessarily going to want to simply cut off all their Internet access, but pf offers a lot of options to do what I think I might want to do, if I can make rules by MAC address. Traffic shaping and additional rules about what ports they can access come to mind. Possibly other possibilities will come to your mind -- hopefully you see what I'm thinking. Is it possible? -- David Benfell, LCP [EMAIL PROTECTED] --- Resume available at http://www.parts-unknown.org/
Never mind... Re: pf by mac address?
On Sun, 22 Jan 2006 21:08:34 -0800, David Benfell wrote: > > Perhaps I'm looking for this the wrong way. My local network now (and > hopefully temporarily) includes hostile users. I may need to exercise > controls on their Internet usage by machine. > Still what I think I'd like to do -- because MAC address spoofing is a level beyond the capability of the users I'm worried about, but I see this has come up before... <http://archives.neohapsis.com/archives/openbsd/2002-06/0513.html> -- David Benfell, LCP [EMAIL PROTECTED] --- Resume available at http://www.parts-unknown.org/
Re: a stupid question, and OT to boot
On Tue, 27 Dec 2005 16:11:09 -0500, Matthew Jenove wrote: > David Benfell <[EMAIL PROTECTED]> wrote: > > Why is this off topic? > > Because it is administrivia more suitable for a unix newbies list? > > man afterboot, then searching for "network" will point you to > ifconfig, which would be the right way to figure out the IP > address(es) -- where as the "where did that ping come from" approach > breaks behind NATing (as you already mentioned). > > And an easier solution than the one asked about would be to point a > web browser at http://whatismyip.com/ > I see this as a solution to a different problem than the one posed. But a worthwhile question to the newbie would have been the classic: "What is the problem you're really trying to solve?" -- David Benfell, LCP [EMAIL PROTECTED] --- Resume available at http://www.parts-unknown.org/
Re: a stupid question, and OT to boot
On Mon, 26 Dec 2005 22:34:28 -0600, Julesg wrote: > Because I want to discover the IP address at box REMOTE. > Probably the easiest way is to run tcpdump. You'll want options to limit the output to ICMP traffic. "man tcpdump" for details. If, however, REMOTE's IP address is in a network address translation scheme, and LOCAL is outside that network address translation scheme, you will only be able to discover the IP address that REMOTE's router assigns to it. > Sorry, I will try to keep OT stuff to a bare minimum, and if I get complaints > I will stop. > Why is this off topic? -- David Benfell, LCP [EMAIL PROTECTED] --- Resume available at http://www.parts-unknown.org/
Re: iptables vs pf
On Thu, 20 Oct 2005 09:59:10 +0200, Jan Johansson wrote: > > And knowing thoose Linux dudes, maybe his Linux squid is a > loadable kernel module so it will be uber fast, I mean crashing > the machine instead of just squid is not really a problem now is > it? > Yes, we know the Linux kernel is bloated. But this is hyperbole. -- David Benfell, LCP [EMAIL PROTECTED] --- Resume available at http://www.parts-unknown.org/