- Roundtable - muug.ca

just me? fido
by Trevor Cordes 05 Jan '16

05 Jan '16

In the latest rev of their web site, Fido broke the login functionality for me in Firefox on linux. Works on FF on Windows and Chrome on Windows. Is anyone else having a problem? fido.ca -> login ... no popup ever appears for me to type in the user/pass. Strangely, FF on linux says that some content is not https, but FF on Windows says *all* the content is https. I wonder if I change my UA string if that would go away... but even when I "allow all content" it still won't let me login. I think FF used to have a web page you could go and submit broken popular websites to so they could examine / fix? Do they still do this? Can't find it anywhere. I suppose there's the mozilla bugzilla...

3 3

MUUG Meeting, Jan 12, 7:30pm -- Logstash Revisited
by Gilbert E. Detillieux 05 Jan '16

05 Jan '16

The Manitoba UNIX User Group (MUUG) will be holding its next monthly meeting on Tuesday, January 12. The meeting topic for this month is as follows: Logstash Revisited This month, Paul Sierks will be giving us an in-depth look at Logstash, which was briefly mentioned and demoed at the November meeting, when Rob Keizer presented it in the context of Elasticsearch and Kibana. RTFM In the RTFM segment this month, Wyatt Zacharias will be showing us qrencode(1). The group holds its general meetings at 7:30pm on the second Tuesday of every month from September to June. (There are no meetings in July and August.) Meetings are open to the general public; you don't have to be a MUUG member to attend. ****************************************************************** Please note our *NEW* meeting location for this month: *Room 3M60* (3rd floor) Manitoba Hall, University of Winnipeg, entrance on Ellice Ave. between Spence St. and Balmoral St. Parking is available on the surrounding streets and in the lots on nearby streets. Look for signage once you're at the building, or ask a security guard. ****************************************************************** For more information about MUUG, and its monthly meetings, check out their web server: http://www.muug.mb.ca/ Help us promote this month's meeting, by putting this poster up on your workplace bulletin board or other suitable public message board: http://www.muug.mb.ca/meetings/MUUGmeeting.pdf -- Manitoba UNIX User Group E-mail: <gedetil(a)muug.mb.ca> c/o Gilbert E. Detillieux Web: http://www.muug.mb.ca/ University of Manitoba Phone: (204)474-8161 Winnipeg MB CANADA R3T 2N2 Fax: (204)474-7609

1 0

mysql bug, hah!!
by Trevor Cordes 05 Jan '16

05 Jan '16

Isn't that just the way it always is?? ... https://bugs.mysql.com/bug.php?id=20786 ========= Bug #20786 mysqldump always includes AUTO_INCREMENT Submitted: 29 Jun 2006 22:31 [21 Jul 2011 1:27] John Swapceinski I'm planning to throw a 5 year birthday party for this bug at the end of the month. Who wants to come? Anyone from MySQL/Sun/Oracle? There will be cake. [28 Jun 2013 17:25] Ada Pascal And now there has been cake: http://www.youtube.com/watch?v=oAiVsbXVP6k Happy 7th birthday MySQL bug #20786! seriously ROFL video PS: this bug is in mariadb too PPS: this bug is biting me now... (piping through sed... sigh)

1 0

mysql crash and non-restart due to RAM?
by Trevor Cordes 04 Jan '16

04 Jan '16

I had a box with 32GB RAM have its mysql just die (no logs, just die). init tried to restart it (RHEL6) and I got this: 160104 8:55:55 InnoDB: Initializing buffer pool, size = 3.9G 160104 8:55:55 InnoDB: Error: cannot allocate 4194320384 bytes of InnoDB: memory with malloc! Total allocated memory InnoDB: by InnoDB 48401248 bytes. Operating system errno: 12 InnoDB: Check if you should increase the swap file or InnoDB: ulimits of your operating system. InnoDB: On FreeBSD check you have compiled the OS with InnoDB: a big enough maximum process size. InnoDB: Note that in most 32-bit computers the process InnoDB: memory space is limited to 2 GB or 4 GB. InnoDB: We keep retrying the allocation for 60 seconds... The setting of a 4G buffer pool was working for months until just now. I reduced it to 3G and mysql restarted ok. Top shows: Mem: 32827576k total, 2274940k used, 30552636k free, 165052k buffers Swap: 2097148k total, 276068k used, 1821080k free, 413640k cached Cacti (up until mysql crashed, wink) shows ps load going up, but that is normal for this box, and RAM usage stayed constant, right before the crash. However, we did launch a long ps that spawns a lot of little ps's (like maybe 100 at a time). This is all normal for this box, and it never has done this before. I'm guessing RAM fragmentation: #cat /proc/buddyinfo Node 0, zone DMA 2 1 1 1 1 0 1 0 1 1 3 Node 0, zone DMA32 1815 1789 1553 1294 1007 688 415 212 103 67 477 Node 0, zone Normal 32859 67280 77301 62304 45390 29754 19144 11069 4786 530 177 (anything else to check?) Looks like tons of pages avail of every size, assuming mysql uses "normal". Any ideas? My only thought now is to reboot server more often to clear fragmentation. Maybe newer kernels solve this "bug" a bit better, but I'm stuck on RHEL6 right now.

2 4

UI convention to show collapsible content (+ and - icons vs left/right and down arrows)
by Fortress Software Inc. 04 Jan '16

04 Jan '16

