BALUG-Talk

balug-talk@lists.balug.org

138 discussions

BALUG lists - lists.balug.org is canonical, temp.balug.org also usable to about 2017-11-30
by Michael Paoli 21 Sep '17

21 Sep '17

BALUG lists: lists.balug.org is canonical, temp.balug.org also usable to about 2017-11-30. So ... temp.balug.org was only ever intended to be temporary - for transitional purposes. So, once again, lists.balug.org functions as it did before (and even better) - it's the domain for the list URLs, and list email addresses. To ease transition back to lists.balug.org, temp.balug.org also remains usable and will remain usable until about 2017-11-30. https://lists.balug.org/cgi-bin/mailman/listinfo

1 0

From the 2017-09-19 BALUG.org meeting (references, etc. on some of what was discussed)
by Michael Paoli 20 Sep '17

20 Sep '17

From the 2017-09-19 BALUG.org meeting (references, etc. on some of what was discussed) Some references, on some of the bits mentioned ... BALUG wiki: https://www.wiki.balug.org/wiki It does contain more than just BALUG stuff. Some of the stuff is rather to quite out-of-date, but also, much of it too, is rather to quite current and maintained/updated pretty well. As location that's automagically indexed, I typically start here: https://www.wiki.balug.org/wiki/doku.php?do=index&idx=balug DreamHost.com hosting exodus & email/list migrations, etc.: https://www.wiki.balug.org/wiki/doku.php?id=balug:dreamhost_exodus https://www.wiki.balug.org/wiki/doku.php?id=balug:mail_and_lists Also maintain list of (mostly Linux) ISO images I have: https://www.wiki.balug.org/wiki/doku.php?id=balug:cds_and_images_etc bup: It backs things up I've not tried it, but at least what I saw of it several years ago, looked quite promising, and, at quick search/glance, looks to be reasonably maintained/active/etc.: https://gitlab.com/SjoenH/bup https://groups.google.com/forum/#!forum/bup-list loopback devices losetup(8) (files are /dev/loop*) "loopback" can be confusing, as it's used in quite different ways for very different things in contexts of Linux/Unix. There's networking loopback device/address. SunOS/Solaris also has loopback filesystem mounts ... but that's something quite different - it functions quite like Linux's bind mounts. All not to be confused with Linux loopback devices. At quick peek at man page, looks like encryption bit has been pushed out of loopback devices and losetup, and into dmsetup(8) One can also automagically (de)allocate loop devices with mounts, e.g. one wants to mount a (regular) file, but mount(8) requires a block device. Well, ... # mount [-t type] -o loop[,...] file mount_point The loop option to mount will create loop device and mount that, and will remove the loop device when it's umount(8)ed. It will also show the mount in slightly more human-friendly form if one uses the mount(8) command to display such - as opposed to manually creating the loop device and directly mounting the loop device itself - or likewise cat(1) of /proc/mounts. (mount(8)/mount(2) tracks that additional information in /etc/mtab - which isn't exactly intended to be human readable, but intended to be read/written by mount(8)/mount(2)). Some of the other bits I wasn't thinking of names of off-the-top-of-my-head (often more rolls off the fingertips, than tongue): dmsetup(8) - some more interesting and complex device mapping, notably file(s)/device(s) - or portions thereof, possibly including encryption, RAID, etc. It's lower-level facility used by, e.g.: cryptsetup(8), lvm(8), partx(8), mdadm(8), etc. Most of the time one doesn't use dmsetup(8) - at least directly ... but once in a while one may (e.g. to "repair" something, e.g. a drive with a fair bunch of at least moderately complex setup (e.g. LVM, or LUKS encryption, or both) is connected, mounted, in use ... drive gets powered off or disconnected and then reconnected and powered on again ... cleaning that state up to a point where one can continue and have such mounted again in such a scenario may effectively require some use of dmsetup(8) - and possibly also some "lazy" unmounts (umount -l)), and maybe a bit of rm(1), and stuff like: # echo 1 > /sys/block/sde/device/delete and maybe some bits of rescanning, e.g.: # (>>/dev/null 2>&1 ls -d /sys/class/scsi_host/host*/scan && for tmp in /sys/class/scsi_host/host*/scan; do echo '- - -' > "$tmp"; done) etc. partx(8) Very handy for creating(/removing) partition devices for a partitioned (block) device, but especially where it's such a device where the kernel and udev, etc. wouldn't typically automagically create parition devices. E.g. /dev/sd[a-z]... would generally automagically have device(s) for partitions, but, if, e.g. one has /dev/loop3 as a block device that references a file that's a paritioned disk image, and one wants devices to access those partitions ... Here's example, setting up a paritioned disk image within a file: # mkdir /var/tmp/partx && cd /var/tmp/partx # truncate -s `expr 50 \* 1024 \* 1024` img # losetup --show -f `pwd -P`/img /dev/loop0 # fdisk /dev/loop0 Welcome to fdisk (util-linux 2.25.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Device does not contain a recognized partition table. Created a new DOS disklabel with disk identifier 0xab8c7754. Command (m for help): n Partition type p primary (0 primary, 0 extended, 4 free) e extended (container for logical partitions) Select (default p): p Partition number (1-4, default 1): First sector (2048-102399, default 2048): Last sector, +sectors or +size{K,M,G,T,P} (2048-102399, default 102399): 51198 Created a new partition 1 of type 'Linux' and of size 24 MiB. Command (m for help): n Partition type p primary (1 primary, 0 extended, 3 free) e extended (container for logical partitions) Select (default p): Using default response p. Partition number (2-4, default 2): First sector (51199-102399, default 51200): Last sector, +sectors or +size{K,M,G,T,P} (51200-102399, default 102399): Created a new partition 2 of type 'Linux' and of size 25 MiB. Command (m for help): w The partition table has been altered. Calling ioctl() to re-read partition table. Re-reading the partition table failed.: Invalid argument The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8). # ls /dev/loop0* /dev/loop0 # partx -a /dev/loop0 && ls /dev/loop0?* /dev/loop0p1 /dev/loop0p2 # mkfs -t ext3 /dev/loop0p1 mke2fs 1.42.12 (29-Aug-2014) Discarding device blocks: done Creating filesystem with 24572 1k blocks and 6144 inodes Filesystem UUID: fbf8ed36-25d8-4d91-a62d-080b8b4199f0 Superblock backups stored on blocks: 8193 Allocating group tables: done Writing inode tables: done Creating journal (1024 blocks): done Writing superblocks and filesystem accounting information: done # mkfs -t ext3 /dev/loop0p2 mke2fs 1.42.12 (29-Aug-2014) Discarding device blocks: done Creating filesystem with 25600 1k blocks and 6400 inodes Filesystem UUID: 9485beff-4240-4214-b919-5ea8c3602b64 Superblock backups stored on blocks: 8193, 24577 Allocating group tables: done Writing inode tables: done Creating journal (1024 blocks): done Writing superblocks and filesystem accounting information: done # mkdir loop0p1 loop0p2 # mount /dev/loop0p1 loop0p1 && mount /dev/loop0p2 loop0p2 # df -h loop0p* Filesystem Size Used Avail Use% Mounted on /dev/loop0p1 23M 209K 21M 1% /var/tmp/partx/loop0p1 /dev/loop0p2 24M 316K 22M 2% /var/tmp/partx/loop0p2 # mount | fgrep loop0p /dev/loop0p1 on /var/tmp/partx/loop0p1 type ext3 (rw,relatime,data=ordered) /dev/loop0p2 on /var/tmp/partx/loop0p2 type ext3 (rw,relatime,data=ordered) # ls -ons img 4116 -rw------- 1 0 52428800 Sep 20 08:07 img # umount loop0p2 && umount loop0p1 && rmdir loop0p2 loop0p1 && > partx -d /dev/loop0 && losetup -d /dev/loop0 && rm img && > cd && rmdir /var/tmp/partx # Notice also that the file was sparse - 50MiB of logical space, only about 4.1MiB of physical blocks used. Anyway, stuff like that can be handy for mucking about with a "disk image" that resides in a (file of type ordinary) file. So, for example, one can prepare a disk image within a file, and then blast (dd(1)) it to a USB or SD flash device, or copy image from disk to file, then work with the file copy, etc. https://www.archive.balug.org/2017/2017-09-19/BALUG.org_2017-09-19_meeting.…

