Re: image view and manipulation
On Mon, Jul 4, 2016 at 4:44 PM, Ryan Freeman wrote: > You might be interested in the ImageMagick (or GraphicsMagick) packages. > The latter is a fork of the former, but they both supply the same > commands. display, convert, mogrify are some of the commands available, > and can be useful to do things on the fly in a scripted fasion if you'd > like. ImageMagick's monolithic design is inflexible. It either does what you want or you're out of luck. netpbm is a better option for pretty much everything that you could do with ImageMagick. And if it doesn't do what you want, you can write your own filter and insert it into the pipeline at an appropriate place. Tet -- I saw cout being shifted "Hello world" times to the left and stopped right there. — Steve Gonedes
Re: Why regexp works different in stock vi vs. vim
On Fri, Feb 5, 2016 at 6:13 PM, Артур Истомин wrote: > When I search tabs in stock vi with '/\t'. It finds all words 'tried'. In > vim it finds tabs. Why? Because \t is a literal t in a standard regular expression. vim uses a different regular expression library that interprets it as a tab. If you want to search for a tab, you can just use a literal tab in the search string. In the past, I've needed to prefix it with ^v, but that doesn't seem to be necessary on any of the systems I have in front of me right now. Tet -- I saw cout being shifted "Hello world" times to the left and stopped right there. — Steve Gonedes
Re: {r,s}mkx entries in terminfo db missing
On Fri, Mar 21, 2014 at 11:41 AM, Nils R wrote:
>The original st.info contains entries for {r,s}mkx, but when i query the
>system terminfo database
>with 'infocmp -1 st', no entries for {r,s}mkx are found:
>
> % egrep '[rs]mkx' st.info
> rmkx=\E[?1l\E>,
> smkx=\E[?1h\E=,
> % infocmp -1 st-256color | egrep '[rs]mkx' | wc -l
>0
>
> How can this be? Is this a bug or am i missing something? Any help much
> appreciated.
It would appear your compiled terminfo database wasn't built from the
same st.info source file that you're looking at. OpenBSD is a bit
different to other Unixes here, but I think you should be able to
convert it to a termcap file using infotocap(1), insert it into
/usr/share/misc/termcap and then use cap_mkdb(1) to recompile the
terminfo database.
Tet
--
"Java is a DSL for taking large XML files and converting them to stack
traces" -- Bulat Shakirzyanov
Re: Bizarre pf/sendmail interaction
On Wed, Dec 18, 2013 at 7:54 AM, Jan Stary wrote: > So $riva is a member of $lokisafe, right? Bingo! I knew it would be something trivial that I'd overlooked. All working now. Thanks, Tet -- "Java is a DSL for taking large XML files and converting them to stack traces" -- Bulat Shakirzyanov
Re: Bizarre pf/sendmail interaction
On Tue, Dec 17, 2013 at 7:51 PM, Jan Stary wrote: >> block in log >> block out log on $ext > > How could anyone help you knowing just these two lines? > Show your pf.conf I was trying to show that I only had two block lines and that they both should log when blocking packets. My rules are actually very simple: match out on $ext from $int_ip to any nat-to $loki_ext block in log block out log on $ext pass in quick on $int flags any pass out on $ext from $lokisafe pass in on $ext inet proto tcp to port 4334 rdr-to 127.0.0.1 port ssh pass in on $ext inet proto tcp from $mx to $loki_ext port smtp rdr-to $riva port smtp flags any pass out on $int inet proto tcp from $mx port smtp flags any $int and $ext are interfaces on the firewall (loki). $loki_ext is the external IP, $int_ip is the internal /24. $lokisafe is a selection of /24s that I've sometimes used, including the internal network. $riva is my home mail server. $mx is the IP addresses of my hosted MX servers. With tcpdump, I can see the response to the EHLO greeting leaving riva, arriving on $int, but never making it to $ext. Using HELO instead doesn't prompt the same behaviour. Tet -- "Java is a DSL for taking large XML files and converting them to stack traces" -- Bulat Shakirzyanov
Re: Bizarre pf/sendmail interaction
On Tue, Dec 17, 2013 at 5:30 PM, Aaron wrote: > Did you enable forwarding? > > net.inet.ip.forwarding Yes. Packets are being forwarded without problems, and it's working as a firewall exactly as you'd expect for outbound traffic. I can browse the web etc. But something strange is going on. Not only do I get problems with EHLO vs HELO, but also I can't ssh from the firewall into my internal mail server and if I ping it, it only works once: # ping riva PING riva.astradyne.corp (192.168.8.10): 56 data bytes 64 bytes from 192.168.8.10: icmp_seq=0 ttl=64 time=0.180 ms ping: sendto: No route to host ping: wrote riva.astradyne.corp 64 chars, ret=-1 ping: sendto: No route to host ping: wrote riva.astradyne.corp 64 chars, ret=-1 ping: sendto: No route to host ping: wrote riva.astradyne.corp 64 chars, ret=-1 It's as if something is allowing through a handful of packets and then blocking subsequent ones. I wouldn't mind so much if I had a log telling me what was being blocked and why. At least then I'd have a clue what was going on and could adjust my pf.conf to fix it. But no, the packets just seem to disappear into the ether. Tet -- "Java is a DSL for taking large XML files and converting them to stack traces" -- Bulat Shakirzyanov
Bizarre pf/sendmail interaction
My firewall died recently, so I replaced it with a new machine. Since I needed to reinstall the OS, I naturally went for 5.4, rather than whatever obsolete version I'd been using on the old machine. But now I can't get incoming email. My setup is something like: public mx ---> firewall ---> internal mail server My mx server is hosted in a datacentre. It receives mail and forwards it on to my home mail server. However, it's not working. From my mx server, I can connect to port 25 on my internal mail server. If I issue a HELO greeting, everything is fine. If I issue EHLO instead, the reply never makes it back to the MX server (the reply is being sent, as I've verified with tcpdump). So clearly something's dropping it. But nothing's being logged to indicate that. I have two block rules, both of which should be logging: block in log block out log on $ext I can issue EHLO without problems from other machines on my internal network, and from the firewall itself. But anything originating outside of the firewall fails. Any ideas? I'm somewhat stumped. My previous machine was sufficiently obsolete that the pf syntax has changed since then, so I wasn't able to just reuse my old pf rules. Tet -- "Java is a DSL for taking large XML files and converting them to stack traces" -- Bulat Shakirzyanov
Re: Can't reach www.openbsd.org
2010/11/2 Ari Constancio : > Let me rephrase: I want to get man pages, and the link is > http://www.openbsd.org/cgi-bin/man.cgi . man(1) is your friend... Tet -- b It seems intuitively obvious to me, which means that it might be wrong.b -- Chris Torek
Re: Linux or OpenBSD
On Sun, Sep 26, 2010 at 11:10 PM, Brad Tilley wrote: > I don't mean this as bashing Linux, just pointing out facts. I think > history shows that OpenBSD has a better track record here (if that means > anything to anyone). Does it though? The only empirical evidence I've seen is with OpenBSD running in its default configuration, which I'm not aware of anyone actually using in the real world. I'd be interested to see how an OpenBSD web server or firewall fared against the Linux distributions and commercial unices. Tet -- b It seems intuitively obvious to me, which means that it might be wrong.b -- Chris Torek
Re: OpenBSD culture?
On Wed, Apr 14, 2010 at 7:19 PM, Matthias Kilian wrote: > What detail in the original reply Theo sent to the OP (and quoted > it later on this list) was rude? The lack of an answer. He could have said "Yes. Check your nearest search engine for details". Which would have conveyed more information in fewer characters. But instead he chose to just get annoyed at the question. Like it or not, OpenBSD developers have a horrible culture of being rude to those genuinely asking for information. Simply pointing the poster in the direction of the documentation without being so abrupt would achieve much more. But hey, what would I know? I've been using BSD since the '80s, and yet I've been told that I'm the sort of person OpenBSD doesn't need, and to go away. That should probably tell you something... FWIW, I still use OpenBSD, but now only on a firewall, and I've given up on interacting with the community. I have a Linux desktop, although I don't run the bloated horrors that are GNOME and KDE -- I haven't sunk that far yet :-) Tet -- b It seems intuitively obvious to me, which means that it might be wrong.b -- Chris Torek
Re: Defending OpenBSD Performance
On Wed, Sep 16, 2009 at 5:37 PM, Henning Brauer wrote: >> Sounds like building from source is necessary to me. > > boo hoo. run one machine somewhere and make release. done. And that attitude is why OpenBSD will never be more than a hobby OS. Sigh. Tet -- b It seems intuitively obvious to me, which means that it might be wrong.b -- Chris Torek
Re: Defending OpenBSD Performance
On Wed, Sep 16, 2009 at 3:39 PM, Henning Brauer wrote: >> Building from source is light years more difficult than >> 'apt-get update && apt-get upgrade, or 'yum upgrade' or >> the like. > > so don't fucking do it, use releases and packages. So how does one remedy CVE-2009-0696 like that? From the web site: 007: RELIABILITY FIX: July 29, 2009 All architectures A vulnerability has been found in BIND's named server (CVE-2009-0696). An attacker could crash a server with a specially crafted dynamic update message to a zone for which the server is master. A source code patch exists which remedies this problem. Sounds like building from source is necessary to me. As does: http://www.openbsd.org/faq/faq10.html#Patches If there genuinely is something as easy as "yum update bind", then great. But if so, it doesn't seem to be documented, and this is the reason I haven't rolled out more OpenBSD boxen in the real world. I run OpenBSD on my own machines. But I'm with Cian here. Keeping up to date really is its Achilles heel compared to other OSes, and is holding it back for corporate use. Tet -- b It seems intuitively obvious to me, which means that it might be wrong.b -- Chris Torek
Re: OpenSSH exploit... or not?
On Mon, Jul 20, 2009 at 6:53 PM, Kevin Wilcox wrote: > I'll believe there is something to release when something gets > released or the OpenSSH devs say "oh, wait, there's a problem..." > > Until then I'm treating anything from that poster (anti-sec) as FUD and SPAM. http://www.theregister.co.uk/2009/07/20/anti_sec_spoof/ Tet -- The greatest shortcoming of the human race is our inability to understand the exponential function -- Albert Bartlett
Re: Where is "Secure by default" ?
On Mon, Mar 9, 2009 at 2:56 PM, Marco Peereboom wrote: > because it is. And therein lies some of the problem with the OpenBSD community. Don't get me wrong, I like OpenBSD, I use it, and have donated to the project. But here we have a user that has security concerns, and rather than either admit there's a problem or point out why there's no security hole, the answer given is just that it's secure "because it is". That wouldn't fill me with confidence if I was looking to deploy an OpenBSD system. I'm worried that some are getting complacent about OpenBSD's security here... Maybe it's a troll. Maybe not. Can we afford to be turning away potential users on the off chance? Tet -- The greatest shortcoming of the human race is our inability to understand the exponential function -- Albert Bartlett
Re: rfc1918
On Thu, Jan 22, 2009 at 1:37 PM, Steve Laurie wrote: > I was wondering if someone could tell me why there's a need to write > a rule to block addresses that come under the private address space if > these addresses aren't routable over the Internet? An RFC that says they shouldn't be routeable over the Internet doesn't mean that they aren't. I've seen plenty of cases where a misconfigured router has sent RFC1918 packets out onto the net. Blocking them at your border is cheap, so it makes sense to do so. Tet -- Perl is like vise grips. You can do anything with it but it is the wrong tool for every job. -- Bruce Eckel
Re: Failure to NAT
On Tue, Dec 2, 2008 at 9:47 PM, Stijn <[EMAIL PROTECTED]> wrote: > Can you post the output of "pfctl -s all". I could do, but the problem was the lack of pf=YES in rc.conf It all works fine now. Tet -- Perl is like vise grips. You can do anything with it but it is the wrong tool for every job. -- Bruce Eckel
Failure to NAT
Hi... The hard drive on my firewall machine died overnight, so I rebuilt it with a new hard drive this morning. I grabbed the most recent OpenBSD CD I had to hand (which was 3.8 -- yes, I know, and the order for 4.4 followed as soon as I got to work and had net access again). The problem is that while I have net access from the firewall itself, I don't from any of the machines on my internal network. After playing with tcpdump, it seems that packets are coming in fine on the internal interface, and are leaving on the external interface, but are not being NATed on the way through. Nothing is being logged on pflog0. My internal interface is 192.168.8.1, and the external interface is 10.0.8.224/28. My minimal pf.conf[1] looks like: int = "fxp0" ext = "rl0" nat on rl0 from 192.168.8.4 to any -> 10.0.8.230 block in log pass in log quick on $int pass out log on $ext keep state 192.168.8.4 is the test machine I'm using on the internal network. Yet packets from that machine are leaving rl0 with a source IP of 192.168.8.4, not 10.0.8.230 as the NAT rule implies they should be. Obviously I'll reinstall with 4.4 when it arrives, but in the mean time, I'm stuck without net access for most of the machines in the house, and urgently need to sort this out. Any ideas on where I might be going wrong, and what I can do to fix it? Thanks, Tet [1] Obviously the real one will be somewhat more complex, but I need to get something working first, and then I'll build a pf.conf that does what I need. -- Perl is like vise grips. You can do anything with it but it is the wrong tool for every job. -- Bruce Eckel
