Home of the Squeezebox™ & Transporter® network music players.
Page 1 of 2 12 LastLast
Results 1 to 10 of 17
  1. #1
    Senior Member
    Join Date
    Jul 2008
    Posts
    119

    LMS on Alpine Linux

    I've got:
    Code:
    Logitech Media Server (v7.9.2, 1576909043, Sat Dec 21 07:49:57 CET 2019) perl 5.030001 - aarch64-linux-thread-multi
    Running on a Raspberry Pi 4 with Alpine Linux 3.11.2:
    Code:
    Linux rpi4 5.4.6-0-rpi4 #1-Alpine SMP PREEMPT Tue Dec 24 11:53:25 UTC 2019 aarch64 Linux
    Besides my bumbling (but ultimately successful) install with Fedora 31 on the Pi 3 B+, I don't have much experience with installing LMS other than from the Windows installer or a Linux package of some sort.

    I've read multiple posts on the subject like:

    This guide by Roland0
    This post by Stuarty
    and this succinct one from Paul-

    Paul-'s post doesn't mention needing slimserver-vendor. I guess I'm a little unclear still about the relationship between Perl versions, module versions, the two repos (slimserver-vendor and slimserver), and the various packages.

    For this effort on Alpine, I mostly followed Stuarty's post above, basically:

    - Cloned the slimserver-vendor repo and built the modules directly on the RPi4 with Alpine. This did require some minor edits here and there to get everything to build correctly. I can post my notes if anyone is interested.
    - I also built the other binaries from the slimserver-vendor source (alac, faad, flac, sox, and wvunpack)
    - Downloaded the "Logitech Media Server: Unix Tarball - No CPAN Libraries" archive and moved the modules under arch/5.30/aarch64-linux-thread-multi/ and binaries under Bin.

    That seems to work ok, I can access the web interface, complete the setup, and stream music to a client. I haven't tested much beyond that.

    I'm interested in feedback on whether this is a "good" process for getting a working LMS on an OS that doesn't have a pre-built package? My next step would be to try to get an APKBUILD together for it but I don't really want to go down that road until I have better feel for whether I'm taking the right build approach here or not. I've looked at some of Gentoo's ebuild files for LMS and they are a little scary (to me).

    Based on Roland0's post, I *think* the main con to my current approach is that I'm tying the modules to the Perl version shipped on this release of Alpine which means that if Alpine updates Perl then that might break LMS?
    Last edited by sodface; 2019-12-29 at 07:12.

  2. #2
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    991
    Quote Originally Posted by sodface View Post
    I was going that direction, building slimserver-vendor modules against the current Alpine Perl version and then combining with the unix-noCPAN tar file to get a working installation.
    There likely isn't an elegant solution to the dependency issues without including a specific version of perl in your package. You can either supply binary modules for multiple perl versions (which is what the LMS deb packages do), but you won't be able to create these with a APKBUILD. Or you can provide the binary modules for only one perl version (i.e. the one on the machine where the APKBUILD is done), which means it will not work on different Alpine versions (or even the same Alpine version if perl gets upgraded - not sure if this happens). I don't know if your package can depend on a specific perl version, but even if, it's won't really help, as Alpine seems to remove old packages from the repo, so users couldn't install them anyway.
    Since I'm not familiar with Alpine, I don't know if including perl in your package is acceptable (on the distros I know, it wouldn't be). If it isn't, and Alpine doesn't upgrade perl major versions within a Alpine version, you'd have to provide a different LMS package for each Alpine version. If it does, you're out of luck.

    The old module sources sort of bothered me and then I read this post by you: https://forums.slimdevices.com/showt...ndled-with-LMS
    First, note that there are non-binary modules in lms/CPAN as well (e.g. Algorithm::C3), which are included in the non-CPAN tarballs. I've never bothered to update those.
    fwiw, the last build I did uses the following versions and has run without any obvious issues for ~3 months:
    Code:
    Audio-Cuefile-Parser-0.02.tar.gz	Module-Build-0.4224.tar.gz
    Audio-Scan-1.01.tar.gz			Mozilla-CA-20180117.tar.gz
    Canary-Stability-2012.tar.gz		Net-SSLeay-1.85.tar.gz
    Class-C3-XS-0.14.tar.gz			Sub-Name-0.21.tar.gz
    Class-XSAccessor-1.19.tar.gz		Sub-Uplevel-0.2600.tar.gz
    DBD-SQLite-1.64.tar.gz			Template-Toolkit-2.26.tar.gz
    DBI-1.641.tar.gz			Test-NoWarnings-1.04.tar.gz
    Data-Dump-1.23.tar.gz			Test-Warn-0.32.tar.gz
    Digest-SHA1-2.13.tar.gz			Tree-DAG_Node-1.29.tar.gz
    EV-4.22.tar.gz				Types-Serialiser-1.0.tar.gz
    Encode-Detect-1.01.tar.gz		XML-Parser-2.44.tar.gz
    ExtUtils-CBuilder-0.280224.tar.gz	YAML-LibYAML-0.63.tar.gz
    HTML-Parser-3.72.tar.gz			common-sense-3.74.tar.gz
    HTML-Tagset-3.20.tar.gz			db-5.3.28.tar.xz
    IO-AIO-4.34.tar.gz			expat-2.2.6.tar.bz2
    IO-Interface-1.09.tar.gz		ffmpeg-0.8.4.tar.bz2
    IO-Socket-SSL-2.059.tar.gz		giflib-4.2.3.tar.gz
    Image-Scale-0.14.tar.gz			libexif-0.6.21.tar.bz2
    JSON-XS-3.03.tar.gz			libjpeg-turbo-1.5.3.tar.gz
    Linux-Inotify2-1.22.tar.gz		libmediascan-0.1.tar.gz
    MP3-Cut-Gapless-0.03.tar.gz		libpng-1.6.37.tar.xz

    Which got me second guessing the approach I was taking. I'm thinking about taking a mixed approach and taking the current Alpine Perl packages (many of the modules are in the repos too) building anything that's missing and then bundling everything together as a separate package with the Perl stuff self contained with LMS.
    I don't see any point in this approach - you will need to build the binary modules specifically for LMS anyway and cannot re-use the ones installed. The only advantage is that you could re-use the already downloaded sources in the local cache (provided you have run the official APKBUILDs and do not just use the binary package), but then you would build the modules twice without needing to (and have them installed twice as well). Much easier to list the module sources in the sources for the APKBUILD, then the akp tool will download them for you and you can use the version from the local cache in your build script (I guess - at least, with gentoo's portage, that would work)

    That way the Perl and modules match the Alpine versions as of today but they are self contained and would remain static as Alpine does updates. I could then update the package at a later date if I felt the need.
    There really is no advantage in the LMS CPAN modules matching the Alpine versions unless you plan to actually use the Alpine versions for LMS (which I really do not recommend - the Gentoo ebuild tried that, and it was a disaster -there's a reason it's now a binary package with it's own modules)

    I've looked at some of Gentoo's ebuild files for LMS and they are a little scary (to me).
    The Gentoo ebuilds I'm aware of are either ancient and broken
    or binary packages, which means the ebuild does not include actually building it.

    Some random thoughts:
    Make sure your versions of faad, sox etc. don't conflict with the ones provided by Alpine
    Include your own Slim/Utils/OS/Custom.pm (example) to set pathnames.
    If you need OpenRC scripts, this one for Gentoo should get you started.
    Various SW: Web Interface | Playlist Editor / Generator | Music Classification | Similar Music | Announce | EventTrigger | LMSlib2go | ...
    Various HowTos: build a self-contained LMS | Bluetooth/ALSA | Control LMS with any device | ...

  3. #3
    Senior Member
    Join Date
    Jul 2008
    Posts
    119
    Thanks for the reply Roland0. I'll review this information and hopefully come up with something that makes sense. One follow on question for you, when you say "the last build I did" and then provide the list of source tarballs, do you mean that you used the slimserver-vendor buildme.sh script with those updated sources or did you build them some other way that didn't rely on any lms related scripts?

    Or asked another way, is there some difference between building a module against the OS installed perl version using the LMS buildme.sh script and just using the same module if it's available in the repos?

    See here for example:
    https://pkgs.alpinelinux.org/package...erl-dbd-sqlite

    I'm fairly confident I can at least get a working LMS for myself to use, I'd prefer it be built with newer perl and module versions (just because). I can probably also manually assemble a package for it just to make it easier to install and share. Making an APKBUILD so that the build system can build the package is probably not worth the effort if I could even get it working. Seems a self contained LMS package with its' own perl and modules bundled with it and installed outside of the normal system perl path might be the right way to go.

  4. #4
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    991
    Quote Originally Posted by sodface View Post
    One follow on question for you, when you say "the last build I did" and then provide the list of source tarballs, do you mean that you used the slimserver-vendor buildme.sh script with those updated sources or did you build them some other way that didn't rely on any lms related scripts?
    slimserver-vendor buildme.sh (patched for new versions)

    Or asked another way, is there some difference between building a module against the OS installed perl version using the LMS buildme.sh script and just using the same module if it's available in the repos?
    Yes there is. Take e.g. Image::Scale, which depends on libjpeg-turbo (and other pkgs). The buildme script will build a static version of libjpeg-turbo and then Image::Scale, which will link against this static library (and libjpeg-turbo never gets installed). A system package of Image::Scale will depend on libjpeg-turbo being installed, and Image::Scale will link against the shared library of libjpeg-turbo in /usr/lib.

    I'm fairly confident I can at least get a working LMS for myself to use, I'd prefer it be built with newer perl and module versions (just because).
    There are definitely performance/stability/security improvements with certain upgrades (perl, SQLite, libjpeg, libpng). While we'are at this topic: Check if your CFLAGS include the optimizations for your platform (or at least -O2 -march=native (which may be suboptimal depending on your gcc version's support for your plarform))
    For pi3 / aarch64 I use -march=armv8-a+crc -mtune=cortex-a53 -O2

    I can probably also manually assemble a package for it just to make it easier to install and share. Making an APKBUILD so that the build system can build the package is probably not worth the effort if I could even get it working. Seems a self contained LMS package with its' own perl and modules bundled with it and installed outside of the normal system perl path might be the right way to go.
    Writing the APKBUILD to automate the steps to build/install LMS (d/l sources + support files (init scripts etc.), run buildme.sh, create user, install files etc) wouldn't be that much of an effort if you are exploring how to get it to build/run anyway (it's just a shell script after all). That way, you (or any user, really) could run the apk build locally for your perl/arch (provided they have installed the build env). This would make installing / upgrading / removing) rather simple. You could then make the APKBUILD file available for d/l if there's demand, but not the resulting binary package.
    That being said, I couldn't be bothered to do this for Gentoo myself, so there's that...
    Various SW: Web Interface | Playlist Editor / Generator | Music Classification | Similar Music | Announce | EventTrigger | LMSlib2go | ...
    Various HowTos: build a self-contained LMS | Bluetooth/ALSA | Control LMS with any device | ...

  5. #5
    Senior Member
    Join Date
    Jul 2008
    Posts
    119
    You guys are probably getting tired of these Alpine Linux threads but, I've been working on an armel port (see this thread) and I've got everything built for LMS I believe and now I just need to package it up. I sort of left this thread and Roland0 hanging a couple of months ago and now it's time to revisit it.

    If anyone has any input on how best to package up LMS I'd love to hear it. With this armel port, I think it's pretty safe to just make perl a separate package as there's nobody upstream to update it. So I'm thinking maybe:

    - Perl 5.30 as a separate package (already built and in the repo)
    - LMS modules as a separate package (not sure this makes any sense)
    - LMS openrc scripts as a separate package
    - LMS no CPAN itself as a package

    I guess I'm thinking that with the first three installed, updating just the LMS package could be done more frequently?

    I'm also wondering about file system paths, I've looked at my Fedora install and I feel like things are scattered around a little, probably for good reason, but if anyone has any suggestions on where things should land that would be good too. Thanks.

  6. #6
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,474
    I run LMS from git in /opt/logitechmediaserver and everything stays contained within that folder other than searching for system utilities as long as you set the folder locations when you start it.

    Code:
    /opt/logitechmediaserver/slimserver.pl --prefsdir /opt/logitechmediaserver/prefs --logdir /opt/logitechmediaserver/Logs --cachedir /opt/logitechmediaserver/cache --charset=utf8
    From the server information tab.

    Code:
    Cache Folder
    /opt/logitechmediaserver/cache
    
    Preferences Folder
    /opt/logitechmediaserver/prefs
    
    Plugin Folders
    /opt/logitechmediaserver/cache/InstalledPlugins/Plugins, /opt/logitechmediaserver/Plugins
    
    Helper Applications Folder
    /opt/logitechmediaserver/Bin/i386-linux, /opt/logitechmediaserver/Bin, /usr/local/sbin, /usr/local/bin, /sbin, /bin, /usr/sbin, /usr/bin, /opt/logitechmediaserver/cache/InstalledPlugins/Plugins/CastBridge/Bin, /opt/logitechmediaserver/Plugins/DSDPlayer/Bin/i386-linux, /opt/logitechmediaserver/Plugins/DSDPlayer/Bin, /opt/logitechmediaserver/cache/InstalledPlugins/Plugins/PlayHLS/Bin, /opt/logitechmediaserver/cache/InstalledPlugins/Plugins/ShairTunes2W/Bin, /opt/logitechmediaserver/cache/InstalledPlugins/Plugins/Spotty/Bin/i386-linux, /opt/logitechmediaserver/cache/InstalledPlugins/Plugins/Spotty/Bin, /opt/logitechmediaserver/Plugins/Xplay/Bin
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 1-UE Radio
    Squeezebox client builds donations always appreciated.

  7. #7
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    991
    The method to customize LMS for an unsupported OS platform is described here
    Which type of data should go where in the Linux file hierarchy is described in the Filesystem Hierarchy Standard
    Various SW: Web Interface | Playlist Editor / Generator | Music Classification | Similar Music | Announce | EventTrigger | LMSlib2go | ...
    Various HowTos: build a self-contained LMS | Bluetooth/ALSA | Control LMS with any device | ...

  8. #8
    Senior Member
    Join Date
    Jul 2008
    Posts
    119
    @ralpy, thanks for the input. So are you recommending _not_ creating a package for LMS itself but maybe just the dependencies, like Perl and the openrc scripts? What about the modules?

    Quote Originally Posted by Roland0 View Post
    The method to customize LMS for an unsupported OS platform is described here
    Which type of data should go where in the Linux file hierarchy is described in the Filesystem Hierarchy Standard
    Thanks for the links Roland0, I'm not unfamiliar with the FHS, in fact I was looking at it last night prior to writing the above post and wasn't able to come to a conclusion that I felt confident about. LMS is more a server application (the S in LMS) than an end user application, no? Ralphy uses /opt/logitechmediaserver which sort of makes sense by the FHS:

    /opt is reserved for the installation of add-on application software packages.
    ...
    Programs to be invoked by users must be located in the directory /opt/<package>/bin or under the /opt/<provider> hierarchy. If the package includes UNIX manual pages, they must be located in /opt/<package>/share/man or under the /opt/<provider> hierarchy, and the same substructure as /usr/share/man must be used.
    But I think you could kind of read that to mean that end user applications go under /opt, not necessarily a daemon type of application started by the system at boot. I took a look at apache2 in Alpine thinking it has some similarities as an application, and it's files are mostly in /usr/lib and /usr/sbin.

    The FHS has this to say about /usr/sbin (and sbin generally):
    This directory contains any non-essential binaries used exclusively by the system administrator. System administration programs that are required for system repair, system recovery, mounting /usr, or other essential functions must be placed in /sbin instead.
    ...
    Deciding what things go into "sbin" directories is simple: if a normal (not a system administrator) user will ever run it directly, then it must be placed in one of the "bin" directories. Ordinary users should not have to place any of the sbin directories in their path.
    I wouldn't classify /usr/sbin/httpd as a system administration program and it's probably never run as either a system administrator or a normal user, or at least it drops privileges after it's executed. In other words, I don't see how Alpine packagers determined that Apache2's binaries should live in /usr/sbin if they were following the FHS so either they weren't, or I don't know how to interpret the FHS.

  9. #9
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    991
    Quote Originally Posted by sodface View Post
    I wouldn't classify /usr/sbin/httpd as a system administration program and it's probably never run as either a system administrator or a normal user, or at least it drops privileges after it's executed. In other words, I don't see how Alpine packagers determined that Apache2's binaries should live in /usr/sbin if they were following the FHS so either they weren't, or I don't know how to interpret the FHS.
    It doesn't say "a system administration program", but one "used exclusively by the system administrator", which is true for any server-type application (a regular user is not supposed to e.g. start a database server etc.)
    Also "run as either a system administrator or a normal user, or at least it drops privileges after it's executed" is not relevant - we're not talking about the technical user (e.g. root, ...) a process runs as (which determines privileges etc., and can be different from the user who started it (suid etc.)), but about who (=which role) runs / uses this application.

    Coming back to LMS:
    Packages from aynwhere but the offical repos should never be in /usr, /srv etc.
    The static application files can be either in /opt/ (monolithic, e.q. /opt/lms/lib/{AnyEvent,...}, /opt/lms/slimserver.pl - basically the untarred no-CPAN), or /usr/local/ (split, e.g. /usr/local/share/lms/, /usr/local/bin/slimserver.pl). Personally, I prefer option 1, since it's much simpler to handle.
    Variable files are always in /var (/var/log/logitechmediaserver, /var/lib/logitechmediaserver/cache) (and not in /opt or /usr/local, since these are read-only for applications)
    Config files are either in /etc/logitechmediaserver or /usr/local/etc/logitechmediaserver

    Excerpt from my Config.pm:
    Code:
            } elsif ($dir eq 'prefs') {                                                                                                                                                                          
                                                                                                                                                                                                                 
                    push @dirs, $::prefsdir || "/etc/logitechmediaserver/prefs";                                                                                                                                 
                                                                                                                                                                                                                 
            } elsif ($dir eq 'log') {                                                                                                                                                                            
                                                                                                                                                                                                                 
                    push @dirs, $::logdir || "/var/log/logitechmediaserver";                                                                                                                                     
                                                                                                                                                                                                                 
            } elsif ($dir eq 'cache') {                                                                                                                                                                          
                                                                                                                                                                                                                 
                    push @dirs, $::cachedir || "/var/lib/logitechmediaserver/cache";                                                                                                                             
                                                                                                                                                                                                                 
            }
    Various SW: Web Interface | Playlist Editor / Generator | Music Classification | Similar Music | Announce | EventTrigger | LMSlib2go | ...
    Various HowTos: build a self-contained LMS | Bluetooth/ALSA | Control LMS with any device | ...

  10. #10
    Senior Member
    Join Date
    Jul 2008
    Posts
    119
    Quote Originally Posted by Roland0 View Post
    It doesn't say "a system administration program", but one "used exclusively by the system administrator", which is true for any server-type application (a regular user is not supposed to e.g. start a database server etc.)
    Also "run as either a system administrator or a normal user, or at least it drops privileges after it's executed" is not relevant - we're not talking about the technical user (e.g. root, ...) a process runs as (which determines privileges etc., and can be different from the user who started it (suid etc.)), but about who (=which role) runs / uses this application.
    Point taken, that's not how I read it but I follow your logic and it makes sense.

    Quote Originally Posted by Roland0 View Post
    Coming back to LMS:
    Packages from aynwhere but the offical repos should never be in /usr, /srv etc.
    The static application files can be either in /opt/ (monolithic, e.q. /opt/lms/lib/{AnyEvent,...}, /opt/lms/slimserver.pl - basically the untarred no-CPAN), or /usr/local/ (split, e.g. /usr/local/share/lms/, /usr/local/bin/slimserver.pl). Personally, I prefer option 1, since it's much simpler to handle.
    Variable files are always in /var (/var/log/logitechmediaserver, /var/lib/logitechmediaserver/cache) (and not in /opt or /usr/local, since these are read-only for applications)
    Config files are either in /etc/logitechmediaserver or /usr/local/etc/logitechmediaserver

    Excerpt from my Config.pm
    Thanks for the detail. In option 1, is there a symlink under CPAN/arch pointing to the compiled modules?
    Last edited by sodface; 2020-03-03 at 06:28.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •