BALUG-Talk

balug-talk@lists.balug.org

1 participants
141 discussions

http[s]://{www., }{, ipv[46].}balug.org/{myip, srcip, myconnection, *}
by Michael Paoli 07 Oct '17

07 Oct '17

Not for high-volume use, not a high availability nor high bandwidth service, but ... http[s]://{www,}{,.ipv[46]}.balug.org/{myip,srcip,myconnection,*} Want to know your (Internet) source IP address ... for IPv4?: $ curl https://www.ipv4.balug.org/myip 198.144.194.235 $ IPv6?: $ curl https://www.ipv6.balug.org/myip 2001:470:66:76f::2 $ What about source IP and port, and likewise for target: $ curl https://www.ipv6.balug.org/myconnection 2001:470:66:76f::2 50265 2001:470:1f04:19e::2 443 $ Anyway, (notably not that balug.org is also off of DreamHost.com, yay!) implemented similar for BALUG what I'd earlier implemented for SF-LUG with those URLs. If one uses, e.g.: https://www.balug.org/myip one may connect and see IPv4, or IPv6 IP (server is dual stack). $ wget -4 -q -O - https://www.balug.org/myip 198.144.194.235 $ wget -6 -q -O - https://www.balug.org/myip 2001:470:66:76f::2 $ The URLs with ipv4 or ipv6 in the host (DNS) name are *only* IPv4 or IPv6, respectively. That can be handy when, e.g. one has a client where one can't (feasibly) tell the client to only use IPv4 or IPv6. Can also use http instead of https (and will all the further lack of assurances on http with the traffic then in the clear). And balug ... one less character to type than sf-lug. ;-) references/excerpts: > From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu> > To: SF-LUG <sf-lug(a)linuxmafia.com> > Subject: > http[s]://{www,}{,.ipv[46]}.sf-lug.org/{myip,srcip,myconnection,*} > ... m-net.arbornet.org > Date: Thu, 22 Jun 2017 06:58:06 -0700 > Now also working with https, > and also handy URL portions ending with /myip, /srcip, /myconnection, > e.g.: > $ curl -s https://www.ipv4.sf-lug.org/myip > 99.95.107.156 > $ curl -s https://www.ipv4.sf-lug.org/myconnection > 99.95.107.156 64316 198.144.194.238 443 > $ curl -s https://www.ipv6.sf-lug.org/srcip > 2001:470:66:76f::2 > $ curl -s http://www.ipv6.sf-lug.org/myconnection > 2001:470:66:76f::2 40862 2001:470:1f04:19e::2 80 > $ > (/myip and /srcip are equivalent) > Some of those may be particularly useful when you're behind > layer(s) of NAT/SNAT, and also, as essentially noted earlier, > if/when you want to explicitly check IPv4 or IPv6 - particularly > if you're using a client that one can't (reasonably) specify > which protocol on the client itself (e.g. mobile browser on > "smartphone"). > >> From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu> > To: SF-LUG <sf-lug(a)linuxmafia.com> >> Subject: http://www.ipv4.sf-lug.org/ http://ipv4.sf-lug.org/ >> Date: Sun, 18 Jun 2017 14:16:13 -0700 > >> And for those that may find it useful, >> if/when you want/need to hit only IPv4, I've also added: >> http://www.ipv4.sf-lug.org/ >> http://ipv4.sf-lug.org/ >> With the former of those two being the canonical form. >> >> So long as you don't have need/reason to restrict to IPv4 only, >> should just use the canonical form: >> http://www.sf-lug.org/ >> or >> https://www.sf-lug.org/ >> >> One can also often restrict to just IPv4 or IPv6 with >> the client ... but not all clients offer such an option >> (e.g. dual stack mobile device may not offer such an option). >> >> What about?: >> https://www.ipv4.sf-lug.org/ >> https://ipv4.sf-lug.org/ >> I don't have corresponding cert added yet, but expect >> I'll have that completed before 2016-08-20T01:30:00+0000. >> Until I add such cert, they "work" - notwihstanding cert >> not having those newer names included. >> >> I didn't add similar for .com, as it's non-canonical anyway. >> >>> Date: Tue, 01 Dec 2015 17:33:28 -0800 >>> From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu> >>> To: SF-LUG <sf-lug(a)linuxmafia.com> >>> Subject: [www.]ipv6.sf-lug.{org,com} [Re: SF-LUG & IPv6 :-)] >>> >>> And for those that may be interested, curious, or might find it useful, >>> if one accesses the sf-lug website via any of these DNS names in the URLs: >>> http://www.ipv6.sf-lug.org/ >>> http://ipv6.sf-lug.org/ >>> http://www.ipv6.sf-lug.com/ >>> http://ipv6.sf-lug.com/ >>> One gets IPv6 only access to the site (it won't work if you don't >>> have IPv6). >>> Same content, just alternatives names (with the "ipv6." portion added) >>> to access via IPv6 only if/when one may want to do or test that. >>> If one doesn't include the "ipv6." portion, the site has both IPv6 and >>> IPv4, so one doesn't have to use ipv6 names (unless one wants to exclude >>> IPv4). >>> >>> >>>> From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu> >>>> Subject: SF-LUG & IPv6 :-) >>>> Date: Sat, 28 Nov 2015 11:29:32 -0800 >>> >>>> The SF-LUG websites >>>> http://([www.]sf-lug.{org,com}/ >>>> now also have IPv6. >>>> Do use the DNS names, as not only may IPv6 addresses change, >>>> but the web server also uses virtual name hosting, and presently >>>> hosts more than just >>>> SF-LUG content. >>>> >>>> Note that the list host (linuxmafia.com) does not (yet?) have IPv6. >>>> >>>> Also, many of the BALUG.org sites now have IPv6 (notably BALUG >>>> ancillary sites >>>> (e.g. archive & wiki sites), but not yet [www.]balug.org itself), >>>> but these don't >>>> yet have full chain of IPv6 DNS servers (alas, balug.org hosting >>>> provider has no >>>> IPv6 DNS servers).