1 0

MOZILLA's GnuPG/PGP key-signing session, October 3rd
by acohen36＠sdf.org 16 Aug '17

16 Aug '17

MOZILLA's GnuPG/PGP key-signing session, October 3rd Former subject was the somewhat longer-titled '[sf-lug] [BALUG-Talk] Fwd: GnuPG / PGP key signing party October 3rd 2017' Quoting <Michael.Paoli at cal dot berkeley dot e d U>, at least from [1] and also from [2]: ~~~~~~~~~~~~~~~~~~~~~~ [DO NOT REPLY-ALL UNLESS YOU'RE SUBSCRIBED TO ALL LISTS!] NOTE ALSO THAT appears (free) "ticket" is REQUIRED to attend this event. Passing this along, as it looks like it didn't make it to at least several lists (non-member posting and/or too many recipients): ----- Forwarded message from lhirlimann at mozilla.com ----- Date: Thu, 20 Jul 2017 10:51:18 +0200 From: "Ludovic Hirlimann" <lhirlimann at mozilla.com> Subject: GnuPG / PGP key signing party October 3rd 2017 To: buug at buug.org, Michael.Paoli at cal.berkeley.edu, talk at nblug.org, balug-talk at lists.balug.org, svlug at lists.svlug.org, sf-lug at linuxmafia.com, info at eblug.org, bad at bad.debian.net, penlug-members at new.penlug.org, bale at linuxmafia.com, meyering at fb.com Hello my name is ludovic, I'm a sysadmins at mozilla working remote from europe. I'm organizing a pgp Key signing party in the Mozilla san francisco office (https://wiki.mozilla.org/People:MozSpaces_Guidelines:San_Francisco) on October the 3rd 2017 from 6PM to 8PM. ~~~~~~~~~~~~~~~~~~~~~~ Ah, so a Mozilla employee is remotely organizing a GnuGP/PGP key-signing session happening at one of the parent company's main U.S. West Coast offices. IMHO, the timing of this session is ever-so-slightly suspicious given that it's happening just over one month before the planned release date of Mozilla Firefox's extensions-busting version 57 [3]; intentionally released to cut down the browser usage percentage of Google's Chrome browser [4] as well as possibly that of the open-sourced Chromium browser [5]. One would hope that there will be _no_ data-collection and storage of participants' _personal_ information before/during/following the time of this Mozilla key-signing-only event, and well in advance of the FF57 release date...... >From what I'm seeing now, and FWIW, both the 64-bit open source Brave* browser [6] and the 32-bit open source Palemoon browser [7] will _still_ be supporting many of our most important browser extensions into the near future. *An interesting fact to note about Brave is that their Mission District HQ [8] is ~3/4 hr MUNI busride from Mozilla's SF offence [9] ear Rincon Point. Comments from announcement-forwarder Michael P, from Rick M, and from others are expected and of course welcome :-) -A References ============ [1] linuxmafia.com/pipermail/sf-lug/2017q3/012773.html [2] https://temp.balug.org/pipermail/balug-talk/2017-August/000005.html [3] https://www.cnet.com/special-reports/mozilla-firefox-fights-back-against-go… [4] https://www.google.com/chrome/browser/index.html [5] https://www.chromium.org/Home [6] https://www.brave.com [7] https://www.palemoon.org [8] https://www.brave.com/about/ [9] https://wiki.mozilla.org/People:MozSpaces_Guidelines:San_Francisco

