Non-copyleft IRC servers

2018-09-22 Thread Eric Pruitt
Does anyone have recommendations for a maintained IRC server that
doesn't have a copyleft license? There are only a few listed on
https://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_daemons,
and they don't seem to be maintained. Any runtime is fine, but I'm
partial to C, and DCC support would be nice but isn't a hard
requirement.

Thanks,
Eric



Re: Non-copyleft IRC servers

2018-09-22 Thread Eric Pruitt
On Sat, Sep 22, 2018 at 10:15:04PM +0200, Solene Rapenne wrote:
> Eric Pruitt  wrote:
> > Does anyone have recommendations for a maintained IRC server that
> > doesn't have a copyleft license? There are only a few listed on
> > https://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_daemons,
> > and they don't seem to be maintained. Any runtime is fine, but I'm
> > partial to C, and DCC support would be nice but isn't a hard
> > requirement.
> >
> > Thanks,
> > Eric
>
> net/ngircd is fine

The GPL is a copyleft license.



Re: Non-copyleft IRC servers

2018-09-22 Thread Eric Pruitt
On Sat, Sep 22, 2018 at 01:00:57PM -0700, Eric Pruitt wrote:
> Does anyone have recommendations for a maintained IRC server that
> doesn't have a copyleft license? There are only a few listed on
> https://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_daemons,
> and they don't seem to be maintained. Any runtime is fine, but I'm
> partial to C, and DCC support would be nice but isn't a hard
> requirement.

I found Oragono, an MIT-licensed server written in Go
(https://github.com/oragono/oragono). Go limits its portability, and I
know there have been issues with Go on BSDs in the past, but my IRC
server is hosted on a Linux box making this a non-issue for me right
now.



Re: man.openbsd.org timing out via HTTP & HTTPS

2023-12-29 Thread Eric Pruitt
On Fri, Dec 29, 2023 at 02:46:39PM -0600, Tim Chase wrote:
> Not much to add to the subject.  For a couple days now, I've tried
> connecting via HTTP & HTTPS from various points around the internet
> and they all time out.  Sounds like something hung or accidentally
> lost power and needs a nudge.

Known issue:

- https://marc.info/?l=openbsd-misc&m=170301839017559&w=2
- https://marc.info/?l=openbsd-misc&m=170345453930038&w=2

Eric



Re: lcamtuf on the recent xz debacle

2024-04-04 Thread Eric Pruitt
On Thu, Apr 04, 2024 at 09:17:18PM +, Katherine Mcmillan wrote:
> I have seen the following comment, or similar, in several articles now:
> "On Friday, a lone Microsoft developer rocked the world when he revealed a 
> backdoor
>  had been intentionally planted in xz Utils, an open source data compression 
> utility available on almost all installations of Linux and other Unix-like 
> operating systems." 
> https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/
> 
> There are a couple of problems with this statement, but I just want to focus 
> in on the "almost all installations of Linux and other Unix-like operating 
> systems" part.  From my understanding, it is certainly almost all 
> installations of Linux​, but the "and other Unix-like operating systems" 
> doesn't seem founded.  From what I understand, this backdoor would not affect 
> any flavour of *BSD, or of illumos for that matter (ex. smartOS), or QNX, or 
> Solaris.  Just for clarity, does anyone know what "Unix-like operating 
> systems" would be affected by this?

I think this might be an issue of how you're parsing the statement. It
sounds like you're reading this as the exploit being available on those
systems. However, when I read the line, I interpret as "xz Utils ...
[is] available on almost all installations of Linux and other Unix-like
operating systems," which is true. That does not necessarily suggest
that they're all affected by the vulnerability.

Eric



Re: fmt replaces utf8 spaces for ascii ones

2017-02-12 Thread Eric Pruitt
On Sun, Feb 12, 2017 at 09:21:37PM +0100, Walter Alejandro Iglesias wrote:
> After investigating a bit I realized that what I called utf8 space is a
> 'nobreakspace' so it's ok fmt to replace them for ascii ones.  I made a
> stupid question.  Sorry!

If that's the behavior you see, I think _that_ is a bug: the reason
non-breaking spaces exist is so programs do not separate words at that
character (https://en.wikipedia.org/wiki/Non-breaking_space). GNU fmt
respects non-breaking spaces and handles them accordingly:

~$ fmt --version | head -n1
fmt (GNU coreutils) 8.25
~$ printf " XXX\u00a0XXX XXX" | fmt -w 20

XXX XXX
XXX
~$ printf " XXX XXX XXX" | fmt -w 20

XXX
XXX XXX

Unfortunately I do not have access to an OpenBSD machine to verify
whether or not its fmt does the correct thing.

Eric



Re: smtpd warn: not enough disk space

2024-07-05 Thread Eric Pruitt
On Sat, Jul 06, 2024 at 01:49:05AM +0200, Christian Schulte wrote:
> A database admin would have monitored the system and just enhanced
> storage when required. Bad thing for me was, that I could not vaccuum
> the database, because postgresql copies tables to new files to reclaim
> disk space afterwards. So the database was unusable for about 12
> hours, until I could manage to xz a backup and transfer it to another
> machine. Making postgresql aware of keeping some free disk space, it
> would need to preserve around 50%, so that vaccuum can always be
> performed.

This is tangential to the original issue, but I've heard of some
administrators leaving around large files so they can be removed when
the disk unexpectedly fills up buying them more time to address the
underlying issue, and CockroachDB implements this natively:
.

Eric



Re: security(8) for linux?

2024-07-20 Thread Eric Pruitt
On Sat, Jul 20, 2024 at 03:11:08PM -0400, Allan Streib wrote:
> I am guessing that many of us also manage linux systems, is anyone
> aware of a port or adaptation of security(8) for linux, specifically
> Ubuntu or Debian distributions?

The closest thing I'm familiar with is tripwire
(https://packages.debian.org/buster/tripwire), but it doesn't do most of
what security(8) does.

Eric