1 0

Re: [BALUG-Talk] [BALUG-Admin] balug.org DNS review
by Michael Paoli 02 Oct '17

02 Oct '17

[moving this to BALUG-Talk - as at least my mostly general responses aren't really all that highly BALUG (admin) specific] Thanks for the excellent review! :-) Some comments, etc, in-line below: > From: "Rick Moen" <rick(a)linuxmafia.com> > Subject: [BALUG-Admin] balug.org DNS review > Date: Wed, 27 Sep 2017 09:25:12 -0700 > Just checking on things, in the wake of the departure from Dreamhost. Yea departing DreamHost.com!!! (A.k.a. nightmare host <sigh>). > 1. We have three nameservers. This is in the recommended range, > barely: RFC2182 section 5 recommends at least 3. RFC1912 section 2.8 > recommends no more than 7. > > If we have one or two more friends running auth nameservers, adding them > would be gravy. Or, ... even not bother a friend and ... There are some free/complementary DNS slave services out there for the taking by any and/or all ... most of 'em suck (perhaps some exceptions?) However, probably of note and worthy of consideration ... balug.org has registrar gandi ... gandi offers complimentary DNS slave services. Now, I wouldn't want to be (too) dependent upon any given registrar, but, as far as I'm aware and what I've seen thus far, gandi's DNS complimentary slave service is basically rock solid and good - only minor thing I've noticed is updates - it either ignores them, or takes some modest bit of time to process them. But it does fully respect the TTLs and relevant SOA times, so as far as I'm aware all is fully within required specifications. I do have at least one (other) domain that uses gandi slave DNS for *one* (and only one) of its slave DNS servers ... so again - not too much in the way of dependencies, and sufficiently easy to break free should there ever be need/reason. Another possible freebie worthy of considering - he.net - with account (which BALUG has, and uses for its IPv6 tunnel), complimentary DNS slave services are also offered. They seem to mostly/basically be quite "good", but come with a few caveats of note. They support *most* - but not *all* - RR types. So ... that's potentially an issue. As for updates, same kind of deal as gandi - except I think he.net explicitly ignores update notifications; but again, works fine regarding TTLs and SOA timing values. But a few more caveats for he.net free DNS. The setup is a bit funky - no way to introduce it without some DNS gotchas when being implemented. Notably (at last I futzed with it), one has to put the delegation in place *first* - so there will be some non-zero time when one has lame NS server(s) - basically after they're delegated, but before they pull and serve the zone data - and they won't pull and serve the zone data until their DNS data checks show that they're delegated - kind'a a Catch-22. Also, don't know that one can feasibly do less than *all* of he.net's DNS servers - they give you a set, they expect you to delegate to them. If they find you're not delegated to them, they drop the service. And ... is that an all or nothing? Doesn't seem to be specified in their documentation, so ... results of delegating less than the full set may be unspecified. *Other* than those few significant caveats, as far as I'm aware, their DNS slave service works perfectly fine - I had (maybe still have?) it on some domain(s) I dealt with. May have dropped it due to the particular limitations and such, though. Oh, and one other possible caveat ... been a while since I read their documents ... there *may* be some traffic limit/caveat? ... or maybe not - I don't recall, I'd have to look over their documentation again. Anyway, yes, those (gandi complimentary and he.net free) DNS slave services, have some potential issues/limitations to consider ... but to give 'em credit too, also have some advantages. Notably they are pretty darn high availability. So that's more than many can offer strung at home on the end of a DSL or cable line or such, or even some host - even if it's in a colo or cloud or the like - if it doesn't have a high availability partner. Then again, for the infrastructure much of such DNS supports, particularly high availability on the DNS can be overkill - when all the services themselves may not be that high in reliability/availability. But still - dang important to have good solid DNS ... as when *that* is down solid - clients on The Internet can't in general even find out that what they're trying to get to is up or down or what the status is, and this also tends to cause or further complicate issues with various services (e.g. SMTP, among others). So ... yes, ... adding a reasonably good reliable (needn't be super high on the reliability) DNS server would be a good thing, ... or more than one, up to total count of about 7 (precise maximum that's still optimal also depends upon the length of the domain name and some other DNS data factors ... e.g. optimal maximum for root (.) is a number larger than 7 ... but root domain (.) also has the shortest possible domain name. For domain names that are highly long, optimal maximum may be somewhat lower than 7 ... but 7 is optimal maximum for *most* typical domain names. > 2. No glue records for one nameserver (ns1.linuxmafia.com), because it > is out-of-bailiwick for the .org TLD nameservers. This means queries to > it are just a little slower than to the other two for which glue > information gets supplied. > > If you want to fix that, assign my nameserver IP (198.144.195.186) the > name NS2.BALUG.ORG in the domain record, removing the entry for > NS1.LINUXMAFIA.COM. That fixes the glue records at the parent (.org) zone. > And then don't forget to make the same switch in the in-zone records > served at master nameserver NS1.BALUG.ORG. Yes, thanks, noted ... will probably get around to that (time, priorities, that one is modest work for only slight/teensy gain ... so ... will likely take longer to get to it). > 3. Information leakage. NS1.BALUG.ORG / 198.144.194.238 answers > (correctly) CHAOS class queries about its version. > > :r! dig version.bind txt chaos @NS1.BALUG.ORG +short > "9.9.5-9+deb8u14-Debian" > > It'd be a good idea to turn this off. I like to return amusing lies, > myself. My stanza in /etc/bind/named.conf.options : > > options { > directory "/var/cache/bind"; > version "Shirley, you're joking"; > hostname "ns1.linuxmafia.com"; > //server-id is essentially redundant to hostname, default is none > //server-id none; > auth-nxdomain no; # conform to RFC1035 > allow-recursion { > [redacted] > }; > allow-query { > [redacted] > }; > dnssec-validation yes; > }; Ah yes. :-) "Of course", there's almost always tradeoffs regarding security. E.g. convenience/speed vs. ... well, security and some information not being so convenient/available. As for DNS server identifying its software/version ... what [il]legitimate uses for that? Well, there's negligible legitimate use, so general best practice is to disable that - or put in some bogus or intentionally misleading string. Legitimate uses of it being there? Mostly negligible ... but there are some slight ones. E.g. for local or secured environments/networks, can be useful/convenient. E.g. not much harm/risk exposing it on 127.0.0.1 and ::1. But ... open to The Internet ... makes it easier for bots/attackers to know the specific target software ... and thus more likely to be able to successfully attack. However, even if the information isn't made available, software can be probed/"fingerprinted", so even if the version information is disabled or altered, attackers may still figure out - if not precisely the target version - at least often approximately the target software and approximate version or some version range. So ... it's bit of tradeoff ... make the information (much) less accessible (or not) - and make attacker's challenge some fair bit more difficult (but not hugely more difficult). Oh, I did say some negligible legitimate uses ... even on The Internet - software surveys - those *can* be used for legitimate purposes. Can also be abused - particularly if the data isn't quickly rolled up into the aggregate, but hangs around (or leaks) with specific IPs and corresponding software information, etc. ... and especially if that is leaked or exposed in bulk. I'm also curious - and don't recall - been long time since I read about it ... txt chaos ... that mechanism was put in BIND many many moons ago. Is it entirely (or mostly) unique to BIND? ... in which case even serving up a "dummy" answer would identify it as some flavor of BIND server. Or ... has other DNS server software adopted that same mechanism for reporting version (most notably if it's in as a default - I think most DNS software can do class CHAOS, though probably almost nobody explicitly implements such). Anyway, depending on the various DNS server software behavior - it may be better to, if feasible, disable that response rather than just put in some dummy response. Anyway, ... I'm curious what current best practice is in that regard for DNS servers - and BIND DNS servers. And I don't think I've any issues with, e.g. disabling it. I think thus so far in my life I've used it one to perhaps a few times. It's a "feature" (offering up its software and version information via DNS query) which is of very close to zero legitimate usefulness.

3 16

scheduled sites outage TOMORROW: [*.]balug.org, [*.]sf-lug.{org, com}, ... >=2017-09-26T09-0700-->~=2017-09-26T15-0700
by Michael Paoli 25 Sep '17

25 Sep '17

As mentioned earlier on the BALUG-Admin list https://lists.balug.org/pipermail/balug-admin/2017-September/000910.html we're anticipating a scheduled sites outage tomorrow, sometime between 9:00 AM and approximately 3:00 PM. PDT. details/references: outage window: >=2017-09-26T09:00:00-0700-->~=2017-09-26T15:00:00-0700 reason: scheduled utility power outage site(s): balug.org - everything on/under that domain sf-lug.{org,com} - everything on/under those domains (does NOT include SF-LUG lists (hosted on linuxmafia.com)) mitigations/controls: Don't have operational UPS presently (even if I did, it probably wouldn't suffice for potential duration of outage). The impacted sites mentioned above are on virtual machine. Prior to outage, I'll (live) migrate that virtual machine onto physical machine that should be able to restart okay after drop of and restoration of power, and likewise virtual machine thereupon should automatically be restarted and recover fine too. With journaling filesystems and such, hopefully this will limit the outage to not much longer than the utility power outage itself. Even in "worst case", I expect sometime tomorrow after 3pm, should some manual intervention be needed, to have the sites up later in that day - I'll also have fresh image on another machine that won't be powering up/down with the utility power, so in all cases, the sites either will come back up, or I'll be able to bring it back up without too much difficulty. https://lists.balug.org/pipermail/balug-admin/2017-September/000910.html http://linuxmafia.com/pipermail/sf-lug/2017q3/012832.html > From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu> > To: BALUG-Admin <balug-admin(a)temp.balug.org> > Subject: scheduled sites outage: [*.]balug.org, [*.]sf-lug.org, ... > >=2017-09-26T09-0700-->~=2017-09-26T15-0700 > Date: Thu, 14 Sep 2017 19:36:09 -0700 > There's upcoming scheduled sites outage due to some > scheduled electric utility work. > > Scheduled outage window: >> =2017-09-26T09:00:00-0700-->~=2017-09-26T15:00:00-0700 > > sites impacted: > [*.]balug.org (note that it may or may not impact www.balug.org and > balug.org - depending where they are at that time, but will impact at > least all other *.balug.org sites/domains) > > [*.]sf-lug.{org,com} (note that SF-LUG list isn't impacted) > > To the extent feasible, I'll try to minimize the outage time, but > expect it may minimally be up to fair part of an hour, and > "worst case" might be 6 hours or more (notably also if I can > have things automagically recover easily enough unattended upon power > restoration - or not). > > It's also possible this outage may be delayed or rescheduled (notably > depending what electric utility provider gets up to).

1 0

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

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

BALUG-Talk