July 19, 201015 yr [moved from webGui Design ] After walking through code in /u/l/w/, I see some obvious ways plugins can be hooked in, but the basic question is do you want unRAID to handle presentation of plugins and handoff to the individual plugin when selected in the UI, or do you want unRAID to simply point to and handoff to a plugin manager, that has its own UI and will take care of presentation of plugins to the user? Of course, the later can be one of the former.... so the question is do you want the former at all. The same question will come up with event callouts to plugins.... should unRAID provide the callouts to every plugin, or to a plugin manager that takes care of passing the event callouts to the plugins? Or do plugins hook into the callouts (i.e. the callouts are to a predefined script name and plugins have to add themselves to it... not the way I'd do it but some do). A separate question is installation and updating of plugins, which I see as left to the community to develop a third party plugin manager (TPPM). I also do not see a away to add to the 5 predefined tabs (Main, Settings, Shares, Users, Utils). Fingured it out.... create a .page file containing: Menu="Tasks" Type="xmenu" And that will create a tab with the same name as the .page file I'll throw out the following for discussion: Add a tab "Plugins" that includes a config option to enable or disable plugin processing. Perhaps always scan the plugin .page files, but display the icons for plugins greyed-out if plugins are globally diabled. Optionally consider a "path to plugins" option, so they could be stored other than a fixed location on the flash. Or perhaps allow fully qualified paths in the .page files. Do plugin processing the same as is being done in the webGui (scan the flash config/plugins for .page files) Allow some way for devs to add to the predefined 5 tabs. Perhaps scanning the .page files, and the list of tabs comes from the unique aggregate of menu names used in the .page files. There is no mechanism for scripting of plugins (i.e an init or stop script). This could come from the event callouts, but also could come from additional directives in the .page files. There are benefits to both. If it was done in the .page files, disabling plugins would then give you a "virgin" system on reboot by also disabling callouts to the plugins... so that could be a positive for troubleshooting for Tom (i.e easy way to make sure no plugins are messing with anything when users report a core unRAID problem). I also think there needs to be some smarts to enable/disable individual plugins within unRAID, so if the third-party plugin manager is broken, users have a fallback other than globally disabling all plugins. The third-party plugin manager (TPPM) can use the same mechanism, but I strongly think unRAID should also be able to do it independently. This could be done on the Plugins tab, by a table listing all the plugins found and allowing them to be manipulated individually. So in sum, I suggest - a plugins tab, that includes configuration options to globally disable all plugin support. - includes a path to plugins option, which defaults to the conventional /boot/config/plugins location. - includes a tabular list of all plugins found and info about them, and the ability to manipulate (disable) them. - ability of a dev to add to the predefined list of tabs. - leave installation, updates, and other management of plugins to a TPPM.
July 19, 201015 yr The same question will come up with event callouts to plugins.... should unRAID provide the callouts to every plugin, or to a plugin manager that takes care of passing the event callouts to the plugins? Or do plugins hook into the callouts (i.e. the callouts are to a predefined script name and plugins have to add themselves to it... not the way I'd do it but some do). We've gotten pretty far without any formal support of Plugins. I would prefer not to be adding/removing lines to predefined call out scripts. Instead, I would prefer the callout or "event" scripts to read a directory of plugin/installed scripts. How the unix environment does it is fine and not overly complex. Each plugin can be designed to source a basic config file that has definitions for it. I.E. Should it run, where it's files exists. Put a file named a certain way in a runlevel directory and it will get run when that event occurs. This is how Thecus does it. We've had many conversations about events and part of this discussion needs to be the list of events that occur and where we want to hook in. There was mention a while ago about an http call to "register" your plugin into the event list. I prefer installing a script into a event level directory. From what I can see, the minimal Event Levels needed. 1. Before the array is started for the "first time". After boot. 2. After the array is started. 3. Before the array is stopped. Right now we have #1 from the go script, but a formal specification would be better. 2 is achieved by polling mdcmd or some dev or some other method. 3 is not really handled correctly. the powerdown package simply hooks itself into the rc.shutdown script and hopes to achieve a more graceful shutdown by doing rudimentary cleanup. I'm not going to get into the presentation of them right now as there seem to be a number of options available. In summary, Also up for discussion is the agreement of events and how we're going to run/trigger them.
July 19, 201015 yr Author I would prefer not to be adding/removing lines to predefined call out scripts. I agree. But that means the script has to have more intelligence in it. Not necessarily a lot, but even just iterating over files flagged as executable is more smarts than just a single script call. Instead, I would prefer the callout or "event" scripts to read a directory of plugin/installed scripts. I agree, with the caveat that unRAID should have an ability -- at a minimum -- for a user to disable all plugins that would also disable all callouts to plugins. part of this discussion needs to be the list of events that occur and where we want to hook in. Agreed. You've identified the bare minimum, and I also agree that the go script is not the place to achieve #1. I also perceive of things other than standard "plugins" that will want to use the callouts, so they shouldn't be married to the plugin arch. Some of the alternatives are: -- scanning a plugin dir for +x scripts of a particular name. -- scanning a plugin dir and subdirs for +x scripts of a particular name. -- scanning a plugin dir for a subdir of a particluar name (ie. start, started, stopping) and running +x scripts in that dir. -- scanning a plugin dir for .page files, getting script names from there and running them -- scanning a plugin dir and subdirs for +x scripts of a particular name However, I expect the plugin root (e.g. /boot/config/plugins) will have all the .page files, and each plugin will live either in the plugin root (particularly simple plugins) or in its own home dir under the plugin root. I would suggest that any plugin that wants to act on script callouts be required to create its own home under the plugin root, and unRAID simply scan all the subdirs under the plugin root. The advantage is that the plugin home dir is self contained. For example: /config/plugins/xyz.page /config/plugins/xyz/xyz.php /config/plugins/xyz/array_start.sh /config/plugins/xyz/array_started.sh /config/plugins/xyz/array_stop.sh This would all be independent of unRAID script callouts that are independent of the plugin architecture, which could be: /boot/config/array_start.sh /boot/config/array_started.sh /boot/config/array_stop.sh Of course, the last three callouts could be used to invoke a script that invokes the plugin scripts ... but I would not do that, as it makes it harder if you want to do a master disable of all plugins (i.e. a unRAID safe mode) as you either need more smarts in the scripts, or you have to disable all the scripts, instead of just the plugin scripts.
July 19, 201015 yr In thinking out loud..... unRAID should have an ability -- at a minimum -- for a user to disable all plugins that would also disable all callouts to plugins. Without a doubt. Disable all or individually. What I would add and require for each event/rc script to source a main plugin.cfg file and then source it's own name.cfg in the config or the plugin directory (I'm open there). In the sourced config you would have VAR=VALUE and then use some of these variables to determine if you should run or not. This would control if a plugin is enabled or disabled. This is how RHEL operates for some of it's control mechanisms. It's also easy enough to operate with sed scripts. I'm sure there are some PHP libraries to manipulate the .cfg/.conf VAR=VALUE files safely. I have some C programs that do it if need be. (That's for the front end). I like the idea of consolidated management. array_start.sh array_stop.sh, etc, etc. could get unwieldy after a while. If we provide a template of an event script, then people just need to fill in the blanks. the /etc/rc.d/rc.samba is a simple enough place to begin. -- scanning a plugin dir for a subdir of a particluar name (ie. start, started, stopping) and running +x scripts in that dir. This seems to be closer to a unix rc environment, however, I also think there may be too many names or subdirectories. Is it easier to operate on one resource control script or a few resource control scripts to manage an event? The closer it is to basic administration methods, the easier it will be for new comers to feel at home. So... do we mimic an rc.d like structure of named event directories as a sysv unix environment would. Or do like slackware does with a master rc.d directory and rc.plugin name. or just look for one rc.plugin name and use the first argument to control what it's doing. I.E. Each plugin control script would have to adhere to basic standards. Parm 1 is the event. It either supports it or it doesn't and exits gracefully. I'm not fond of start/started/stop. What about boot/start/stop boot = first startup of environment after boot. before array is active. start = start block of plugin after array is active stop = stop block of plugin when array is going to be stopped. we could have a shutdown block. I'm not sure that's needed. unless you want to copy something to flash when you know you are going to be rebooted. So this gives boot = install environment & cached etc files from flash. start = starts package/environment/plugin stop = stops package/environment/plugin shutdown = save anything on root ram because it will not survive. However, I expect the plugin root (e.g. /boot/config/plugins) will have all the .page files, and each plugin will live either in the plugin root (particularly simple plugins) or in its own home dir under the plugin root. I would suggest that any plugin that wants to act on script callouts be required to create its own home under the plugin root, and unRAID simply scan all the subdirs under the plugin root. The advantage is that the plugin home dir is self contained. I agree with this idea. (thumbs up ) Just thinking out loud here, lots of cool suggestions.
July 20, 201015 yr One rc. script, similar to how Slackware does it is easiest for all, especially since it will mirror how Slackware itself works. "boot", "start", "stop", "shutdown" works for me. Might want to permit others.. ("restart", "status" ) as needed to assist in maintenance. I see that the current unRAID main page now provides real-time updates of the steps as it stops the array. Try this to see it in action: log in via telnet cd /mnt/disk1 Then, use the management web-page to "Stop" the array. It will sit there adding "Attempting to un-mount" to the window, again, and again. (until you type: cd /boot) I'd like to take advantage of that feature of real-time-status to send start-up/shut-down messages back to the user when there is a need, or when a plug-in cannot be started, or stopped. With that in mind, the stdout and stderr output of an invoked rc. script should end up in a specific spot for capture by the unRAID web front-end. (A method to communicate the successful start/stop status of a plug-in to the user.) Joe L.
July 20, 201015 yr Author I'm sure there are some PHP libraries to manipulate the .cfg/.conf VAR=VALUE files safely. Yup, php has a built-in parser for that. I like the idea of consolidated management. array_start.sh array_stop.sh, etc, etc. could get unwieldy after a while. Consolidated or separate files makes no difference to me.... but then the +x flag is all or nothing. I.E. Each plugin control script would have to adhere to basic standards. Parm 1 is the event. It either supports it or it doesn't and exits gracefully. Either have to have standard file names for each event, or a standard script name (or a standard parameter in the .page file providing the script name) with standard 1st parameter. I like: boot (server is up and ready for login), start (array has started and is online (i.e. after array start)) stop (array is going to stop (i.e. before array begins stopping process)) shutdown (server is going to shutdown/reboot) Of course, any plugin could have others that it uses for its own use. The controling script that calls the plugin scripts could of course capture any output from the plugin scripts, and report it back.
July 20, 201015 yr Author One thing I just realized ... the "boot" code can't be called by emhttp, unless you are willing to wait until emhttp is first invoked.... and it is subject to being called more than once if emhttp is killed and restarted. I would suggest going with a standard filename, so the Slackware rc.d scripts (or the go script called from Slackware rc.d startup) can call it independent of emhttp.
July 20, 201015 yr One thing I just realized ... the "boot" code can't be called by emhttp, unless you are willing to wait until emhttp is first invoked.... and it is subject to being called more than once if emhttp is killed and restarted. I would suggest going with a standard filename, so the Slackware rc.d scripts (or the go script called from Slackware rc.d startup) can call it independent of emhttp. I washed some dishes and gave it some thought. >> The "boot" code can't be called by emhttp, unless you are willing to wait until emhttp is first invoked.... This is a side effect of yeilding control over to emhttp. I don't see it as a negative. my thought is to have one path of code controlled by one process configured the same way for each new plugin subsystem. If we have to go back to the go script methodology for some of the triggering it sort of dilutes a protocol. >> it is subject to being called more than once if emhttp is killed and restarted. This is also a side effect of yielding control to a new protocol/methodology. Let's consider. what is the side effect of running an rc boot block more then once? What would be in the boot(init) block that would break something if it ran more then once? I see the boot(init) block a method of installing packages, copying files from flash to etc. If something absolutely could not run more then once in the boot block then using the /var/lock/subsys method like redhat might be in order. As for emhttp being killed and restarted. if this happens start may be called again too. I don't see worrying about emhttp being killed and restarted as a normal situation and in effect. I would not worry about it as much. As mentioned start would be called multiple times too. Killing and restarting emhttp is be a protocol violation, in effect, something that should not be done on a normal basis anyway. Now, emhttp dieing and having to restart it to shutdown properly could be an issue, then the start scripts will run also. This is where the /var/lock/subsys methodology comes in. This is something in place in some distro's and I think it could be reviewed. I don't want basic events to be come too complex past basic runlevel methodology. We have boot level events from the go script. We have shutdown level events from the /etc/rc.d/rc.local_shutdown script. I've been working behind the scene on rc.unRAID to use a directory for shutdown events. I stopped because it was under code review and it's so close to the beta 5.0. Having emhttp do callouts at each of the 4 runlevels without worrying significantly about the details outside of emhttp is my thought process so far.
July 20, 201015 yr "boot", "start", "stop", "shutdown" works for me. Might want to permit others.. ("restart", "status" ) as needed to assist in maintenance. restart/status are almost always there depending on complexity or simplicity. Requiring them would just be something to add to the api/protocol. Restart calls the named script with stop and start. Easy enough. Status is depending on what the plugin deems is appropriate, but should be something usefull for emhttp or a plugin to determine what is going on. I'd like to take advantage of that feature of real-time-status to send start-up/shut-down messages back to the user when there is a need, or when a plug-in cannot be started, or stopped. With that in mind, the stdout and stderr output of an invoked rc. script should end up in a specific spot for capture by the unRAID web front-end. (A method to communicate the successful start/stop status of a plug-in to the user.) Entirely possible. Where do we capture? I would do it into syslog. The front end can always query something out of syslog or stdout. Another idea is having the front end run the called script. Capturing stdout/stderr as it is occurring. This then gets sent to syslog for archiving and since the message has already been captured by the calling program via select, it can be displayed on the front end as it is occurring. A realtime syslog viewer plugin could be used too. I've seen this before. Even for irc. yep a browser was capable of realtime messages as they occurred. This might be getting too far ahead though.
July 20, 201015 yr Author Having emhttp do callouts at each of the 4 runlevels without worrying significantly about the details outside of emhttp is my thought process so far. I'll buy that.
July 20, 201015 yr Author Entirely possible. Where do we capture? Since (at least the way I see it) emhttp will be iterating over the plugins, it could report the output to the browser at the end of each one, as well as write to the syslog. Of course, devs can have their scripts write to the log too. I see no harm is including a "status" command as standard. For a plugin where there is no real "status" relevance, it can report just "installed" where another one may have several different statuses.
July 20, 201015 yr Author Figured out how to add new tabs: Create a .page file containing: Menu="Tasks" Type="xmenu" And that will create a tab with the same name as the .page file
July 20, 201015 yr Figured out how to add new tabs: Create a .page file containing: Menu="Tasks" Type="xmenu" And that will create a tab with the same name as the .page file Kudos!
July 20, 201015 yr One rc. script, similar to how Slackware does it is easiest for all, especially since it will mirror how Slackware itself works. "boot", "start", "stop", "shutdown" works for me. Might want to permit others.. ("restart", "status" ) as needed to assist in maintenance. I see that the current unRAID main page now provides real-time updates of the steps as it stops the array. Try this to see it in action: log in via telnet cd /mnt/disk1 Then, use the management web-page to "Stop" the array. It will sit there adding "Attempting to un-mount" to the window, again, and again. (until you type: cd /boot) I'd like to take advantage of that feature of real-time-status to send start-up/shut-down messages back to the user when there is a need, or when a plug-in cannot be started, or stopped. With that in mind, the stdout and stderr output of an invoked rc. script should end up in a specific spot for capture by the unRAID web front-end. (A method to communicate the successful start/stop status of a plug-in to the user.) Joe L. Yes that 'progress' iframe at the bottom of the screen is meant to display the output of a script/program. In the case of array start/stop you are seeing the output generated by emhttp as it calls an internal 'logEvent()' function. This function will be fleshed out to call corresponding plugin event scripts. I like how unMenu handles plugins/packages & I think I'd like to adapt some of those ideas. My current thinking is this: - A plugin directory that consists of a series of plugin 'tgz' files. Ideally these should be slackware 'makepkg' files. These files will be 'installed' using slack's 'installpkg' command either within the 'go' script, or by emhttp just before it starts up. - When a plugin package gets installed, what happens is that it's contents get copied to the directories indicated in the package. There is also an option to invoke an install script as the last step. - In addition to a plugin repository, there would be a plugin configuration file directory. These files are in 'ini file' format. The install script of a plugin would look to see if the ini file exists, and if so, don't overwrite, if not, create it. - At some point in emhttp startup, the plugin config directory would be scanned. There would be known variables in the config files that instruct emhttp how to do things like enable/disable the plugin, run installation scripts, etc. - Another directory would be a plugin 'event' directory. During plugin installation, any event scripts needed by the plugin would be installed. For example, if plugin 'myplugin' needed a script to be called upon array start, it would put a script in the 'event' directory called 'myplugin.array_start' (or maybe 'array_start.myplugin?). When any type of event happens inside emhttp, it would scan the 'event' directory looking for corresponding plugin scripts to call for that event. As for the UI... the plugin install would create the necessary .page and .php files (plus any other needed) in the /usr/local/webgui directory. The template system works by scanning this directory with every page lookup, so no other action needs to be take to 'register' the plugin other than simply creating those files. The intent also is that the plugin php file will control the UI, though the goal is to create a standard set of divisions and styles so that the UI has a consistent look and feel across all plugins.
July 20, 201015 yr - When a plugin package gets installed, what happens is that it's contents get copied to the directories indicated in the package. There is also an option to invoke an install script as the last step. - In addition to a plugin repository, there would be a plugin configuration file directory. These files are in 'ini file' format. The install script of a plugin would look to see if the ini file exists, and if so, don't overwrite, if not, create it. many slackware packages use a block of code in the install.sh scripts (doinst). config() { NEW="$1" OLD="`dirname $NEW`/`basename $NEW .new`" # If there's no config file by that name, mv it over: if [ ! -r $OLD ]; then mv $NEW $OLD elif [ "`cat $OLD | md5sum`" = "`cat $NEW | md5sum`" ]; then # toss the redundant copy rm $NEW fi # Otherwise, we leave the .new copy for the admin to consider... } for i in config.new do config etc/$i; done In addition I add some thing like this to allow specification of Variables on the installpkg line to modify internal variable defaults in the script. if [ ! -z "${LOGDIR}" ];then sed --in-place=.bak -e "s/LOGDIR=.*/LOGDIR=${LOGDIR}/g" ${RCFILE} fi
July 20, 201015 yr Author - A plugin [repository] that consists of a series of plugin 'tgz' files. Ideally these should be slackware 'makepkg' files. These files will be 'installed' using slack's 'installpkg' command either within the 'go' script, or by emhttp just before it starts up. I suggest the repository for where the .tgz package files are should be configurable in the unRAID UI so it can be on a disk outside the array... or a different flash.... otherwise folks who bought small flash drives will run out of space, not to mention some flash drives are dog-slow and it slows down booting. At the very least, you need to be able to disable all plugins in the unRAID UI for troubleshooting, and that should include not running installpkg on the .tgz files in the repository. I also see a problem with this with enabling/disabling individual plugins. The .ini files need to be read first, so decisions to run installpkg or not can be made.... but if you just dropped a new .tgz file into the repository, there will be no .ini file yet. Perhaps do it with the +x, but then the enabled/disabled directive can be out of sync if you use both +x and the .ini file. There is also an issue of which .ini belongs to which .tgz. Also, how is a package manager going to work if people can manually drip a .tgz package file into the repository? Should the repository be rigidly managed and not permit dropping outside the oversight of the manager? You also have an issue with multiple versions of a .tgz package since the convention of Slackware packages is to have unique names based on the version. This could be made the responsibility of a package manager to take care of, but that's a ways off. I need to think about this a lot more. The more I think about it the more I am seeing problems from multiple versions of the same package file. I think we may want to consider making a change to the Slackware standard package file, to include some additional info that unRAID can use. Either in the file naming conventions or with an unraid.info file added to the root of the .tgz file... something. Perhaps even add guids. Conceptually, you have to decide where you start the thread that is a plugin. Starting with the .tgz file in the repository makes sense, but it has to be thought out. If we go with the Slackware package-file naming convention, you can parse the file name: <application name>-<version>-<platform>-<identifier> Then the .ini file has to be matched based on <application name> and the package manager also works off of <package name>. A package manager can also handle this and detect multiple packages of the same application, and manually dropped packages can be handled too. Of course, nothing prevents also adopting something like an unraid.info file added to a package file, or some text added to the slack-desc file in the package, that can provide additional info about an unraid specific package, but in the absence of an unraid.info file, a standard unmodified Slackware package can work. - At some point in emhttp startup, the plugin config directory would be scanned. There would be known variables in the config files that instruct emhttp how to do things like enable/disable the plugin, run installation scripts, etc. - Another directory would be a plugin 'event' directory. During plugin installation, any event scripts needed by the plugin would be installed. For example, if plugin 'myplugin' needed a script to be called upon array start, it would put a script in the 'event' directory called 'myplugin.array_start' (or maybe 'array_start.myplugin?). When any type of event happens inside emhttp, it would scan the 'event' directory looking for corresponding plugin scripts to call for that event. I would favor a more self-contained layout, where all the files related to a plugin are within its own home directory. In addition to a plugin repository, there would be a plugin configuration file directory. These files are in 'ini file' format. The install script of a plugin would look to see if the ini file exists, and if so, don't overwrite, if not, create it. I see this a the most important part to discuss. I would not refer to these as "configuration" files, because each plugin may have other "configuration" files that configure the operation of the plugin. I think these are better described as just INI files used by unRAID to initialize the plugin. I like ini layouts, and php parses them into an array easily. Rather than have the events directory and multiple scripts, possible name collisions, etc., I would like the ini file to have a directive like: home=<path> ; either a relative path or a fully-qualified path for that plugin's home dir control=<script name> ; script name (relative to home or a fully-qualified path) that emhttp will call with the 1st parameter set to boot, start, stop, etc.
July 20, 201015 yr I suggest the repository for where the .tgz package files are should be configurable in the unRAID UI so it can be on a disk outside the array... or a different flash.... otherwise folks who bought small flash drives will run out of space, not to mention some flash drives are dog-slow and it slows down booting. We have a condition here where devices outside the array somehow need to be mounted. At the very least, you need to be able to disable all plugins in the unRAID UI for troubleshooting, and that should include not running installpkg on the .tgz files in the repository. Agreed, also, purko and I came up with the emergency and/or safe option on the syslinux boot prompt from the go script. I also see a problem with this with enabling/disabling individual plugins. The .ini files need to be read first, so decisions to run installpkg or not can be made.... but if you just dropped a new .tgz file into the repository, there will be no .ini file yet. Perhaps do it with the +x, but then the enabled/disabled directive can be out of sync if you use both +x and the .ini file. I would not use +x on a tgz file. Use read permissions at some level if you want to prevent yourself from processing it. Then do a test on that permission bit. not +x or -x. There is also an issue of which .ini belongs to which .tgz. Maybe the .ini file is named as the package without version. Inside the ini file is the name of the actual slackware package file. Also, how is a package manager going to work if people can manually drip a .tgz package file into the repository? Should the repository be rigidly managed and not permit dropping outside the oversight of the manager? Packages in the repository without ini files are installed at boot and would lack individual management. (sort of how it is now). Packages rarely do anything other the install. Packages with .ini files have all the proper functionality with individual management (like how unmenu does it). You also have an issue with multiple versions of a .tgz package since the convention of Slackware packages is to have unique names based on the version. This could be made the responsibility of a package manager to take care of, but that's a ways off. I need to think about this a lot more. The more I think about it the more I am seeing problems from multiple versions of the same package file. I think we may want to consider making a change to the Slackware standard package file, to include some additional info that unRAID can use. Either in the file naming conventions or with an unraid.info file added to the root of the .tgz file... something. Perhaps even add guids. We have not had this problem now. There is good communication here and I would surmise there would be good communication at some unRAID plugin repository. if packages are sorted by name, would the newer ones be installed after, thus overwriting anything that could be an issue? This quickly becomes complicated. We need to consider, if the .ini file is the definition of the plugin, then it has the version information in it. One .ini file without the version just the stub name of the package, Inside the .ini are the specifics of where to get the file, what version, subordinate install commands, required packages, There's no law that says the ini cannot be included in the package. The only protocol specific is, if it is in the package, it cannot overwrite an existing .ini file. It uses the logic above to add a .new or have the user rename the .old. Yet I see us as creating the .ini file first. Who knows, through some browser tool at the plugin repository. Before this starts getting really complex, Is it possible to do the 4 proposed event callouts? Even if the event callout scripts are super basic and just turn around calling logger and put a message into syslog. If not, can a message be put in syslog of when these proposed events occur? I bet if this were in the framework, it would provide the fodder to work with and fuel testing in various ways.
July 20, 201015 yr Author Just some random thoughts... There are a lot of good packages already out there, and I'd like them to be able to be utilized smoothly w/o having to alter them. I want a package manager to be able to work relying on just native files. I.e., a stock unRAID system that has some packages already dropped in manually, if you add the package manager later, it will work, and it will work if packages are added manually in the future. There are some packages, like bwm-ng, that have a dash in the appname. So the parse has to look for a digit after the dash to parse off the appname. Not hard, but it has to be accounted for. Sorting by filename will not always give you the latest last. Consider: MyApp-0.3.2-i486-bubba.tgz MyApp-0.3.12-i486-bubba.tgz Yes, devices outside the array have to be mounted. Perhaps I was being overly cautious, as the person capable to mount devices before emhttp loads are also likely to be able to symlink to them from the flash, so that's solved. I remember the safe mode using the syslinux options, and that should be incorporated too, for the times when you get an abend (good Novell term) during the startup process so you can't get to the UI.... but I'd still like to see it in the UI. As for the +x, I agree it is a kludge, but I've used it successfully. How about change the filename from MyApp-0.1.2-i486.tgz to MyApp-0.1.2-i486.tgz.disabled Maybe the .ini file is named as the package without version. Inside the ini file is the name of the actual slackware package file. That's what I originally had in mind, but then you have a chicken-and-egg thing for stock Slackware packages. I want to be able to handle plain Slackware packages, and prevent orphans. To me, there needs to be a 3-way ability to match 1) an ini to a package (easy since the ini can contain the name of its associated package); 2) match a package to an ini trickier, but doable through iteration); and 3) match to package files as different versions of the same application (much trickier, but critical IMHO). All three are simplified if we use the convention of the filenames of the .tgx and associated .ini file based on the <appname>-<digit>
July 20, 201015 yr As for the +x, I agree it is a kludge, but I've used it successfully. How about change the filename from MyApp-0.1.2-i486.tgz to MyApp-0.1.2-i486.tgz.disabled Ahh yes, much better. I usually move them to some .bak or bak directory. but this works just as well and it's very clear that it is disabled.
July 20, 201015 yr Author Ahh yes, much better. I usually move them to some .bak or bak directory. but this works just as well and it's very clear that it is disabled. And an "added later" package manager can figure it out, as well as scripts that are not part of the package manager.... no need to consult a .ini file.
July 20, 201015 yr Author So I’m feeling the love for this: /boot/packages – a package repository for .tgz package files - disabled packages have “.disabled” appended to the file name - <appname>-<version>-<whatever> naming scheme At startup, either the unRAID server itself, or an early step in emhttp runs installpkg on the non-disabled packages, UNLESS either the syslinux or other agreed upon boot option for “safe mode” is set, or a configuration option in the unRAID UI has been set to safe mode or disable all third-party packages/plugins. A .tgz package file may contain some unRAID-specific information (perhaps the .ini file?) that can be extracted and acted on by some yet-to-be-developed process, but a stock Slackware package will work fine without it. The install script in the .tgz file needs to handle creating and not overwriting its .ini file. The .ini file needs to be named to match the <appname> of its .tgz file.... <appname>.ini ... so we can easily do 3-way matching. .ini files go into a location shared by all .ini files. (Perhaps with the .tgz files?) What goes in the .ini files is left for future discussion.
July 20, 201015 yr I'm in agreement. I am not. There are many "packages" that are collections of .tgz files. I'd rather NOT rename them as .tgz.disabled, nor try to re-write every slackware package out there to include our new scheme. As an example, the "airVideo" package uses: AirVideoServerLinux.jar x264-20100425-i486-1alien.tgz faac-1.26-i486-1gds.tgz faad2-2.6.1-i486-2gds.tgz xvidcore-1.2.1-i486-1sl.tgz git-core-0.99.6-i486-1mik.tgz jam-2.5-i486-2gal.tgz lame-3.98.2-i486-1gds.tgz mpeg4ip-1.5.0.1-i486-1ahl.tgz yasm-0.7.2-i486-1sl.tgz libX11-1.1.5-i486-1.tgz libxcb-1.0-i486-1ced.tgz libXau-1.0.4-i486-1.tgz I'd rather have the .tgz files left as they are, and have a single "package" description file that we can control by re-naming (if you wish) This is complicated by the fact that some of the libraries are needed by other utilities ( hello ... "shared libraries" ...) and other are not .tgz files at all, but ".jar" Please, do not ask me to try re-name a full set of 14 .tgz files if we wish to enable, or disable a package. I'd really rather keep the single "package" description file as simple as possible. xml would work, "ini" format will work (and Tom seems to prefer that format) The .ini file can be changed to .ini.disabled. So... airvideo.ini / airvideo.ini.disabled That is my preference. The format in the ini can be discussed, but there will be a need for scripting, as many Slackware packages require some changes after they are installed to fit with the unRAID structure. If anything, the types of "sections" in the ".ini" file will be very similar to those in the unMENU package.conf files. Unless you plan on hosting (and potentially re-writing) every slackware package out there, a download URL will be needed, and a way to configure the package locally. If you make the format complicated, you'll not get the contributions from those who have no clue on how to create a ".tgz" installpkg. That, I think would be a mistake.
July 20, 201015 yr >> The install script in the .tgz file needs to handle creating and not overwriting its .ini file. this is "IF" it is included in the package.tgz file. The boot/installpkg procedure should ignore anything that is not named .tgz or txz. End of story there. When an .ini control file is available, It determines if it installs the associated packages if they are named properly. We have two needs. 1. Drop in basic slackware packages, install or not based on proper extension. 2. plugin control where the .ini determines it's status and subordinate dependencies. .jar and .zip files will need to be handled by a package manager or definitions in the .ini file. I think we are in agreement to use the .ini construct. So XML isn't a problem and at this point in time it complicates things. airvideo.ini / airvideo.ini.disabled (I agree with this technique for package managed configurations) Not everything or everyone wants things to be package managed.
July 20, 201015 yr # Install any extra packages if [ -d /boot/extra ]; then ( cd /boot/extra ; find -maxdepth 1 -type f -exec installpkg {} \; ) fi This needs to be changed, disabled, or put in the boot call out so it can be changed by a user. There is a blind expectation here and the possibility for exploitation. -name '*.tgz' -o -name '*.txz' satisfies part of it. I believe (and correct me if I'm wrong) -exec installpkg '{}' \; makes it safer with spaces or other embedded meta characters. With this I can disable a regular slackware package install by renaming it.
Archived
This topic is now archived and is closed to further replies.