2 1

full raw archive (mbox) files publicly available, ...
by Michael Paoli 13 Aug '17

13 Aug '17

Just so everyone is also aware, BALUG lists are publicly archived (I believe that's always been the case, and is reasonably clear on the lists' pages). Also, on the new infrastructure, the full raw archive (mbox) files are also available. They can be found on the lists' archive pages, the link on each labeled: download the full raw archive Note that the old archives aren't merged in yet, but expecting to have that completed in the near future. Also, planning to make those full raw archive mbox files available via rsync - that will also be more handy/useful/efficient, as some missing bits of the archives get filled in later (don't presume the mbox files are append-only ... though they will generally be append-mostly). Over the years, there have been multiple occasions where DreamHost.com lost some or all of our archives (at least on some of our lists). Still hoping to later reinject and restore that, from other copies we have or may be able to obtain. That also means that anyone has the ability to backup the entire raw mbox archive. :-) Making those raw mbox archives public wasn't even an option with DreamHost.com (at least through current version of MailMan, it's a global option setting, and not per-list. DreamHost.com hosted many lists from many customers, so didn't reasonably have a way to adjust that on a per-customer or per-list basis). Two most important assets of list, are the archives, and the members/roster - with those it's always possible to recreate the list if needed/warranted. Without those, not so easy to infeasible. > From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu> > To: BALUG-Test <balug-test(a)temp.balug.org> > Subject: BALUG-Test: full raw mbox archive publicly available > Date: Tue, 11 Jul 2017 07:34:46 -0700 > And yes, the full raw mbox archive for BALUG-Test > is publicly available: > $ curl -I https://temp.balug.org/pipermail/balug-test.mbox/balug-test.mbox > HTTP/1.1 200 OK > Date: Tue, 11 Jul 2017 14:29:02 GMT > Server: Apache/2.4.10 (Debian) > Last-Modified: Tue, 11 Jul 2017 14:23:34 GMT > ETag: "a046-5540b71d48512" > Accept-Ranges: bytes > Content-Length: 41030 > Content-Type: application/mbox > > $ > Procedure documented on: > https://www.wiki.balug.org/wiki/doku.php?id=balug:mail_and_lists > notably: > o Y full mbox archive publicly available; procedure: > add: > PUBLIC_MBOX = Yes > to file: > /etc/mailman/mm_cfg.py > restart mailman > for existing lists, toggling archive from public to private and > back again seems sufficient to then create the needed link > > Also making it available via public rsync is on the todo list, but > not towards the higher/highest priority bits. > "Not worse than" migration off of DreamHost.com is higher on the priorities. > Additional improvements generally come later.

1 0

Recommendations for email resender/"forwarder"? (infrastructure: Debian oldstable amd64, MTA exim4)
by Michael Paoli 13 Aug '17

13 Aug '17

So, ... I'm looking for recommendations. The basic context: using /etc/aliases (or equivalent) to simply and directly forward/alias email out onto The Internet at large, is in general a bad idea (particularly in the days of spam, and anti-spam, etc., among other factors). Our existing old hosting on DreamHost.com uses a fair bit of that. 8-O Need to migrate that functionality off of DreamHost.com. I'm looking for a way to make that migration that at least partially fixes the issues with such overly simplistic aliases. Notably such "aliased"/forwarded email ought be sent out with appropriate Sender: or similar header(s) (Resent-From: ?) and envelope FROM showing (re)origination from domain of the forwarding host (@balug.org or subdomain thereof). Ideally, a relatively simple near-drop-in replacement that could go into /etc/alises, that would, rather than do overly simple (and problematic) aliases such as: some-alias(a)balug.org: bob(a)example.com jane(a)example.com ... might implement something more like: some-alias(a)balug.org: "|resend bob(a)example.com jane(a)example.com" Also, for these purposes, do not want the complexity of mail lists, e.g. don't need or want subscribe/unsubscribe, archives, etc. At present @balug.org has at least 28 distinct aliases - certainly don't want to manage or have to deal with 28+ additional email lists. The target infrastructure is: Debian oldstable Debian GNU/Linux 8.9 (jessie) x86_64 MTA: exim4 (will get upgraded to stable at some point, but for the short to medium-term future or so, it's oldstable, and need to implement solution on oldstable). Thanks in advance regarding recommendations/pointers. :-)

3 6

Fwd: GnuPG / PGP key signing party October 3rd 2017
by Michael Paoli 12 Aug '17

12 Aug '17

[DO NOT REPLY-ALL UNLESS YOU'RE SUBSCRIBED TO ALL LISTS!] NOTE ALSO THAT appears (free) "ticket" is REQUIRED to attend this event. Passing this along, as it looks like it didn't make it to at least several lists (non-member posting and/or too many recipients): ----- Forwarded message from lhirlimann(a)mozilla.com ----- Date: Thu, 20 Jul 2017 10:51:18 +0200 From: "Ludovic Hirlimann" <lhirlimann(a)mozilla.com> Subject: GnuPG / PGP key signing party October 3rd 2017 To: buug(a)buug.org, Michael.Paoli(a)cal.berkeley.edu, talk(a)nblug.org, balug-talk(a)lists.balug.org, svlug(a)lists.svlug.org, sf-lug(a)linuxmafia.com, info(a)eblug.org, bad(a)bad.debian.net, penlug-members(a)new.penlug.org, bale(a)linuxmafia.com, meyering(a)fb.com Hello my name is ludovic, I'm a sysadmins at mozilla working remote from europe. I'm organizing a pgp Key signing party in the Mozilla san francisco office (https://wiki.mozilla.org/People:MozSpaces_Guidelines:San_Francisco) on October the 3rd 2017 from 6PM to 8PM. For security and assurances reasons I need to count how many people will attend. I'v setup a eventbrite for that at https://www.eventbrite.com/e/pgp-key-signing-party-in-san-francisco-tickets… <http://t.umblr.com/redirect?z=https%3A%2F%2Fwww.eventbrite.com%2Fe%2Fgnupg-…> (please take one ticket if you think about attending - If you change you mind cancel so more people can come). Also it helps for counting pizza as I'm trying to get some pizza while we chat and sign keys. I will use the eventbrite tool to send reminders and I will try to make a list with keys and fingerprint before the event to make things more manageable - if you want to be on that list please send me an eamil with key IDs so I can build it. To make the event more visible I've created a lanyrd entry at : http://lanyrd.com/2017/pgp-key-signing-party-in-san-francisco/ An upcoming event at : https://upcoming.org/event/pgp-key-signing-party-42p3iubxhi feel free to add yourselves on these, but getting a ticket is mandatory so I can manage security on siet and insurances etc .... I will advertise this on twitter and mastodon (I'm @lhirlimann and usul(a)mamot.fr), retweet and boost wanted. Ludovic ps sending this to a lot of people, to get more visibility. Feel free to pass this along to interested parties (eg I was unable to find a live BSD group) ps2 I will also contact people listed on biglumber to have more gpg related people show up. -- :Usul in #moc on irc.mozilla.org Mozilla Operation Center http://www.hirlimann.net/Ludovic/carnet/ ----- End forwarded message -----

1 0

Bit more information on the new hosting, & BALUG-Talk migration
by Michael Paoli 04 Aug '17

04 Aug '17

The BALUG-Talk list migration did go quite smoothly. Still need to migrate the list archives, but will get to that. A couple other bits one might want to be aware of on the new hosting: Also note, with the new infrastructure, notably anti-spam measures and greylisting, postings to the list may not appear quite immediately - especially if one hasn't posted to the list before or in some fair while (or notably from the same SMTP sending IP address before). So one may see an initial delay of a couple minutes up to about five minutes or so (depending upon one's sending MTA) or more. Also, while the site will generally be up, available, and on-line, it's not exactly a high-availability infrastructure - so if at any point it appears to not be available, rest assured we'll take care of it (and any postings sent earlier, will still generally still make it - may just take a bit longer in such circumstances).

1 0

BALUG-Talk list migrating!
by Michael Paoli 04 Aug '17

04 Aug '17

BALUG-Talk list migrating! This should be the last post from the list's old hosting location. The old location of the list (and its archives) should be treated as "read-only" - the "Emergency moderation" is set on the list, and no postings should be approved. Expect some email(s) once the migration has completed. You can also check back later at: http://www.balug.org/#Lists for status, links, etc.

1 0

Re: [BALUG-Talk] Linux Mint 18.2
by acohen36 31 Jul '17

31 Jul '17

Quoting Andrew Lewis (andy at simulsys.demon.co.uk): > Hi Guys, > > I hope you do not mind us reaching out from SOSLUG, the Southend-on-Sea > Linux User Group in England, but I saw your email about Lubuntu? A > couple of us at SOSLUG have installed Linux Mint 18.2 64-bit and it is > a cool user environment, and I recommend you give it a look on a stick? Then quoting Rick Moen <rick at linuxmafia.com> > Hullo, Andrew! Of course we don't mind a bit. Yes, I agree that > Lubuntu is a terrific little distribution, as is LXDE generally. > I'm always on the lookout for nice but relatively compact 'live" > distributions in particular. (We used to call those live-CD, but > the metaphor is perhaps a bit confusing in 2017.) I think Andrew mentioned Linux Mint 18.2 64-bit instead of Lubuntu (with the latter's LXDE) above. FWIW, a cursory review of the site linuxmint.com/release.php?id=29 doesn't yet show an available LXDE version of Linux Mint 18.2, although it _does_ show the "light" Xfce version of the same. Linux Mint 18.2 Xfce (64-bit) is a ~1.5 GB ISO in size, so if anyone wishes to try this, it is probably best to use a USB stick for both 'live'/temporary booting and for installation. Same USB stick requirement for the 64-bit Cinnamon and MATE versions of Linux Mint 18.2, although the sizes of their ISO's are slightly larger than Xfce's, at ~1.6GB -A acohen36(a)sdf.org SDF Public Access UNIX System - http://sdf.org

2 1

Linux Mint 18.2
by Andrew Lewis 29 Jul '17

29 Jul '17

Hi Guys, I hope you do not mind us reaching out from SOSLUG, the Southend-on-Sea Linux User Group in England, but I saw your email about Lubuntu? A couple of us at SOSLUG have installed Linux Mint 18.2 64-bit and it is a cool user environment, and I recommend you give it a look on a stick? We are looking at a number of projects, including music from sensor data from a Raspberry Pi Sense Hat, and machine learning using scikit-learn. We would be happy to share basic data about Raspberry Pi using Raspbian Linux; for example I have a 4-node Beowulf Pi Cluster which runs parallel Python on Open MPI which I can share information about? Anyway, just to say "Hi!", Tally ho! Andrew J Lewis MSc FLS Director www.simulsystemsltd.co.uk Chelmsford, UK. 44-(0)7710 588318 smalllogo

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

BALUG-Talk