BALUG-Talk

balug-talk@lists.balug.org

2 participants
147 discussions

Re: [BALUG-Talk] FHS, ro /usr ?, separate (or not) /boot, etc.
by Michael Paoli 22 Jul '17

22 Jul '17

Moving this (mostly) non-Mailman (notwithstanding some relevant context/ examples) "discussion" to BALUG-Talk - as most of it is not BALUG administrivia (BALUG-Admin) specific, but of more general Linux interest. (FHS, filesystems, security, ...) > From: "Rick Moen" <rick(a)linuxmafia.com> > Subject: Re: [BALUG-Admin] BALUG lists ... blank body with command > in Subject: header, ... > Date: Thu, 20 Jul 2017 12:48:35 -0700 > Quoting Michael Paoli (Michael.Paoli(a)cal.berkeley.edu): > >> originally the files in >> /etc/mailman/en/ >> match those in >> /usr/share/mailman/en/ >> And looks like the bits editable in web GUI default to > > It doesn't help that Mailman uses symplinks for a number of things > criss-crossing between /var/lib/mailman locations and /usr/share/mailman > (I think) ones. Well, as/where "it" does that (or distribution's (e.g. Debian's) modification/installation/configuration of such does so, I think it is a semi-elegant "solution" to a somewhat ugly problem. E.g. per Filesystem Hierarchy Standard (FHS) http://www.pathname.com/fhs/ https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard etc., it's permissible for /usr to be mounted read-only (ro) in "normal" operation (e.g. when not performing administrative actions such as adding/removing/updating software, but including administrative actions such as editing of configurations of installed software, routine changes which the software itself makes, etc.). However, fair bits of software don't follow FHS on that, or didn't in past and there's desire to have backwards compatibility with things being more easily alterable if not physically, at least logically, in their (former) location(s) on/under /usr. So, one quite common way to do that is to create symbolic links from relevant location(s) on /usr to relevant locations where things will be editable (and/or contain variable data), e.g. somewhere under /etc and/or /var (and/or for 3rd party applications, /opt - though better yet, /opt should also be possibly ro (though I don't think FHS goes quite as far as to explicitly state such?), and any otherwise "variable" stuff under /opt ought be symbolic link(s) to elsewhere, e.g. under /var/opt and/or something similar for /etc (e.g. /etc itself, or /etc/opt or the like)). Similar applies to cases where a relatively common binary can be covered by somewhat different (but similar) programs ... and even both may be installed. E.g. update-alternatives(8) and /etc/alternatives. Though that may have first come to Debian (not sure which distribution used it first), I've even see it show up on Fedora and derivatives (Red Hat, CentOS, ...) - though on Fedora and derivatives thereof, I've seen it used on far far far fewer software packages compared to Debian ... but at least that number is greater than zero, and it does exist on Fedora and derivatives thereof (at least last I checked). Anyway, what the alternatives mechanism "solves" is essentially this (notably for those that may not be familiar). Let's see we're on a host, and after having settled the emacs/vi war, everyone wants vi(1) ;-) (okay, theoretical argument). But, alas, some want nvi (which is vi on BSD), and some want vim (which last I was aware, Fedora doesn't even make nvi available!). What if some want *both*, but, well, vi on standard PATH in /bin/ or /usr/bin ... well, it's got to provide one of those (or some reasonable vi-like alternative) ... ought that not be a reasonable matter of system configuration? Well, with alternatives, it is, but ... there's FHS. So, those configurations should be managed ... under /etc. But, what if/when the binaries are properly under /usr/bin? Well, we have, e.g.: $ readlink /usr/bin/vi /etc/alternatives/vi $ readlink /etc/alternatives/vi /usr/bin/nvi $ So those on such a lovely system can be treated to beautiful nvi (which is the vi on BSD systems) by using the command vi (and avoid all the annoyances of vim http://www.rawbw.com/~mp/linux/vim/vim_annoyances.txt ), but heaven forbid, should a user on such system actually want to execute vim (e.g. to redemonstrate its bugs/annoyances), they merely need type vim $ type vim vim is /usr/bin/vim $ readlink /usr/bin/vim /etc/alternatives/vim $ readlink /etc/alternatives/vim /usr/bin/vim.basic $ ls -l /usr/bin/vim.basic -rwxr-xr-x 1 root root 2240936 Mar 9 16:56 /usr/bin/vim.basic $ And the lovely alternatives mechanism also updates related links, so e.g. $ man vi will give what corresponds to /usr/bin/vi So ... a pretty darn good solution to a relatively difficult problem/issue. Some distributions, however decide thou shalt have no choice, and, e.g. provide only and exactly one editor for vi, namely vim and all its annoyances (or on BSD, one gets the lovely nvi for vi, but if one wants to get vim by invoking command vi, there isn't mechanism that puts that in place on the PATH and in standard location for all general users). >> And per FHS, etc., the above typically wouldn't be editable (/usr >> filesystem may be mounted read-only.... > > Well, it's hardly the only offender. I discovered this when I did the > research that produced > http://linuxmafia.com/faq/Admin/linuxmafia.com-backup.html , and > [re-]discovered that Apache httpd's cgi-bin directory is in > /usr/lib/cgi-bin/ Egad, uhm, yeah, some software (notably often "upstream") may still have stuff in/under /usr that ought not be there. Some distributions will choose to alter the software such that the offending stuff is no longer under /usr - which fixes the FHS issue - and if also fixed corresponding changes are made for all related software for that distribution - is then mostly all fine and dandy - *except* it still breaks any backwards compatibility that may be expected - e.g. users might expect the stuff to at least logically appear to be under /usr, likewise software (e.g. random home-grown local script) may have been developed expecting the stuff under /usr - and that script breaks if it's no longer (at least logically) present under /usr where it was and where the script expects it. > I likewise keep /usr normally mounted ro, and likewise use the apt hooks > to autoremount it for package operations -- but live with the fact that > I need to also manually remount /usr to fiddle with cgi-bin scripts. > > SpamAssassin's rulesets and scoring settings in /usr/share/spamassassin > are another example (and I guess I should add that directory to my > backup list). Yes, many examples of stuff that ought not (at least physically) be under /usr, and is generally (FHS) fixed on quality distributions (e.g. Debian) to be FHS compliant, but may provide symbolic links or such on /usr - to allow for compatibility with things/users that may still expect it to appear/function as if it's on /usr - even if it's no longer physically on/under /usr. > I'll admit to getting a bit disenchanted with many of the more-recent > additions to FHS (specifically /media and /srv). I've read the > rationales, and I don't agree that /media is justified in addition to > /mnt. I am now grudgingly reconsidering my reflexive opposition to > /srv, because there's a good case that CGI-BIN scripts should be there > rather than anywhere in /usr, including the '/usr may be ro' one. > Therefore, SpamAssassin rulesets and scoring settings arguably are > better there, too. Well, not sure if I've read the latest FHS (I also miss something that was removed from earlier FHS - and I also continue to use: /var/local/ it answered the question of where variable content local stuff goes, which at least partially answered the question: So, I've got lots and lots of data that needs additional filesystem(s), where ought those be mounted? There doesn't seem to be a fully universal answer for that, and FHS (at least I last read) fails to fully and unambiguously answer that. Well, /usr/local (or beneath that) would be suitable for some stuff, /var/local (at least per earlier FHS) for some other stuff ... bits of FHS and what I'd guestimate for logical extensions ... /etc/local for config of local (not distribution or 3rd party) stuff, /var/opt for variable 3rd party stuff, etc. - anyway, at least something approximating that - but alas I see many (most) sites that don't do it that way, and often, egad, create semi-arbitrary additional mount points right under / <sigh>.) I think /mnt is "nice", but has always been rather limited - as it's just a single mostly guaranteed (normally) available mount point - so mostly useful for a temporary mount location, or when one needs to mount directly under root filesystem and root filesystem is ro (e.g. recovery or maintenance scenario) and there may be no other filesystems mounted, but need a dir to mount something at least temporarily ... oh where oh where? - that's when /mnt is really your friend. So, ... /media, /sys, /srv ... I think things could've gone in better directions. Adding stuff right under / should be done very conservatively/minimally - I think there were probably better solutions for all of those. And I think /sys was (and is) totally unnecessary ... great stuff there, but it should'a gone elsewhere - e.g. /proc/sys. > Any time someone says 'Oh, let's solve this problem by putting it in a > new directory off /', I get cranky and conservative-minded, though. > Which is why I think /sys is regrettable -- even though I've heard how > we haplessly fell into the need for that on Linux systems. > (Essentially, the kernel people made such a dog's breakfast out of /dev > that they had to make a new tree to start over. Nice going, guys.) Whether it was /dev, or /proc, I think at least between *major changes* of Linux kernel versions, those were ample opportunities to clean up and fix (and add new stuff) under /dev and/or /proc - no need to add a whole separate /sys (or geez, at least don't mount it at /sys - why not have it just mounted as /dev/sys or /proc/sys, huh? I mean we have a perfectly good devpts mounted on /dev/pts - why not likewise put sysfs at /proc/sys or /dev/sys ? Ah well. I've got mixed thoughts on /media ... I think it's at least better than /cdrom, but perhaps replacing /cdrom with something a bit more general than /media? E.g. perhaps combining functionality of /mnt and /media somewhere/somehow? I dunno. But yeah, sometime it feels too much like feature creep, with too much stuff being added not quite, but almost willy-nilly, to FHS, with semi-arbitrary new locations. > I actually wanted to consult you on /boot being a separate filesystem. > I've done that since forever, but am acutely aware that the original > rationale no longer applies, that of old BIOSes being unable to branch > from int 13h to disc cylinder locations 1024 and over. > > So, is there a 2017 reason for still having /boot separate? I can think > of scenarios, like you have most of the system on md mirrored partitions > but want your bootloader to be able to run from a pair of ext2 ones on > both drives, _or_ you have most of the system encrypted. Are there > reasons I'm missing? Well ... :-) I think there definitely still are reasons to have /boot as a separate filesystem. Some may not be relevant, or as relevant/significant as before, but I think many of the arguments/advantages of separate /boot still apply. Stuff I'd argue/advocate for separate /boot (I'll skip the counter-arguments): o ro/security( / accident reduction) - a separate /boot can be ro, without necessitating / be ro o faster/safer fsck/recovery - for filesystems/data critical to boot and getting to at least single user mode, within reason, smaller and separate is generally an advantage. Many often lump *lots* into root (/) filesystem and/or it may get rather to quite large, so having a separate /boot can be rather to quite advantageous. o one can be ultra-conservative on the filesystem type for /boot, independent of choice of filesystem type for /. E.g. I think many of my /boot filesystems are still ext2 - exceedingly backwards compatible with most anything that would deal with them or that I might want to have deal with them. And with /boot kept sufficiently small and clean, fsck time for recovery of /boot even if it's just ext2, is still pretty darn quick. Though as I think about it now / nowadays, and think what filesystem type is most widely and thoroughly tested and used, well supported, maintained, and works with pretty much any Linux tools ... might be time by now to advance /boot from ext2 to ext3. For similar I like to not have / be "too big", and like separate /usr, /home, and /var. Same also applies, as feasible, to those filesystems too. o lovely useful tip/"trick" I like and have always done on /boot: $ ls -ld /boot/boot lrwxrwxrwx 1 root root 1 Dec 29 2011 /boot/boot -> . So, bootloader configs and all that, to the paths have a leading /boot, or not? If the path is relative to the root of the filesystem used for boot, and that may be /boot filesystem, or may be / (root) filesystem, do we need to change having / not having that leading /boot in the boot loader configuration bits? No. Any reasonably sane boot loader deals fine with symbolic links. by having the symbolic link I note above, all boot configurations have the /boot prefix, and it doesn't matter if /boot is a separate filesytem or not, or changes back and forth - the logical pathnames all remain prefixed with /boot and the bootloader handled 'em all fine - period. End of all that silliness of whether or not we have a /boot prefix in there - we always do and it always works. o all kinds of stuff one might possibly want for / (root), but that bootloaders at least often can't handle or would prefer the bootloaders generally not deal with that complexity (even if the (claim they) generally can): o encrypted / (root) o md / (root) o LVM / (root) o latest wizbang spiffy/experimental filesystem type for / (root) o two or more of the above ;-) (I'm using at least two of the above on at least one host :-)) o separate /boot leaves open the possibility to do more "interesting" things with / (root) - even in future and if one isn't doing so presently and may not have any immediate or short-term plans to do so. o rather darn easy to get rid of a separate /boot and place it on / (root) - presuming suitable filesytem type, not encrypted, and other similar requirements, but significantly more difficult to later add a separate /boot filesystem - especially if one hasn't saved reasonable space at start of drive, it's a single drive system or that's the only drive that can be reasonably conveniently booted from; drive space is relatively cheap these days - probably good to invest in saving that space up front and separate on the drive - even if one isn't doing a separate /boot filesystem - in case one wants to change it later to separate /boot; to make such transition even easier in future if one isn't doing separate /boot, also create a partition there - even if not at all using it presently. o 1024 cylinder limit? Not much of an issue these days - but might want to still consider it for possibly high levels of backwards compatibility. With much larger drives, there's whole partitioning format issue and UEFI and all that - but that's a whole 'nother set of questions / can of worms. >> I suppose too, I ought set up some user in group (or with access to group) >> list, so that many of the list related commands can be run fine with >> less-than-root privileges - a not otherwise privileged user but also in >> group list would seem optimal - as group list seems to have the permissions >> to do the needed, but would generally lack permissions to muck with stuff it >> ought not (e.g. files owned by list by not writable by group list). >> At least on Debian, of what I've seen so far, looks like all the normally >> needed actions to manage mailman lists, are controlled/accessed via the >> list group. > > Makes sense. FWIW, when I need to muck about with Mailman's files I > _generally_ just su to list. Most particularly, it's really important > to be user 'list' if you regenerate a pipermail archive using > /var/lib/mailman/bin/arch . Otherwise, if you make the mistake of doing > it as root, the ownership of the generated Web archive is wrong and > you'll get 403 errors until you figure that out and fix it. Good points. But I noticed on Debian (presently still oldstable): $ grep '^list:' /etc/passwd list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin $ awk -F: '{if($3==38)print;}' /etc/group list:x:38: $ So ... su - list ain't gonna cut it. 8-O. But I added: $ expand -t 4 < ~root/bin/golist #!/bin/sh cd / && exec perl -e ' ($),$()=(q(38 38),38); ($<,$>)=(38,38); $ENV{HOME}=q(/var/list); exec {bash} (q(/bin/bash)); ' $ :-) It's a start anyway ... I ought add bits on that, to adjust PATH, read list's HOME from getpwent or the like for list's entry, probably even likewise read list's UID and GID similarly. Like I said, it's a start. But also, may want to have two different "list" role accounts, one using list's UID (and GID) - most notably for stuff that will, e.g. create new files/directories., and one that uses list's GID, but unprivileged user, for operations that are essentially read-only. Ought also make that thing entirely perl - it's not like perl lacks a chdir function.

3 4

BALUG-Test list
by Michael Paoli 20 Jul '17

20 Jul '17

The BALUG-Test list has been created (actually it was created a bit earlier, and also slightly mentioned on: http://lists.balug.org/pipermail/balug-announce-balug.org/2017-July/000718.… ). It's up and running on the host where the BALUG lists will be migrated to. Feel free to (at least reasonably) test it - see relevant policy, etc. on the list page itself: https://temp.balug.org/cgi-bin/mailman/listinfo/balug-test Note that the host isn't high bandwidth or especially high reliability, but for the most part it should be up, online, and quite reasonably functional. Certainly feel free to let me know if you see any problems with it. Myself and Rick Moen (Thanks Rick!) are the listadmins on the list. Note that BALUG lists will be moving from lists.balug.org to temp.balug.org - and will eventually resettle back on lists.balug.org after we've fully removed BALUG from all DreamHost.com hosting. Also, at the persent time, on temp.balug.org, with our quite good (but bit aggressive) anti-spam in place: If mailman email command has a blank body (after stripping of images, etc.), the anti-spam will reject it. Work-around is to add the command: end (on a line by itself) to the body of the message. The relevant texts have been adjusted (let me know if I missed any). Also, sometimes email sent may be "greylisted" - so don't always expect that email will instantly be processed - sometimes there may be a delay of a couple minutes or more. If interested, one can also see quite a bit regarding development and testing on the list, most notably on the list itself, the BALUG-Admin list, and also on wiki page (which again is slightly out-of-date). https://temp.balug.org/pipermail/balug-test/ http://lists.balug.org/pipermail/balug-admin-balug.org/ https://www.wiki.balug.org/wiki/doku.php?id=balug:mail_and_lists

1 0

script du jour (.unroll) - "unroll" Apache Include / IncludeOptional
by Michael Paoli 11 Jul '17

11 Jul '17

So ... for an Apache configuration ... with lots of Name-based Virtual Hosts ... it's generally quite convenient to have that complex configuration split into many files, with lots of use of Include and IncludeOptional. That also allows what would otherwise be many repeated common sections, to simply be brought in via Include or IncludeOptional, so they can simply be updated in some common place(s), rather than all the redundant sections scattered throughout some huge monolithic configuration file. But *sometimes* order does or may matter - and that can be a bit trickier to then see/determine exactly what comes first, and also exactly what optional bits are and aren't included. Sometimes it's nice to "pretend", or have the perspective *as if* it were one big monolithic configuration file - even though one really does *not* want to actually have or manage it like that. Well, for the quick-and-dirty, what would it look like if ... if we "unrolled" all those Include and IncludeOptional configuration bits, as if it then looked like one (huge) configuration file? Well, enter the script du jour (at the moment, using it for some troubleshooting - where order does matter): $ expand -t 4 < .unroll #!/bin/sh set -e while read -r line do set -- $line case "$1" in Include) shift cat "$@" | "$0" ;; IncludeOptional) shift 2>>/dev/null cat "$@" | "$0" || : ;; *) echo "$line" ;; esac done $ Could probably be done better / more efficiently, in Perl, or Python ... but for the quick and dirty, that does it quite efficiently and quickly enough. We have, on the host being examined: $ pwd -P /etc/apache2 $ wc -l apache2.conf 221 apache2.conf $ ./.unroll < apache2.conf | wc -l 6068 $ find * -type d -name RCS -prune -o -type f -exec \ > egrep -h '^[ ]*Include(|Optional)[ ]' \{\} \; | > wc -l 163 $

1 0

Wednesday, July 12th: San Francisco Ubuntu Hour and Bay Area Debian Dinner
by Elizabeth K. Joseph 10 Jul '17

10 Jul '17

Hello BALUG friends, Just a quick note to say that after over a year hiatus from both events, we've decided to host a San Francisco Ubuntu Hour synced with the 2nd Wednesday of the month date of the Bay Area Debian Meeting, to offer an evening of Ubuntu and Debian camaraderie! So this Wednesday, July 12th, the plan is as follows: First, from 6-7PM: San Francisco Ubuntu Hour Location: Starbucks, 74 New Montgomery Street Details: http://loco.ubuntu.com/events/ubuntu-california/3581-ubuntu-hour-san-franci… Also on Meetup: https://www.meetup.com/Ubuntu-California/events/241078624/ Then, from 7:10 onward many of us will go to the nearby... Bay Area Debian Dinner Location: Henry's Hunan Restaurant, 110 Natoma St., San Francisco Details: http://bad.debian.net/pipermail/bad/2017-July/003779.html So come out to the Ubuntu Hour or join us for dinner at the Bay Area Debian Meeting, or both! No particular expertise is needed to be welcome, just show up and express interest to share a casual chat with us. We have a lot to talk about since we last met up :) To find us at both events, look for the people in the Linux shirts and the Stretch (purple octopus) stuffed toy, we will have signs up on or near our table as well. Feel free to contact me directly or on list if you have any questions about either event. Hope to see you there! -- Elizabeth Krumbach Joseph || Lyz || pleia2

1 0

Lubuntu 14.04 guest session login failure
by Christian Einfeldt 09 Jul '17

09 Jul '17

Hi, I am experiencing a very strange thing for which there are no ready answers by googling. I am a volunteer for a non-profit which puts GNU-Linux computers in low income shelters. They are stand-alone machines connected directly to the Internet via a hub on a dedicated ethernet cable. The shelters don't want the users to be able to store anything directly to the machine's hard drive. To give them that functionality, we ask them to use the guest session, which wipes out all data by default when the session ends. Right now, however, we are experiencing a failure of logging into the guest session. Normally, you just choose the guest session in the Lubuntu login screen, and hit enter, and it boots up a full guest session. No password is required. Now, when I chose the guest session and hit enter, the system appears to head toward a normal login, but then quickly fails and returns to the login screen. The system's SU admin account is performing normally. To get into the admin account, I just choose it in the login screen, enter the password, and the admin session boots up normally. This whole thing is very strange, and I have never seen anything like it before. We are using 14.04 on 13 machines with identical or similar hardware and are not having any such problems. This email is being written on one of those such machines, and the guest session works just fine. I ran updates on the malfunctioning machines, rebooted, no joy. Thanks very much in advance. -- Christian Einfeldt

6 9

LXDE volume control missing from panel
by Christian Einfeldt 09 Jul '17

09 Jul '17

Hi, I am volunteering to help a low-income shelter in San Francisco. I have donated Lubuntu computers, but the volume control is not appearing on one of the machines. I followed the instructions on line by doing this: - Right click on the panel - choose Add/Remove Panel Items - The Panel Window appears: You will note that Volume Control already is listed on the list of "Currently loaded plugins", but the volume control does not appear on the panel. Here is a shot of my panel: I have tried clicking on the "add" button on the right of the Panel Preferences window above, but doing so only puts another instance of "Volume Control" under the list of "Currently loaded plugins" but the icon does not appear in the panel. Thanks in advance for trying to help! -- Christian Einfeldt

3 2

Farewell BALUG!
by Bill Kendrick 09 May '17

09 May '17

BALUG friends & acquaintances, it's with mixed emotion that I say farewell! My family and I are moving up to Washington state this summer, after ~20 years out here in Davis. We'll be close to our kids' grandparents, finally own our own house, and won't have 105F days during summer! :) I'll be unsubscribing from various local mailing lists soon. I'm sure I'll see at least some of you around online, though. (And nostalgia won't let me unsubscribe from LUGOD's mailing lists. ;) ) -- -bill! Sent from my computer

1 0

(SF) Fwd: [Tech] Digital Inclusion Week on now
by Michael Paoli 09 May '17

09 May '17

Fair bit going on - including evenings and Saturday ----- Forwarded message from grantbow(a)partimus.org ----- Date: Tue, 09 May 2017 12:21:37 +0000 From: "Grant Bowman" <grantbow(a)partimus.org> Subject: [Tech] Digital Inclusion Week on now To: discussion(a)lists.partimus.org, tech(a)lists.partimus.org Fyi http://sfpl.org/digitalinclusionweek If anyone will be attending please let us know. Maybe we fan meet up. Regards, Grant ----- End forwarded message -----

1 0

Linux Users' Group of Davis, May 15: "DockerCon recap"
by nbs 02 May '17

02 May '17

The Linux Users' Group of Davis (LUGOD) will be holding the following meeting: Monday May 15, 2017 7:00pm - 9:00pm Presentation: "DockerCon17 Recap and Highlights" Presented by: Stephen Matthew Helms Description: Docker is an open-source project that automates the deployment of applications inside software containers -- a server virtualization method in which the kernel of an operating system allows the existence of multiple isolated user-space instances, instead of just one. DockerCon, held recently in Austin, Texas, is a "community and container industry conference for makers and operators of next generation distributed apps built with containers ... with talks by practitioners, hands-on labs, an expo hall of Docker ecosystem innovators." This presentation will highlight some of the Linux- and open-source-related topics found at DockerCon 2017. Stephen will also briefly discuss the Docker Community, Mentoring and Higher Ed and Embassador program, and if time permits, audience participation in some demos. This meeting will be held at: Yolo County Public Library, Mary L. Stephens Davis Branch Blanchard Community Meeting Room 315 E 14th Street Davis, CA 95616 For more details on this meeting, visit: http://www.lugod.org/meeting/upcoming/ For maps, directions, public transportation schedules, etc., visit: http://www.lugod.org/meeting/library/ ------------ About LUGOD: ------------ The Linux Users' Group of Davis is a 501(c)7 non-profit organization dedicated to the Linux computer operating system and other Open Source and Free Software. Since 1999, LUGOD has held regular meetings with guest speakers in Davis, California, as well as other events in Davis and the greater Sacramento region. Events are always free and open to the public. You can 'like' LUGOD on Facebook at: https://www.facebook.com/LinuxUsersGroupOfDavis join the LUGOD group on Facebook at: https://www.facebook.com/groups/lugod/ and find us on LinkedIn at: http://www.linkedin.com/groups?gid=35879 Please visit our website for more details: http://www.lugod.org/ -- Bill Kendrick pr(a)lugod.org Public Relations Officer Linux Users' Group of Davis http://www.lugod.org/ (Your address: balug-talk-balug.org(a)lists.balug.org )

1 0

Linux Users' Group of Davis, March 20: "Kodi media player"
by nbs 12 Mar '17

12 Mar '17

The Linux Users' Group of Davis (LUGOD) will be holding the following meeting: Monday March 20, 2017 7:00pm - 9:00pm Presentation: "Kodi media player (formerly XBMC: Xbox Media Center)" Presented by: Ronile Lambert Description: Kodi (formerly known as "XBMC", or "Xbox Media Center") is an award-winning open source media center for playing videos, music, pictures, games, and more. Licensed as free software, under the GNU General Public License (GPL), it runs on Linux, OS X, Windows, iOS, and Android. Kodi features a "10-foot user interface" (that is, a UI suitable for televisions, where the user is 10' away from the screen, and using a hand-held remote control), and can play digital content from local and network storage, as well as streamed from the Internet. It supports live TV, and can act as a Personal Video Recorder (PVR). It supports 'skins', allowing the entire UI to be customized, and 'add-ons' to give Kodi additional functionality (e.g., controlling the lights in your house). Universal Plug and Play (UPnP) support lets Kodi instances stream to each other, and other devices. Along with real remote controls, and iOS and Android remote apps for phones and tablets, Kodi can also be controlled programmatically, via a web interface! Kodi began as XBMC, the Xbox Media Center, for the original Microsoft Xbox game console, but has since been ported to a variety of platforms, and in 2014 the software was renamed to Kodi. A stand-alone Linux distribution "Kodibuntu" (based on Ubuntu) is available, and a number of commercially sold stand-alone devices running XBMC & Kodi have been made. This meeting will be held at: Yolo County Public Library, Mary L. Stephens Davis Branch Blanchard Community Meeting Room 315 E 14th Street Davis, CA 95616 For more details on this meeting, visit: http://www.lugod.org/meeting/ For maps, directions, public transportation schedules, etc., visit: http://www.lugod.org/meeting/library/ ------------ About LUGOD: ------------ The Linux Users' Group of Davis is a 501(c)7 non-profit organization dedicated to the Linux computer operating system and other Open Source and Free Software. Since 1999, LUGOD has held regular meetings with guest speakers in Davis, California, as well as other events in Davis and the greater Sacramento region. Events are always free and open to the public. You can 'like' LUGOD on Facebook at: https://www.facebook.com/LinuxUsersGroupOfDavis join the LUGOD group on Facebook at: https://www.facebook.com/groups/lugod/ and find us on LinkedIn at: http://www.linkedin.com/groups?gid=35879 Please visit our website for more details: http://www.lugod.org/ -- Bill Kendrick pr(a)lugod.org Public Relations Officer Linux Users' Group of Davis http://www.lugod.org/ (Your address: balug-talk-balug.org(a)lists.balug.org )

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
15
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

BALUG-Talk