Re: Fail2ban alternative for OpenBSD
On 2017-10-29 04:35, Rupert Gallagher wrote: Note that PF cannot discriminate between legitimate and abusive multiple connections from same cidr. If you whitelist the cidr of a mobile network, to avoid banning yourself on port 993, you also whitelist bruteforce attacks from the same cidr. Sent from ProtonMail Mobile On Sun, Oct 29, 2017 at 5:26 AM, Tom Rosso wrote: On 2017-10-28 21:20, x9p wrote: > Hi, > > Coming from the Linux world, I wonder if there is a better alternative > to fail2ban, already being used in OpenBSD servers by the majority. > > cheers. > > x9p The pf firewall provides the capability to block brute force attacks. See max-src-conn-rate. https://www.openbsd.org/faq/pf/filter.html#stateopts was suggested http://openports.se/sysutils/sec , which seems the most proper. thanks all for the inputs.. cheers. x9p
desync: scheduling fib reload
Hi I'me running a couple of openbsd routers running (still OpenBSD 6.0) with carp failover and ospfd+ospf6d. Everything seems running fine but i see clockwork every 5 min the following message: ospfd[PROCESSID]: desync; scheduling fib reload ospfd[PROCESSID]: reload interface list and routing table It appaers from source/docs that RTM_DESYNC could com from buffer shortage. We have changed default sysctl settings for: kern.maxcluster=24576 net.inet.ip.ifq.maxlen=4096 net.inet6.ip6.ifq.maxlen=1024 as from netstat -m we ran out of 2048 mbufs at defaults. We run 4 10gb ix interfaces for traffic one uplink and 2 bound as trunk (failover) and carp on the vlans on top of the trunk. ospf is simply announcing connected carp and flagged routes. Where can I get more information how to tune ospfd so desync won't occure. For now upgrading to 6.2 is not a option. We had issues with 6.1 and our ix interfaces not being enabled. See mail in this list from may 2017. Any input would be helpfull Regards Robert
late ro remount to permit reorder_kernel on 6.2
Hi, on 6.2, kernel relinking is done last in rc: # Re-link the kernel, placing the objects in a random order. # Replace current with relinked kernel and inform root about it. /usr/libexec/reorder_kernel & I have some boxes which have /var /tmp and /dev mounted as mfs, while others are mounted from local SDcard and kept read-only. Historically I used @reboot cron for remounting local filesystems (mount -urA -t nomfs), but this prevents relinking libraries, and - as of 6.2 - relinking kernel, because cron is started earlier in rc. I am currently remounting local file systems late by modifying rc (terrible I know): /usr/libexec/reorder_kernel && mount -urA -t nomfs >/dev/null 2>&1 I know read-only setups are unsupported, modifying base files as well, but if someone has an advice on what would be a better way of remounting local file systems read-only after kernel relinking is done, I'd be grateful. Thank you in advance, -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
Re: mandoc output paper size
Hiya On 10/27/17 14:31, Ingo Schwarze wrote: [ sending this particular one back to the list because it contains something useful for everyone and nothing private ] Replying to list to archive comments even if not acted on. Hi Jan, Jan Stary wrote on Fri, Oct 27, 2017 at 12:46:00PM +0200: I produced a PS output with "man -Tps rm > rm.ps", with output paper set to a3, a4, and a5 in man.conf. This results, respectively, in %%DocumentMedia: Default 841 1190 0 () () %%DocumentMedia: Default 595 841 0 () () %%DocumentMedia: Default 419 595 0 () () which apparently are the right dimensions. However, the Minolta will print all of them on A4 paper, although it does have a stash of A3 and A5 too. That's where I thought it might take a hint from the DSC comment, if I changed the "Default" to "A3" or "A4" or "A5", or if mandoc(1) itself put that in the DSC comments. I rewrote it manually before each printing, but the Minolta still prints them all on an A4: That's interesting, but anecdotal. It is neither surprising that a specific printer selects paper as configured (in whichever way), as opposed to inspecting fikes it is sent; nor would it be surprising if other printers, or even the same one, or printer drivers on the print server, could be configured to inspect the contents of PostScript files to select paper. The trouble is, i just don't know what firmwares and softwares do, what they should do according to standards, and where to look for standards in this respect. Does anybody else know? The DSC comments are not part of the PS specification (the reference manual quoted earlier) and a PS interpreter would not normally take notice of the them. The comments are aimed at document printing systems which can just look for the comments and manage the printing of the file amongst other files and a range of available printers - such as queuing for a printer which supports/has the media listed by the DSC comment. Some PS interpreters may look for and act on the comments, but this would not be "standard" behaviour. For the %%DocumentMedia: comment the name used is for human consumption, it is the numeric values that are used for any media handling decisions. The %%DocumentMedia: comment lists all media sizes used by the document but does not say which page uses which size of media so could not be used to select media for any particular page. If the media size is important for a page then there should be a PS setpagedevice call like the following: <>setpagedevice The PS interpreter will perform media selection based on the values - use matching media, next largest, scale/rotate content, ask operator, etc. - see section 6.2.1 of the PS reference manual for way more detail. This is what is needed for the Minolta printer to use the other media sizes it has available. A quick edit of the PS file to add the above line with the appropriate media sizes for A3 or A5 should prove that. Basically don't rely on DSC comments to do media selection. I don't know gv but it will be working as a virtual printer with some standard media sizes to use when rendering a file. It sounds like it adds the list of media from any %%DocumentMedia: comments to provide additional media sizes it may not have by default. Ah, in the State menu there is the option "Respect document structure". If I unselect this the page size used by gv changes from the letter used in the -Tps output to the default A4 used by gv. It may be useful to use a media name such as man-A4, man-letter, etc. (to indicate the source of the file and media size used) for any systems that do process the DCS comments. That will avoid duplicates appearing in generated media lists. As for PDF, no there is no way to name the media size being used. There is no equivalent of the DSC comments for PDF. Media selection is always done based the dimensions in the /MediaBox array, the same way as the /PageSize array in PS, and it is up to the processor to decide how to handle the media size request. Finally, the -Tpdf output is not a valid PDF. It is missing the endobj keyword from several of the object definitions. This will cause warnings or errors when processing. I haven't updated to 6.2 yet so that may have been fixed by now, apologies if it has. Hm, so I can remove man.conf altogether, because even the default "letter" manpages will get printed on A4, which is what I want. That's a bad idea. The purpose of the -Opaper= option is not to select paper, but to adjust the width and height that the document content will require, and the primary purpose of the DocumentMedia DSC instruction isn't selecting paper either. but to inform how the content was arranged. If you use -Opaper=letter, margins will be reasonable for letter size paper, but ugly for A4: Since letter paper is wider than A4 but not as tall, printing on A4 without -Opaper=a4 will usually result in an awkwardly narrow ri
switching to DUIDs (and back)
I thought this was documented somewhere but I'm not finding it in Googling. I don't really like DUIDs, but I want to stick in a second drive controller temporarily to recover data off some old hard drives. Which means /dev/wd0a etc is going to change since the added controller (in a PCI slot) becomes primary. I'm perfectly comfortable manually mounting and unmounting the old drives, I don't want to add them to an fstab. I want to replace my fstab with one that accesses my current partitions using DUIDs. Disklabel shows me a DUID for the drive, how do I set up individual partitions? Or is there already a DUID (or UUID) for each partition that I need to find and use? The main thing right now is to change fstab so it boots back up smoothly with DUIDs. I'll comment out my current entries and put the DUID ones below. And yes, I already made a backup copy. All IDE, can't afford SCSI.
Re: switching to DUIDs (and back)
On Sun, Oct 29, 2017 at 11:25:22AM -0400, Alan Corey wrote: > I thought this was documented somewhere but I'm not finding it in Googling. > > I don't really like DUIDs, but I want to stick in a second drive > controller temporarily to recover data off some old hard drives. > Which means /dev/wd0a etc is going to change since the added > controller (in a PCI slot) becomes primary. I'm perfectly comfortable > manually mounting and unmounting the old drives, I don't want to add > them to an fstab. > > I want to replace my fstab with one that accesses my current > partitions using DUIDs. Disklabel shows me a DUID for the drive, how > do I set up individual partitions? Or is there already a DUID (or > UUID) for each partition that I need to find and use? > > The main thing right now is to change fstab so it boots back up > smoothly with DUIDs. I'll comment out my current entries and put the > DUID ones below. And yes, I already made a backup copy. All IDE, > can't afford SCSI. The fstab(5) man page is your friend. There's even an EXAMPLES section in there for you to review that shows how DUIDs are addressed. Basically, replace "wd0" with the drive's DUID.
Re: 5-button wheeled mouse and X
On 10/25/17 07:20, Cág wrote: Natasha Kerensikova wrote: it started as a bug report: it have a 5-button mouse with a wheel, even though I don't use much the buttons 4 and 5 (I think only for previous and next in firefox history). I recently switched to OpenBSD, and I was surprised to find these buttons cause scrolling, like the wheel. If this behavior is intended, the rest of this e-mail is moot. This isn't a bug apparently. Are the extra buttons recognised by xev? If they are, remap them with xmodmap(1). If they aren't, well, then it should be done by xf86-input-evdev or libinput. There's been some work in FreeBSD, and the drivers are in ports, but OpenBSD doesn't have them. I use a 4-button Logitech trackball mouse. It required remapping in xmodmap to make it work. Yes, xev showed enough information to see "button up" and "button down" events to use as input to xmodmap. geoff steckel
Re: switching to DUIDs (and back)
On Sun, Oct 29, 2017 at 11:30:51AM -0400, Josh Grosse wrote: > Basically, replace "wd0" with the drive's DUID. I'm wrong, of course. Replace "/dev/wd0" with the drive's DUID, then append "." followed by the partition.
Re: mandoc output paper size
In article Mike Williams wrote: > Hiya > > On 10/27/17 14:31, Ingo Schwarze wrote: > > [ sending this particular one back to the list > > because it contains something useful for everyone and nothing private ] > > Replying to list to archive comments even if not acted on. > > > Hi Jan, > > > > Jan Stary wrote on Fri, Oct 27, 2017 at 12:46:00PM +0200: > > > >> I produced a PS output with "man -Tps rm > rm.ps", > >> with output paper set to a3, a4, and a5 in man.conf. > >> This results, respectively, in > >> > >> %%DocumentMedia: Default 841 1190 0 () () > >> %%DocumentMedia: Default 595 841 0 () () > >> %%DocumentMedia: Default 419 595 0 () () > >> > >> which apparently are the right dimensions. However, > >> the Minolta will print all of them on A4 paper, > >> although it does have a stash of A3 and A5 too. > >> > >> That's where I thought it might take a hint from the DSC comment, > >> if I changed the "Default" to "A3" or "A4" or "A5", or if mandoc(1) > >> itself put that in the DSC comments. I rewrote it manually before > >> each printing, but the Minolta still prints them all on an A4: > > > > That's interesting, but anecdotal. It is neither surprising that > > a specific printer selects paper as configured (in whichever way), > > as opposed to inspecting fikes it is sent; nor would it be surprising > > if other printers, or even the same one, or printer drivers on the > > print server, could be configured to inspect the contents of > > PostScript files to select paper. > > > > The trouble is, i just don't know what firmwares and softwares do, > > what they should do according to standards, and where to look for > > standards in this respect. > > > > Does anybody else know? > > The DSC comments are not part of the PS specification (the reference > manual quoted earlier) and a PS interpreter would not normally take > notice of the them. The comments are aimed at document printing systems > which can just look for the comments and manage the printing of the file > amongst other files and a range of available printers - such as queuing > for a printer which supports/has the media listed by the DSC comment. > > Some PS interpreters may look for and act on the comments, but this > would not be "standard" behaviour. For the %%DocumentMedia: comment the > name used is for human consumption, it is the numeric values that are > used for any media handling decisions. The %%DocumentMedia: comment > lists all media sizes used by the document but does not say which page > uses which size of media so could not be used to select media for any > particular page. If the media size is important for a page then there > should be a PS setpagedevice call like the following: > > <>setpagedevice In my other message I was about to mention that in the document generated by groff I inspected, besides the comment, I found this other line: %%BeginFeature: *PageSize Default << /PageSize [ 595 842 ] /ImagingBBox null >> setpagedevice It's in the place I put an image. I tried modifying the values here too to see if this line was taken in care by gv too, but it seems it's not. > > The PS interpreter will perform media selection based on the values - > use matching media, next largest, scale/rotate content, ask operator, > etc. - see section 6.2.1 of the PS reference manual for way more detail. > > This is what is needed for the Minolta printer to use the other media > sizes it has available. A quick edit of the PS file to add the above > line with the appropriate media sizes for A3 or A5 should prove that. > > Basically don't rely on DSC comments to do media selection. > > I don't know gv but it will be working as a virtual printer with some > standard media sizes to use when rendering a file. It sounds like it > adds the list of media from any %%DocumentMedia: comments to provide > additional media sizes it may not have by default. Ah, in the State > menu there is the option "Respect document structure". If I unselect > this the page size used by gv changes from the letter used in the -Tps > output to the default A4 used by gv. > > It may be useful to use a media name such as man-A4, man-letter, etc. > (to indicate the source of the file and media size used) for any systems > that do process the DCS comments. That will avoid duplicates appearing > in generated media lists. > > As for PDF, no there is no way to name the media size being used. There > is no equivalent of the DSC comments for PDF. Media selection is always > done based the dimensions in the /MediaBox array, the same way as the > /PageSize array in PS, and it is up to the processor to decide how to > handle the media size request. > > Finally, the -Tpdf output is not a valid PDF. It is missing the endobj > keyword from several of the object definitions. This will cause > warnings or errors when processing. I haven't updated to 6.2 yet so > that may have been fixed by now, apologie
Re: desync: scheduling fib reload
> I'me running a couple of openbsd routers running (still OpenBSD 6.0) > with carp failover and ospfd+ospf6d. Everything seems running fine but i > see clockwork every 5 min the following message: > > ospfd[PROCESSID]: desync; scheduling fib reload > ospfd[PROCESSID]: reload interface list and routing table > > It appaers from source/docs that RTM_DESYNC could com from buffer > shortage. Yes, on the route socket. It is unreasonable for the kernel to maintain an infinite number of route change messages, so about 9 years ago we developed this scheme of marking the situation for userland to handle. Such a mechanism didn't exist before, because noone had run into the concern before -- people weren't turning *BSD systems into full-table/high-churn routing systems before our daemons came along. > We have changed default sysctl settings for: > kern.maxcluster=24576 > net.inet.ip.ifq.maxlen=4096 > net.inet6.ip6.ifq.maxlen=1024 > > as from netstat -m we ran out of 2048 mbufs at defaults. Come on, think for a second. See "ip" and "ip6"? That doesn't grow the queue on the routing socket. If anything it probably makes your situation worse. As for growing the size of the route socket buffer -- it is unclear whether that won't make the situation worse. When a desync is detected in userland, you will already have read and consumed the full queue -- which now has a gap in it, and requires a fresh restart. So you are promising to do MORE wasteful work before recovering. Anyways, there are two circumstances where it happens: route buffer limits, or temporary mbuf shortage. I think you've hit the latter.
Re: late ro remount to permit reorder_kernel on 6.2
On Sun, Oct 29, 2017 at 12:32:58PM +0100, Marko Cupać wrote: > I know read-only setups are unsupported, modifying base files as > well, but if someone has an advice on what would be a better way of > remounting local file systems read-only after kernel relinking is done, > I'd be grateful. You can use rc.local(8).
Re: late ro remount to permit reorder_kernel on 6.2
On Sun, Oct 29, 2017 at 06:54:29PM +0100, Klemens Nanni wrote: > On Sun, Oct 29, 2017 at 12:32:58PM +0100, Marko Cupa?? wrote: > > I know read-only setups are unsupported, modifying base files as > > well, but if someone has an advice on what would be a better way of > > remounting local file systems read-only after kernel relinking is done, > > I'd be grateful. > You can use rc.local(8). Not really and btw. the OP uses it already. The kernel relinking happens at the end of rc in the background. rc.local is run before. -- -=[rpe]=-
Re: late ro remount to permit reorder_kernel on 6.2
> > On Sun, Oct 29, 2017 at 12:32:58PM +0100, Marko Cupa?? wrote: > > > I know read-only setups are unsupported, modifying base files as > > > well, but if someone has an advice on what would be a better way of > > > remounting local file systems read-only after kernel relinking is done, > > > I'd be grateful. > > You can use rc.local(8). > > Not really and btw. the OP uses it already. > The kernel relinking happens at the end of rc in the background. > rc.local is run before. OP has all the pieces. Once you start on your own road, noone else can really help.
Re: CUPS and AVAHI (bloatware)
On 10/26/17 07:24, Rupert Gallagher wrote: It is well known that cups does not need avahi. Avahi is an option, it requires dbus, which requires X11. If you have a server with limited resources and without X11, you cannot install the present cups package. Please remove cups's dependency on avahi. Check the FAQs for how to build ports. It's possible to build a version of cups without avahi. You would need to do it on a moderately capable system: any recent laptop or desktop system would suffice. It must have the same type of CPU as your target system. I'm not sure I have all the details correct, but this is what should work. After setting up your system to build ports from the instructions in the FAQ: go to /usr/ports/print/cups and edit Makefile to remove all mentions of avahi and mdns make print-build-depends > list_of_dependencies go through that list and install all of them using pkg_add. This saves considerable time since the make will build and install all missing dependencies. This is the crucial step: make CONFIGURE_ARGS='--disable-avahi --disable-mdns' you may have to use 'doas' for this step: make package this will create a cups package which can be installed with pkg_add on the system of your choice. It -will- install dbus. Removing that is harder. When this works you should probably work with the ports group to make this version available. They may not accept it because compiling another version of cups on their build systems would take too long. In any case posting a succinct list of the changes you had to make might be interesting to some people. geoff steckel
Re: mandoc output paper size
Hi Mike, hi Jan,
Mike Williams wrote on Sun, Oct 29, 2017 at 10:26:08AM +:
> If the media size is important for a page then there
> should be a PS setpagedevice call like the following:
[...]
> Basically don't rely on DSC comments to do media selection.
[...]
> It may be useful to use a media name such as man-A4, man-letter, etc.
Thanks a lot for pointing me to the relevant features and documentation
and for providing so much context. That really helped to improve
mandoc PostScript output.
See below for what i committed to -current. It would be quite
welcome if Jan could test on his multi-tray printer that the printer
actually selects the right paper for different -Opaper= options
now, and that there are no errors or warnings.
> As for PDF, no there is no way to name the media size being used.
No problem, so no changes seem to be required to PDF output.
> Finally, the -Tpdf output is not a valid PDF. It is missing the endobj
> keyword from several of the object definitions. This will cause
> warnings or errors when processing. I haven't updated to 6.2 yet so
> that may have been fixed by now, apologies if it has.
No, that is still broken in 6.2, i only fixed it post-6.2.
Thanks again,
Ingo
Log Message:
---
Print a human-readable media name in the %%DocumentMedia DSC comment
and use the setpagedevice PostScript operator to help printers
automatically select the paper of the best matching PageSize.
Many thanks to Mike Williams
for teaching me about the relevant features of PostScript and DSC
and for suggesting what to put into the first %%DocumentMedia argument.
Modified Files:
--
mandoc:
term_ps.c
Revision Data
-
Index: term_ps.c
===
RCS file: /home/cvs/mandoc/mandoc/term_ps.c,v
retrieving revision 1.88
retrieving revision 1.89
diff -Lterm_ps.c -Lterm_ps.c -u -p -r1.88 -r1.89
--- term_ps.c
+++ term_ps.c
@@ -77,6 +77,7 @@ structtermp_ps {
size_tlineheight; /* line height (AFM units) */
size_ttop; /* body top (AFM units) */
size_tbottom; /* body bottom (AFM units) */
+ const char *medianame;/* for DocumentMedia and PageSize */
size_theight; /* page height (AFM units */
size_twidth;/* page width (AFM units) */
size_tlastwidth;/* page width before last ll */
@@ -559,6 +560,7 @@ pspdf_alloc(const struct manoutput *outo
/* Default to US letter (millimetres). */
+ p->ps->medianame = "Letter";
pagex = 216;
pagey = 279;
@@ -570,20 +572,26 @@ pspdf_alloc(const struct manoutput *outo
*/
pp = outopts->paper;
- if (pp && strcasecmp(pp, "letter")) {
- if (0 == strcasecmp(pp, "a3")) {
+ if (pp != NULL && strcasecmp(pp, "letter") != 0) {
+ if (strcasecmp(pp, "a3") == 0) {
+ p->ps->medianame = "A3";
pagex = 297;
pagey = 420;
- } else if (0 == strcasecmp(pp, "a4")) {
+ } else if (strcasecmp(pp, "a4") == 0) {
+ p->ps->medianame = "A4";
pagex = 210;
pagey = 297;
- } else if (0 == strcasecmp(pp, "a5")) {
+ } else if (strcasecmp(pp, "a5") == 0) {
+ p->ps->medianame = "A5";
pagex = 148;
pagey = 210;
- } else if (0 == strcasecmp(pp, "legal")) {
+ } else if (strcasecmp(pp, "legal") == 0) {
+ p->ps->medianame = "Legal";
pagex = 216;
pagey = 356;
- } else if (2 != sscanf(pp, "%ux%u", &pagex, &pagey))
+ } else if (sscanf(pp, "%ux%u", &pagex, &pagey) == 2)
+ p->ps->medianame = "CustomSize";
+ else
warnx("%s: Unknown paper", pp);
}
@@ -846,6 +854,7 @@ ps_end(struct termp *p)
static void
ps_begin(struct termp *p)
{
+ size_t width, height;
int i;
/*
@@ -887,21 +896,29 @@ ps_begin(struct termp *p)
*/
if (TERMTYPE_PS == p->type) {
+ width = AFM2PNT(p, p->ps->width);
+ height = AFM2PNT(p, p->ps->height);
+
ps_printf(p, "%%!PS-Adobe-3.0\n");
ps_printf(p, "DocumentData: Clean7Bit\n");
ps_printf(p, "Orientation: Portrait\n");
ps_printf(p, "Pages: (atend)\n");
ps_printf(p, "PageOrder: Ascend\n");
- ps_printf(p, "DocumentMedia: "
- "Default %zu %zu 0 () ()\n",
- (size_t)AFM2PNT(p, p->ps->width),
- (size_t)AFM2PNT(p, p->ps->he
Re: CUPS and AVAHI (bloatware)
Hi, gwes wrote on Sun, Oct 29, 2017 at 03:40:48PM -0400: > On 10/26/17 07:24, Rupert Gallagher wrote: >> If you have a server with limited resources and without X11, >> you cannot install the present cups package. I can't comment on CUPS and avahi in particular, but yes, in general, X libraries are required to work with packages(7). So even on a stunted server, always install xbase??.tgz, or expect trouble and deal with it without asking for help or for changes to the system. Disks that can't hold an additional 63 MB practically no longer exist. > When this works you should probably work with the ports > group to make this version available. They may not accept > it because compiling another version of cups on their > build systems would take too long. Bulk build times are a consideration, but even if build times are moderate, additional flavours are often rejected because simplicity and reliability are paramount. Each additional flavour invites additional failure modes, requires additional testing, and complicates maintenance of dependent ports. > In any case posting a succinct list of the changes you had to make > might be interesting to some people. In general, home-brewing a version of a library package with some dependency removed is a very bad idea. Even if you do it, don't advertise the details to the world, because it is likely to trap the unwary, in particular those who understand even less than you what they are doing, into following you and screwing their systems up. Say you build custom, non-official flavour L-noD of the library package L that, in the official ports tree, always depends on the package D. Months later, you decide to install the application package A that depends on L. If A also depends on D, the port maintainer probably did *not* register the dependency on D in LIB_DEPENDS, BUILD_DEPENDS, or RUN_DEPENDS because that's already implied by the dependency on L. So with your non-official L-noD installed, any attempt to install A is likely to fail in surprising ways, no matter whether you try installing it from packages or whether you try to build it yourself in your own copy of the ports tree. Yours, Ingo
Re: CUPS and AVAHI (bloatware)
On 2017-10-29, gwes wrote: > When this works you should probably work with the ports > group to make this version available. They may not accept > it because compiling another version of cups on their > build systems would take too long. Build time of cups isn't really an issue. But the dependency chain around cups is already very delicate, and anything involving optional dependencies for a library gets *really* awkward further down the chain.
Re: Fail2ban alternative for OpenBSD
You might also want to check out http://openports.se/security/sshguard which integrates directly with PF. I find it quite effective. On 29 Oct 2017 at 6:30, x9p wrote: > On 2017-10-29 04:35, Rupert Gallagher wrote: > > Note that PF cannot discriminate between legitimate and abusive > > multiple connections from same cidr. If you whitelist the cidr of a > > mobile network, to avoid banning yourself on port 993, you also > > whitelist bruteforce attacks from the same cidr. > > > > Sent from ProtonMail Mobile > > > > On Sun, Oct 29, 2017 at 5:26 AM, Tom Rosso wrote: > > > >> On 2017-10-28 21:20, x9p wrote: > Hi, > > Coming from the Linux world, > >> I wonder if there is a better alternative > to fail2ban, already being > >> used in OpenBSD servers by the majority. > > cheers. > > x9p The pf > >> firewall provides the capability to block brute force attacks. See > >> max-src-conn-rate. > >> https://www.openbsd.org/faq/pf/filter.html#stateopts > > was suggested http://openports.se/sysutils/sec , which seems the most > proper. > > thanks all for the inputs.. > > cheers. > > x9p > >
Re: pkg_add -u skipping mutt and python
On 2017-10-26, Alex Holst wrote: > mutt is linked against two libc. To make matters worse, I am running > mutt 1.6.2 from 6.0, not 1.9.x from OpenBSD 6.2. Mutt isn't linked against two libc. Some of the libraries it use have been updated (pulling in new libc) but mutt itself hasn't been updated. > Skipping mutt-1.9.1v3-gpgme-sasl (update candidate for > mutt-1.6.2v0-compressed-sasl-sidebar-slang) > mutt-1.6.2v0-compressed-sasl-sidebar-slang pkgpaths: > mail/mutt,sasl,sidebar,slang,compressed > mail/mutt/,slang,compressed,sidebar,sasl > mail/mutt/snapshot,sasl,sidebar,compressed,slang > mail/mutt/stable,sasl,slang,compressed,sidebar > mutt-1.9.1v3-gpgme-sasl pkgpaths: mail/mutt/stable,sasl,gpgme > mail/mutt/snapshot,sasl,gpgme mail/mutt,sasl,gpgme mail/mutt/,sasl,gpgme I just removed a stray / in the PLIST in the port in -current, which *may* be related, but honestly I would just pkg_delete and pkg_add the version you want. The maze of flavours makes it hard to get updates absolutely correct with all combinations. > [..] > Skipping python-3.6.2 (update candidate for python-3.4.5p2) > python-3.4.5p2 pkgpaths: lang/python/3.4,-main lang/python3/3.4,-main > python-3.6.2 pkgpaths: lang/python3/3.6,-main lang/python/3.6,-main This is working as currently designed (though I agree it's not totally useful). python/3.4 and python/3.6 are separate branches in ports and don't auto update between the branches, even though python 3.4 (and 3.5) have now been removed. Problem is, the module directories are different, so if you had some locally installed thing using 3.4 it probably wouldn't work directly with 3.6. Leaving them installed in parallel there's still some chance old programs will still run (up to a point).
Re: CUPS and AVAHI (bloatware)
Stuart Henderson wrote: > Build time of cups isn't really an issue. But the dependency chain > around cups is already very delicate, and anything involving optional > dependencies for a library gets *really* awkward further down the chain. How about package splitting? cups doesn't require avahi binaries or XML dbus entries (org.freedesktop.Avahi.Something.xml), it can only use libavahi-client and libavahi-common shared libraries, so let them be in avahi-libs or libavahi or whatever. The same applies to dbus packages; they're big and fat with a lot of executables, but many programmes only need libdbus.so. Since we started the topic, another example: as I am typing this in mutt, why would I need the entire cyrus-sasl, if mutt-sasl only needs libsasl? It's already done by various package managers, some of them are ugly, some of them are pretty cool. Most of them split packages into -dev, -doc, -lang, and lib-, of course in case of having files that fit these categories: headers and such - in -dev; man/info pages, pdf/html docs - in -doc; /usr/local/share/locale files - in -lang; shared libs - in lib-. -- caóc
Re: CUPS and AVAHI (bloatware)
> > Build time of cups isn't really an issue. But the dependency chain > > around cups is already very delicate, and anything involving optional > > dependencies for a library gets *really* awkward further down the chain. > > How about package splitting? cups doesn't require avahi binaries or XML > dbus entries (org.freedesktop.Avahi.Something.xml), it can only use > libavahi-client and libavahi-common shared libraries, so let them be in > avahi-libs or libavahi or whatever. The same applies to dbus packages; > they're big and fat with a lot of executables, but many programmes only > need libdbus.so. So basically you are saying the ports developers, who have worked very hard, haven't built things exactly the way you want. Did I get that right? By the way who are you? Are you proposing to write a diff which handles all the cases, or are you offloading a proposal on other people -- a proposal you came up with in the last hour or so? You come off as pretty uncharitable. > Since we started the topic, another example: as I am typing this in > mutt, why would I need the entire cyrus-sasl, if mutt-sasl only needs > libsasl? Because decisions were made by some people, to try to satisfy the most common requirements. > It's already done by various package managers, some of them are ugly, > some of them are pretty cool. Most of them split packages into -dev, > -doc, -lang, and lib-, of course in case of having files that fit > these categories: > headers and such - in -dev; > man/info pages, pdf/html docs - in -doc; > /usr/local/share/locale files - in -lang; > shared libs - in lib-. More complexity. I don't think you are listening. The ports developers make economical decisions as to how things get coupled, because the upstreams keep changing their minds. You can seperate things, and a year down the line that seperation doesn't work anymore. Then it all has to be redone. It seems there aren't enough people in the ports tree to satisfy the complex requirements you describe.
Re: CUPS and AVAHI (bloatware)
Hi, Cag wrote on Sun, Oct 29, 2017 at 09:49:49PM +: > headers and such - in -dev; No. OpenBSD is a developer-oriented system, so headers are an integral part of the installation. Installing them must not be optional, or it will cause nothing but needless confusion as soon as people actually start using what they installed. > man/info pages, pdf/html docs - in -doc; Over my dead body. Software without documentation is completely useless, almost a crime. Docs must always be available, even on a tiny server. The sysadmin logs into the server, needs a brief look at the docs to fix stuff -- and is slowed down because the docs aren't there, and a web search turns up the wrong version, and a wild goose chase ensues? No way. Yes, there are exceptions. If the documentation is of excessive size, in a hostile format like PDF, and/or needs a ridiculous toolchain for building, then in rare cases separate -doc may be the least terrible way out, but it's always a symptom that docs are pitifully defective. > /usr/local/share/locale files - in -lang; In most cases useless on OpenBSD, most of that stuff isn't used in the first place. Certainly not important enough to consider special rules for it. KISS. Yours, Ingo
Re: CUPS and AVAHI (bloatware)
> So basically you are saying the ports developers, who have worked very > hard, haven't built things exactly the way you want. > Did I get that right? Nobody apparently cared about it (neither do I really). It's an idea to be discussed (or not), not a proposal to have an answer right now. > By the way who are you? A happy fairly long time user. > Are you proposing to write a diff which handles all the cases, or > are you offloading a proposal on other people -- a proposal you came > up with in the last hour or so? A couple of years ago or so, it doesn't matter. It was discussed privately and in some forums/lists; and it wasn't me who came up with this idea first, certainly. > More complexity. If would literally take a couple of if's in Makefile for a price of A LOT of saved bandwidth and disk space. Of course it would quadruple the number of packages. > You can seperate things, and a year down the line that seperation > doesn't work anymore. Then it all has to be redone. This can happen with a build system, then it used CMake, now it uses ninja. Or then it relied on GTK+2, now it uses GTK+3. Or Qt. Or Tk. Or previous ./configure no longer exist. -- caóc
Re: CUPS and AVAHI (bloatware)
> > So basically you are saying the ports developers, who have worked very > > hard, haven't built things exactly the way you want. > > Did I get that right? > > Nobody apparently cared about it (neither do I really). It's an idea to > be discussed (or not), not a proposal to have an answer right now. Shrug. > > By the way who are you? > > A happy fairly long time user. They keep using. But your mails are going beyond by being critical of decisions made. > > Are you proposing to write a diff which handles all the cases, or > > are you offloading a proposal on other people -- a proposal you came > > up with in the last hour or so? > > A couple of years ago or so, it doesn't matter. It was discussed > privately and in some forums/lists; and it wasn't me who came up with > this idea first, certainly. I discussed world peace in a bar once. > If would literally take a couple of if's in Makefile for a price of > A LOT of saved bandwidth and disk space. Of course it would quadruple > the number of packages. You don't get to make the decisions, since you aren't doing the work. > > You can seperate things, and a year down the line that seperation > > doesn't work anymore. Then it all has to be redone. > > This can happen with a build system, then it used CMake, now it uses > ninja. Or then it relied on GTK+2, now it uses GTK+3. Or Qt. Or Tk. > Or previous ./configure no longer exist. Lots of words. No action.
Re: CUPS and AVAHI (bloatware)
Ingo Schwarze wrote: > No. OpenBSD is a developer-oriented system, so headers are an > integral part of the installation. Installing them must not be > optional, or it will cause nothing but needless confusion as soon > as people actually start using what they installed. And what if someone wants to build an OpenBSD router? It doesn't need headers, or docs. It doesn't have a lot of storage. Are you a dev? Use this meta -dev package that pulls -dev versions of all packages you installed. Are you an admin? Install this -doc metapackage with docs. Cheers -- caóc
Re: CUPS and AVAHI (bloatware)
> > No. OpenBSD is a developer-oriented system, so headers are an > > integral part of the installation. Installing them must not be > > optional, or it will cause nothing but needless confusion as soon > > as people actually start using what they installed. > > And what if someone wants to build an OpenBSD router? It doesn't need > headers, or docs. It doesn't have a lot of storage. Are you a dev? > Use this meta -dev package that pulls -dev versions of all packages > you installed. Are you an admin? Install this -doc metapackage with > docs. You can use what we provide which satisfies the maximum number of needs & requiresments in the smallest complete operating system package... Or you can go it all yourself. Why don't you do that? It is pretty obvious you are only thinking of yourself, so you should go create your own system. I actually think you don't have the combination of balls, skills, or dedication to follow through on anything you are talking about, so I expect you'll keep using OpenBSD. But we don't need to put up with your demands. Adjust your attitude user -- you didnt pay a dime for the wonderful software built over 25 years by thousands of volunteers. I believe this conversation is over, because you have no credibility.
Re: CUPS and AVAHI (bloatware)
On Sun, Oct 29 2017, Ingo Schwarze wrote: [...] >> /usr/local/share/locale files - in -lang; > > In most cases useless on OpenBSD, most of that stuff isn't used > in the first place. Most of what can be found in /usr/local/share/locale are LC_MESSAGES files handled by gettext, they are actually used as soon as one sets LC_MESSAGES. There's a bunch of LC_TIME and LC_SCRIPTS files too, which are unused it seems. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: CUPS and AVAHI (bloatware)
Hi Cag, Cag wrote on Sun, Oct 29, 2017 at 10:51:29PM +: > Ingo Schwarze wrote: >> No. OpenBSD is a developer-oriented system, so headers are an >> integral part of the installation. Installing them must not be >> optional, or it will cause nothing but needless confusion as soon >> as people actually start using what they installed. > And what if someone wants to build an OpenBSD router? I did so many times. > It doesn't need headers, or docs. I did read manual pages there in the past, for sure. It even happened in 2017 that i read manual pages on a server machine (that doesn't even have a monitor) and then committed improvements to that manual based on what i read there. Besides, i regularly use /usr/include as part of the documentation, usually more than once every week. Many manual pages contain copies of struct declarations, but many others actually point to the header files for that kind of documentation, and many OpenBSD developers agree that in some cases, that's a reasonable way to document. > It doesn't have a lot of storage. Sure, my first OpenBSD router had 200 MB of hard disk space grand total. I did have to do a few special things to save space there, but the last time i needed that was more than a decade ago. One i'm currently still running has a 1 GB disk. No more special savings needed, OpenBSD just works out of the box. Oh, and by the way, the only package i usually install on routers is this one: $ pkg_info -L rsync Information for inst:rsync-3.1.2p0 Files: /usr/local/bin/rrsync /usr/local/bin/rsync /usr/local/man/man1/rsync.1 /usr/local/man/man5/rsyncd.conf.5 /usr/local/share/doc/rsync/tech_report.tex /etc/rc.d/rsyncd I guess you don't want to split that into -main and -doc, right? So the discussion about splitting packages is *particularly* irrelevant for very small servers because those have hardly any packages in the first place. > Are you a dev? Yes, I am. > Use this meta -dev package that pulls -dev versions of all packages > you installed. Hell, no. Useless additional work, one more thing to code when packaging, one more thing to configure, one more thing to maintain, one more thing to forget about. > Are you an admin? Yes, I am. > Install this -doc metapackage with docs. Useless additional work. One among the most important strengths of OpenBSD is that it requires less work and less configuration. It just works without any of the additional steps you propose. I do all the things you want to improve all the time, but don't see any actual problem that needs solving. Yours, Ingo
Gateway - Cannot bring WiFi up or broadcast ssid
I am configuring my home gateway. Being enthusiastically new to OpenBSD, I followed the directions here along with other various bits of documentation along the way: https://www.openbsd.org/faq/pf/example1.html Unfortunately, I can't seem to understand how to bring my WiFi network "up" and broadcast my SSID. Here is output from `ifconfig`: iwm0: flags=8843 mtu 1500 lladdr f0:42:1c:80:df:90 index 4 priority 4 llprio 3 groups: wlan media: IEEE802.11 autoselect status: no network ieee80211: nwid chan 1 wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255 Running these commands don't seem to do anything: # ifconfig iwm0 up # ifconfig iwm0 up scan Here is my `/etc/hostname.iwm0` file: # cat /etc/hostname.iwm0 media autoselect mode 11n mediaopt hostap chan 1 nwid wpakey inet 192.168.2.1 255.255.255.0 dmesg output: # dmesg | grep "iwm0" iwm0 at pci4 dev 0 function 0 "Intel Dual Band Wireless AC 7260" rev 0xc3, msi iwm0: hw rev 0x140, fw ver 16.242414.0, address f0:42:1c:80:df:90 I'd appreciate if anyone can point me in the right direction on how to better debug, learn, or otherwise get this working.
Re: Gateway - Cannot bring WiFi up or broadcast ssid
On 10/29/17 17:51, Kurtis wrote: I am configuring my home gateway. Being enthusiastically new to OpenBSD, I followed the directions here along with other various bits of documentation along the way: https://www.openbsd.org/faq/pf/example1.html Unfortunately, I can't seem to understand how to bring my WiFi network "up" and broadcast my SSID. Here is output from `ifconfig`: iwm0: flags=8843 mtu 1500 lladdr f0:42:1c:80:df:90 index 4 priority 4 llprio 3 groups: wlan media: IEEE802.11 autoselect status: no network ieee80211: nwid chan 1 wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255 Running these commands don't seem to do anything: # ifconfig iwm0 up # ifconfig iwm0 up scan Here is my `/etc/hostname.iwm0` file: # cat /etc/hostname.iwm0 media autoselect mode 11n mediaopt hostap chan 1 nwid wpakey inet 192.168.2.1 255.255.255.0 dmesg output: # dmesg | grep "iwm0" iwm0 at pci4 dev 0 function 0 "Intel Dual Band Wireless AC 7260" rev 0xc3, msi iwm0: hw rev 0x140, fw ver 16.242414.0, address f0:42:1c:80:df:90 I'd appreciate if anyone can point me in the right direction on how to better debug, learn, or otherwise get this working. Hi Kurtis, iwm(4) doesn't support hostap mode. You might want to check out a compatible ath(4) or athn(4) card. +--+ Carlos
Need to swap partitions: /tmp amd /usr
Good Evening Fellow OpenBSDers, Below is currently how I have my disk laid out partition wise. I have a feeling I need to swap /tmp and /usr in order to gain additional space for /usr. What is the best way to go about that? Filesystem SizeUsed Avail Capacity Mounted on /dev/wd0a 1005M708M247M74%/ /dev/wd0k 22.7G 20.0K 21.6G 0%/home /dev/wd0d 3.9G 10.0K3.7G 0%/tmp /dev/wd0f 2.0G1.7G153M92%/usr /dev/wd0g 1005M227M728M24%/usr/X11R6 /dev/wd0h 6.8G 27.1M6.4G 0%/usr/local /dev/wd0j 3.9G293M3.5G 8%/usr/obj /dev/wd0i 3.9G852M2.9G22%/usr/src /dev/wd0e 6.3G 28.0M6.0G 0%/var Thanking you in advance, Jay
Re: Gateway - Cannot bring WiFi up or broadcast ssid
Thank you very much, Carlos! That explains a lot, and you probably just saved me many more hours of frustration. I purchased this WiFi device with my new APU2. Is there a guide or list to find decent devices which will support hostap mode? I'm not quite sure what to look for when reading specs or driver man pages. > Original Message > Subject: Re: Gateway - Cannot bring WiFi up or broadcast ssid > Local Time: October 29, 2017 9:26 PM > UTC Time: October 30, 2017 1:26 AM > From: cardena...@gmail.com > To: Kurtis > misc@openbsd.org > > On 10/29/17 17:51, Kurtis wrote: > >> I am configuring my home gateway. Being enthusiastically new to >> OpenBSD, I followed the directions here along with other various >> bits of documentation along the way: >> https://www.openbsd.org/faq/pf/example1.html >> Unfortunately, I can't seem to understand how to bring my WiFi >> network "up" and broadcast my SSID. Here is output from >> ifconfig: >> iwm0: flags=8843 mtu 1500 >> lladdr f0:42:1c:80:df:90 >> index 4 priority 4 llprio 3 >> groups: wlan >> media: IEEE802.11 autoselect >> status: no network >> ieee80211: nwid chan 1 wpakey wpaprotos wpa2 >> wpaakms psk wpaciphers ccmp wpagroupcipher ccmp >> inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255 >> Running these commands don't seem to do anything: >> >> ifconfig iwm0 up >> >> ifconfig iwm0 up scan >> >> Here is my /etc/hostname.iwm0 file: >> >> cat /etc/hostname.iwm0 >> >> media autoselect mode 11n mediaopt hostap chan 1 >> nwid >> wpakey >> inet 192.168.2.1 255.255.255.0 >> dmesg output: >> >> dmesg | grep "iwm0" >> >> iwm0 at pci4 dev 0 function 0 "Intel Dual Band Wireless AC 7260" rev 0xc3, >> msi >> iwm0: hw rev 0x140, fw ver 16.242414.0, address f0:42:1c:80:df:90 >> I'd appreciate if anyone can point me in the right direction on how to better >> debug, learn, or otherwise get this working. > > Hi Kurtis, > > iwm(4) doesn't support hostap mode. You might want to check out a compatible > ath(4) or athn(4) card. > > +--+ > Carlos
Re: Gateway - Cannot bring WiFi up or broadcast ssid
On 10/29/17 18:38, Kurtis wrote: Thank you very much, Carlos! That explains a lot, and you probably just saved me many more hours of frustration. I purchased this WiFi device with my new APU2. Is there a guide or list to find decent devices which will support hostap mode? I'm not quite sure what to look for when reading specs or driver man pages. Take a look at: https://www.openbsd.org/faq/faq6.html#Wireless At the top of that section, it talks about Host AP mode and which drivers support them. Take a look at each of those respective man pages (personally, I would focus on ath(4), athn(4), and ral(4)) and choose the chipset capabilities you are looking for. If you bought your APU2 from PC Engines, they also sell the Compex WLE200NX (http://pcengines.ch/wle200nx.htm) which is a compatible athn(4) card. +--+ Carlos Original Message Subject: Re: Gateway - Cannot bring WiFi up or broadcast ssid Local Time: October 29, 2017 9:26 PM UTC Time: October 30, 2017 1:26 AM From: cardena...@gmail.com To: Kurtis misc@openbsd.org On 10/29/17 17:51, Kurtis wrote: I am configuring my home gateway. Being enthusiastically new to OpenBSD, I followed the directions here along with other various bits of documentation along the way: https://www.openbsd.org/faq/pf/example1.html Unfortunately, I can't seem to understand how to bring my WiFi network "up" and broadcast my SSID. Here is output from ifconfig: iwm0: flags=8843 mtu 1500 lladdr f0:42:1c:80:df:90 index 4 priority 4 llprio 3 groups: wlan media: IEEE802.11 autoselect status: no network ieee80211: nwid chan 1 wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255 Running these commands don't seem to do anything: ifconfig iwm0 up ifconfig iwm0 up scan Here is my /etc/hostname.iwm0 file: cat /etc/hostname.iwm0 media autoselect mode 11n mediaopt hostap chan 1 nwid wpakey inet 192.168.2.1 255.255.255.0 dmesg output: dmesg | grep "iwm0" iwm0 at pci4 dev 0 function 0 "Intel Dual Band Wireless AC 7260" rev 0xc3, msi iwm0: hw rev 0x140, fw ver 16.242414.0, address f0:42:1c:80:df:90 I'd appreciate if anyone can point me in the right direction on how to better debug, learn, or otherwise get this working. Hi Kurtis, iwm(4) doesn't support hostap mode. You might want to check out a compatible ath(4) or athn(4) card. +--+ Carlos
Re: 5-button wheeled mouse and X
On Sun, 29 Oct 2017 11:37:45 -0400, gwes wrote: > On 10/25/17 07:20, Cág wrote: > > Natasha Kerensikova wrote: > > > >> it started as a bug report: it have a 5-button mouse with a wheel, > >> even though I don't use much the buttons 4 and 5 (I think only for > >> previous and next in firefox history). I recently switched to > >> OpenBSD, and I was surprised to find these buttons cause > >> scrolling, like the wheel. If this behavior is intended, the rest > >> of this e-mail is moot. > > > > This isn't a bug apparently. Are the extra buttons recognised by > > xev? If they are, remap them with xmodmap(1). If they aren't, well, > > then it should be done by xf86-input-evdev or libinput. There's > > been some work in FreeBSD, and the drivers are in ports, but > > OpenBSD doesn't have them. > I use a 4-button Logitech trackball mouse. It required remapping in > xmodmap to make it work. > Yes, xev showed enough information to see "button up" and "button > down" events to use as input to xmodmap. Do you mind sharing your configuration? Cheers, Daniel
Re: CUPS and AVAHI (bloatware)
I don't like the idea of splitting packages, but I get weirded out when ghostscript (which DOES have a no_x11 variant) winds up pulling in dbus. I guess there's no escaping freedesktop.org. khm
Re: MATE Desktop Environment 1.18.0
Hi, apmd -A I didn't try the other one you mentioned though and it's too late for me to try unfortunately. > On Sat, Oct 28, 2017 at 06:12:33PM -0400, tec...@protonmail.com wrote: > >> A little off topic.. but.. >> I haven't tried MATE, but I have the same laptop (T430) and can report that >> XFCE works very well without major issue ..although I did find that some >> problems with over-heating and constant fan use resulting in faster battery >> drain. >> >> Are you running the laptop with "sysctl hw.perfpolicy=auto" or "apm -A"? >> >> Gnome3 didn't perform well on my T430 - had to remove it after just a couple >> of hours. The performance difference between Gnome3 on OpenBSD and Gnome3 on >> Debian is like night and day. >> Anyway, just thought I'd share some stuff I've noticed with having the same >> machine. >> >>> Original Message >>> Subject: MATE Desktop Environment 1.18.0 >>> Local Time: October 28, 2017 9:33 PM >>> UTC Time: October 28, 2017 8:33 PM >>> From: oregn...@riseup.net >>> To: misc@openbsd.org >>> Hi, >>> I'm currently using MATE Desktop with OpenBSD / amd64 6.2 -stable on a >>> Lenovo ThinkPad T430. >>> I want to report some errors encountered during its use. >>> Have you ever encountered these errors and possibly found a solution? >>> gnome-keyring-daemon[31733]: couldn't access control socket: >>> /var/run/user/1000/keyring/control: No such file or directory >>> gnome-keyring-daemon[31733]: The PKCS#11 component was already initialized >>> gnome-keyring-daemon[31733]: The Secret Service was already initialized >>> console-kit-daemon[49025]: WARNING: Error waiting for native console 1 >>> activation: Permission denied >>> console-kit-daemon[49025]: WARNING: Error waiting for native console 2 >>> activation: Permission denied >>> console-kit-daemon[49025]: WARNING: Error waiting for native console 3 >>> activation: Permission denied >>> console-kit-daemon[49025]: WARNING: Error waiting for native console 4 >>> activation: Permission denied >>> mate-session[53962]: WARNING: Unable to find provider '' of required >>> component 'dock' >>> ** (mate-settings-daemon:59867): WARNING **: Error opening directory >>> /etc/xrdb: No such file or directory >>> [system] Activating service >>> name='org.mate.SettingsDaemon.DateTimeMechanism' (using servicehelper) >>> [system] Activated service 'org.mate.SettingsDaemon.DateTimeMechanism' >>> failed: Launch helper exited with unknown return code 1 >>> pulseaudio[87536]: [(null)] authkey.c: Failed to open cookie file >>> '/home/loginname/.config/pulse/cookie': No such file or directory >>> pulseaudio[87536]: [(null)] authkey.c: Failed to load authentication key >>> '/home/loginname/.config/pulse/cookie': No such file or directory >>> pulseaudio[87536]: [(null)] authkey.c: Failed to open cookie file >>> /home/loginname/.pulse-cookie': No such file or directory >>> pulseaudio[87356]: [(null)] authkey.c: Failed to load authentication key >>> '/home/loginname/.pulse-cookie': No such or directory >>> pulseaudio[87536]: [(null)] core-util.c: Failed to create secure directory >>> (/var/run/user/1000/pulse): No such file or directory >>> DEBUG (42951): glibtop_open_p () >>> LibGTop-Server(c=42951): [ERROR] kvm_open: Operation not permitted >>> glibtop(c=57092/s=42951): [ERROR] read 8 bytes: Resource temporarily >>> unavailable >>> (marco:5367): Gdk-ERROR **: The program 'marco' received an X Window >>> System error. >>> This probably reflets a bug in the program. >>> The error was 'BadRegion (invalid Region parameter)'. >>> (Details: serial 116413 error_code 140 request_code 138 (XFIXES) >>> minor_code 10) >>> Thank you for your help. >>> >>> - Olivier Regnier >>> >>> -- >>> Juan Francisco Cantero Hurtado http://juanfra.info
Re: CUPS and AVAHI (bloatware)
The last time AVAHI got installed on one of my systems the installer started it immediately. Avahi then proceeded to scribble on that system's network configuration and confuse other systems on that subnet. I would assert that Avahi should be either (a) not automatically started when installed or (b) split. I am not asking for a general split. This one package causes a lot of confusion if the daemons are started. A simple "do you want to enable the daemons?" would be good enough. Is this worth considering? thanks geoff steckel