(Adam, Trevor, and MUUG round table, I have added you to this discussion for you valuable input.) My kids and I have been discussing proper icons to distinguish collapsible content on the web (specifically on one of my new mobile friendly/responsive web pages: http://matchomatics.com/index.php?country=canada&page=why-matchomatics) Our discussions were for which icons identify the collapsible content behavior the best (arrows/chevrons vs +/-). After much more web based research I think I will stick to '<' for collapsed and 'v' for expanded as using +/- icons can confuse users that this is as an 'add/remove' action. And sorry Alex, I see only a small sampling of reference to an '^' arrow to show collapsed content. Interesting to note that when using arrows the icon shows the 'current' state but when using +/- the icons show the 'action' state. Don't you just love UI transitions, as in the 'hamburger' menu icon... Bradford C. Vokey - Director ============================== Fortress Software Incorporated ============================== 390 Provencher Blvd Unit F Winnipeg, Manitoba, Canada R2H 0H1 ----------------------------------------------- Phone: (204) 231-3969 or 1-800-665-0396 FAX: 1-800-513-9356 -----------------------------------------------

4 3

Bug doh moment of the week
by Trevor Cordes 31 Dec '15

31 Dec '15

Doh! Ya, that might be a problem... Date: Wed, 30 Dec 2015 17:51:54 +0000 (UTC) From: updates(a)fedoraproject.org Subject: [SECURITY] Fedora 22 Update: cups-filters-1.4.0-1.fc22 [ 1 ] Bug #1291227 - CVE-2015-8560 cups-filters: foomatic-rip did not consider semicolon as illegal shell escape character https://bugzilla.redhat.com/show_bug.cgi?id=1291227

1 0

Re: [RndTbl] Roundtable Digest, Vol 132, Issue 9
by Michael Doob 23 Dec '15

23 Dec '15

This exact situation has happened to me due to the following scenario: I rsync parts of my system nightly onto an external esata drive mounted in the file system. If something hiccups and the drive gets unmounted, the backup is done onto the root file system at the mount point, and then when the drive gets remounted the files on the root system are hidden in just the way just as you described you described. The script now looks at what is mounted on the file system before rsync runs. It's obvious once you see it (just like mathematics). Cheers, Michael On 15-12-23 12:00 PM, roundtable-request(a)muug.mb.ca wrote: > Send Roundtable mailing list submissions to > roundtable(a)muug.mb.ca > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.muug.mb.ca/mailman/listinfo/roundtable > or, via email, send a message with subject or body 'help' to > roundtable-request(a)muug.mb.ca > > You can reach the person managing the list at > roundtable-owner(a)muug.mb.ca > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Roundtable digest..." > > > Today's Topics: > > 1. "Missing" disk space (Adam Thompson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 22 Dec 2015 12:02:05 -0600 > From: Adam Thompson <athompson(a)avant.ca> > To: roundtable(a)muug.mb.ca > Subject: [RndTbl] "Missing" disk space > Message-ID: > <CAFGv8b9jCKjwVhRjJLWm7cSWz9GoxQ5ZYO+AE_gCRsU0rhP8Vg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Documenting for posterity, and in case anyone else runs into the same > problem: > > > I ran into a situation today where df(1) showed me a filesystem that was > getting pretty full (109GB used out of 146GB), but when I used du(1) to > find the space hogs, it was only able to locate <30GB of data on the > partition. > > (Hint: it was the root partition.) > > The culprit turned out to be 87GB of files "hidden" underneath > mountpoints. If you create /mnt/xyz, copy files into /mnt/xyz/*, then > mount another filesystem (local or remote) at /mnt/xyz, the original files > are still there, still taking up disk space, but unavailable. > > Luckily, this was a Linux system, and I was able to get access to those > files using a rebind mount: > - mkdir /tmp/xyz" > - "mount -o rebind /dev/mapper/root_lv /tmp/xyz" > - "cd /tmp/xyz/mnt/xyz" > - "du -sh *" > ...yup, there's 87GB of files that I *don't* see under /mnt/xyz. > > It's pretty obvious that the files were intended to live on a remote > fileshare, but got copied in at a point in time when the remote filesystem > wasn't mounted. Now I'm mv(1)'ing 87GB of data back across to a Windows > server across a CIFS mount... time to go for lunch, I guess! > > [image: Avant logo] *Adam Thompson* > Senior Systems Administrator > *voice:* 204.789.9596 x24 | *email:* athompson(a)avant.ca | *web:* avant.ca >

1 0

"Missing" disk space
by Adam Thompson 22 Dec '15

22 Dec '15

Documenting for posterity, and in case anyone else runs into the same problem: I ran into a situation today where df(1) showed me a filesystem that was getting pretty full (109GB used out of 146GB), but when I used du(1) to find the space hogs, it was only able to locate <30GB of data on the partition. (Hint: it was the root partition.) The culprit turned out to be 87GB of files "hidden" underneath mountpoints. If you create /mnt/xyz, copy files into /mnt/xyz/*, then mount another filesystem (local or remote) at /mnt/xyz, the original files are still there, still taking up disk space, but unavailable. Luckily, this was a Linux system, and I was able to get access to those files using a rebind mount: - mkdir /tmp/xyz" - "mount -o rebind /dev/mapper/root_lv /tmp/xyz" - "cd /tmp/xyz/mnt/xyz" - "du -sh *" ...yup, there's 87GB of files that I *don't* see under /mnt/xyz. It's pretty obvious that the files were intended to live on a remote fileshare, but got copied in at a point in time when the remote filesystem wasn't mounted. Now I'm mv(1)'ing 87GB of data back across to a Windows server across a CIFS mount... time to go for lunch, I guess! [image: Avant logo] *Adam Thompson* Senior Systems Administrator *voice:* 204.789.9596 x24 | *email:* athompson(a)avant.ca | *web:* avant.ca

1 0

OpenCSW Solaris packages
by Adam Thompson 18 Dec '15

18 Dec '15

https://www.opencsw.org/

3 9

Map of NSA spying on Canadian data
by Adam Thompson 18 Dec '15

18 Dec '15

http://www.theregister.co.uk/2015/12/17/canadian_live_route_map_shows_nsa_s… Neat... -Adam

1 0