May 8, 200818 yr If we can have a modified version of unRAID, then it could ..... Anyways I'll argue that point later. I mean this respectfully, however, you're clogging things up with geodesic thoughts. I'm fine with communicating it's merits, just not here. Start another thread or recontinue the old one. We have different points of view and I want to keep this on track so we can move forward Is far as the directory structure, I think it'd be less confusing to have it named like I did. This didn't really tell me enough. Like you did as far as the multple run levels? If so, that's there it from the wiki. It depends on Tom if he wants to implement it via emhttp. We still need a sanctioned, documented and agreed upon structure for dropping packages and scripts so users do not have to modify /boot/config/go I'm guessing you want to actually store the program directly in /boot/local so it'd be /boot/local/programname, but that won't work. This is an assumption and it is not what I had in mind at all. I'm only looking for a consensus on FHS directly on /boot FHS on /boot under another subdirectory (named local, unraid, custom whatever). If FHS is on /boot then it mimics root. Programs designed to run that stay there. that's a static copy. The only downside is that it will make the flash root directory busier with more files. That's the only downside. We can easily create a package to create this structure wherever we decide. If FHS is /boot/local then it mimics root there. Yes you would have /boot/local/usr/local or /boot/local/usr/share The upside of this is it's a cleaner root directory for the novice user. As far as a tree to sync to the real root. All we need is a /boot/local.sync directory installpkg -r /boot/local.sync will store programs there. As far as syncing between the two tree's that's a more detailed topic of implementation for later or another thread.
May 8, 200818 yr If we can have a modified version of unRAID, then it could ..... Anyways I'll argue that point later. I mean this respectfully, however, you're clogging things up with geodesic thoughts. I'm fine with communicating it's merits, just not here. Start another thread or recontinue the old one. We have different points of view and I want to keep this on track so we can move forward I was mentioning it in the spirit of this thread. It could make things easier. If we heard from Tom saying that it was ok, then we'd know that it was an option and could fully consider it. BTW, re-read the original post in this thread, neither your posts nor mine are strictly staying on topic. The thread was about a go directory instead of a go script. You started talking about making a standard way to install all third-party add-ons, I then talked about a modified version of unRAID that would be more friendly to adding programs and what-not. If FHS is on /boot then it mimics root. Programs designed to run that stay there. that's a static copy. The only downside is that it will make the flash root directory busier with more files. That's the only downside. We can easily create a package to create this structure wherever we decide. Not good, if we want to copy over the entire directory, we end up copying over unecessary files. It would also be difficult to have a separate directory that's static and another that needs to be copied over (and possibly sync'd). Yes it could be done, but you'd have to explicitly NOT copy a certain directory in /boot, and that could get confusing. If FHS is /boot/local then it mimics root there. Yes you would have /boot/local/usr/local or /boot/local/usr/share The upside of this is it's a cleaner root directory for the novice user. While that would work, the use of the name "local" would be confusing. It's tripped me up when I have to go down multiple levels with some directories named identically. You don't have to name it customcopy, I simply think it'd be better to name it something other than local. As far as a tree to sync to the real root. All we need is a /boot/local.sync directory installpkg -r /boot/local.sync will store programs there. As far as syncing between the two tree's that's a more detailed topic of implementation for later or another thread. That's what I was saying, just using a different directory name other than local*. In my example above, /boot/customcopy would be your /boot/local.sync and /boot/customperm would be your /boot/local. I'm saying that idea (yours or mine, whoever said it first) is good, I only think we can name it something other than "local". Now, when I used the word sync, I was talking about syncing back to the flash drive. I was going off on a tangeant. I tend to think of multiple things at once. Thinking of any cons to an approach and whether we can work around them or not. Many programs will need to be run off the main root filesystem, but may need to have files updated on the flash drive. I worked it out in my head and typed part of it down, figured that it could be worked out, and moved on.
May 8, 200818 yr Not good, if we want to copy over the entire directory, we end up copying over unecessary files. It would also be difficult to have a separate directory that's static and another that needs to be copied over (and possibly sync'd). Yes it could be done, but you'd have to explicitly NOT copy a certain directory in /boot, and that could get confusing. Two votes for not putting FHS directly on /boot. We're good here. If FHS is /boot/local then it mimics root there. Yes you would have /boot/local/usr/local or /boot/local/usr/share The upside of this is it's a cleaner root directory for the novice user. While that would work, the use of the name "local" would be confusing. It's tripped me up when I have to go down multiple levels with some directories named identically. You don't have to name it customcopy, I simply think it'd be better to name it something other than local. So another vote on a new tree under /boot Just not local. Well this is why I called the tree "unraid" in the wiki. So anyone navigating to the flash knew this tree was specific to the unraid instalation. Personally I'm ok with local simply because it implies the same thing. Directories, files, programs in this tree are specific to this machines implementation and are not part of the standard operating system distribution. It is "third party". For the record I have "unraid" as my locally implemented root in a couple places. On flash and on a disk share. On the disk share I have the expanded uncompressed root where I can install packages and remake bzroot. I also backup my /boot tree to /mnt/disk1/unraid/boot (the whole tree.. no trimming) just in case my flash gets hosed. So at this point we have vote - method 1 - /boot/local 1 - /boot/(somethingelse) I already use /boot/unraid I can switch to either. I'm not fond of customperm customcopy although I like the spirit of it. If I were to do it I would choose local & local.sync or unraid & unraid.sync. Where the default is permanent. Going back to what brought more out in the discussion someone preferred not to use unraid as the FHS root directory of /boot. I'm open. Discuss.
May 8, 200818 yr How about adding just 2 folders, /usercopy and /userstatic. One contains the tree to copy/sync - /boot/usercopy/bin, /boot/usercopy/etc, etc. The other keeps the package folders and other static stuff - /boot/userstatic/packages, etc.
May 8, 200818 yr I would be more inclined to use "custom" rather then "user" /boot/custom/ {bin,etc,usr/share) A person could then use the same package to recreate the tree or install as /boot/custom.sync Without the name it implies it is static. For those seasoned they can add the custom.sync folder and scripts. To me, "custom" means third party customizations (as does local). So we have suggestions for. /boot/user /boot/custom /boot/local /boot/unraid Good going, keep it coming guys, we're almost there.
May 8, 200818 yr I would be more inclined to use "custom" rather then "user" /boot/custom/ {bin,etc,usr/share) A person could then use the same package to recreate the tree or install as /boot/custom.sync Without the name it implies it is static. For those seasoned they can add the custom.sync folder and scripts. To me, "custom" means third party customizations (as does local). You've convinced me, my vote goes to your custom and custom.sync setup. By the way, congratulations on joining the Hero Member Club. Although I suppose its only an arbitrary milestone, whatever credit it carries you have certainly earned.
May 8, 200818 yr Here's a picture of the tree It can easily be unraid, local or custom. (more on the cache directory later) Log would be where we save syslogs (unless you want that in /boot/log. share/packages doesn't necessarily have to be under a usr.. It's open for discussion. !/boot/custom/ |___bin/ |___etc/ ! |___rc.d/ ! ! |___init.d/ ! ! |___rc-post-array-start.d/ ! ! |___rc-post-array-start-onboot.d/ ! ! |___rc-post-array-stop.d/ ! ! |___rc-pre-array-start.d/ ! ! |___rc-pre-array-start-onboot.d/ ! ! |___rc-pre-array-stop.d/ |___lib/ |___usr/ ! |___share/ ! ! |___packages/ |___var/ ! |___cache/ ! |___log/
May 8, 200818 yr I still have a preference for finding the current/latest syslog as close to the root as possible, for new and non-technical users. Plus, they (many users) won't have a custom tree to put their syslogs. A compromise, but may satisfy both needs, keep a copy of the latest syslog in the root, always named /boot/syslog.txt. Then you can put the archive of syslogs any where you want, eg. /boot/custom/var/log.
May 8, 200818 yr I still have a preference for finding the current/latest syslog as close to the root as possible, for new and non-technical users. Plus, they (many users) won't have a custom tree to put their syslogs. A compromise, but may satisfy both needs, keep a copy of the latest syslog in the root, always named /boot/syslog.txt. Then you can put the archive of syslogs any where you want, eg. /boot/custom/var/log. Keep in mind that flash drives have a limited number of "write" cycles... A log file should not be kept there unless it writes very very infrequently, so /boot/custom/log is a bad idea unless it is a symbolic link to the actual file or folder elsewhere. /boot/custom sounds fine to me too. Joe L.
May 9, 200818 yr Author I still have a preference for finding the current/latest syslog as close to the root as possible, for new and non-technical users. Plus, they (many users) won't have a custom tree to put their syslogs. A compromise, but may satisfy both needs, keep a copy of the latest syslog in the root, always named /boot/syslog.txt. Then you can put the archive of syslogs any where you want, eg. /boot/custom/var/log. Keep in mind that flash drives have a limited number of "write" cycles... A log file should not be kept there unless it writes very very infrequently, so /boot/custom/log is a bad idea unless it is a symbolic link to the actual file or folder elsewhere. Joe L. Logs stored in RAM is a great idea until your machine locks up and you don't have logs to debug it. Writing to flash would be OK if the GUID wasn't tied to the licence (since its a couple of dollars to replace a flash drive). This IMO is one of the biggest downsides of unRAID that unfortunately only effects the people who are having problems. If you dont have problems you dont care about this. Heres a random thought.... how about a completely separate flash drive for all of this. Solves the log problem and reduces the chances that of breaking a legit install. The more i think about it the more I think i has alot of advantages (alot of which are OT here such as config backups etc etc)
May 9, 200818 yr I still have a preference for finding the current/latest syslog as close to the root as possible, for new and non-technical users. Plus, they (many users) won't have a custom tree to put their syslogs. A compromise, but may satisfy both needs, keep a copy of the latest syslog in the root, always named /boot/syslog.txt. Then you can put the archive of syslogs any where you want, eg. /boot/custom/var/log. Keep in mind that flash drives have a limited number of "write" cycles... A log file should not be kept there unless it writes very very infrequently, so /boot/custom/log is a bad idea unless it is a symbolic link to the actual file or folder elsewhere. Joe L. Logs stored in RAM is a great idea until your machine locks up and you don't have logs to debug it. Writing to flash would be OK if the GUID wasn't tied to the licence (since its a couple of dollars to replace a flash drive). This IMO is one of the biggest downsides of unRAID that unfortunately only effects the people who are having problems. If you dont have problems you dont care about this. Heres a random thought.... how about a completely separate flash drive for all of this. Solves the log problem and reduces the chances that of breaking a legit install. The more i think about it the more I think i has alot of advantages (alot of which are OT here such as config backups etc etc) I really like the idea. The other flash drive could easily be identified by its volume label, as long as we all agree to what it should be. Actually, we should not care of the type of drive for the second drive... we should just look for it by label and use the one we find. That way, I can plug in a USB hard disk, or a flash drive and use either. We would just need to mount it if we find it, and make a share for it if we desire to get to it from the lan if needed. (and agree on a label name for its volume label ;D) Let the volume name negotiations begin. Joe L.
May 9, 200818 yr Keep in mind that flash drives have a limited number of "write" cycles... A log file should not be kept there unless it writes very very infrequently, so /boot/custom/log is a bad idea unless it is a symbolic link to the actual file or folder elsewhere. Joe L. I don't expect the log to be updated that often in this location. The plan was only to save it on reboot, poweroff, or user request.
May 9, 200818 yr I really like the idea. The other flash drive could easily be identified by its volume label, as long as we all agree to what it should be. Actually, we should not care of the type of drive for the second drive... we should just look for it by label and use the one we find. That way, I can plug in a USB hard disk, or a flash drive and use either. We would just need to mount it if we find it, and make a share for it if we desire to get to it from the lan if needed. (and agree on a label name for its volume label ;D) Let the volume name negotiations begin. Joe L. How many people do you think will go out an purchase another flash, or another drive to store this information on? We have 11 characters to choose from. CUSTOM fits but has no designation as owned by unraid. UNRAIDCUSTOM doesn't fit. UNRAIDROOT fits. UNRAIDSUPP for unraid supplementary support fits. Frankly, I'm not sure if this is really needed. I'm considering the use of a tool called runlevel which will run the shells in the subordinate directories. It will be called as: runlevel [CUSTOMDIRECTORYROOT] [RUNLEVEL] ... where arguments are passed to all shells in run. Custom directory can point to any FHS root locatation where a user installs. Runlevel can be undefined for the defauilt startup or if we get buy in from tom with the 6 run levels, then a runlevel that unraid is at. So in all, this could possibly exist on a hidden directory in the cache drive or another flash. It's a user option. We have to consider, if we do have another flash or location fort the customroot, then we will have to insure it is mounted. This entails updating the go script, mounting the drive in a location then handling the startup. Or is it just being suggested that another flash is used only for output and shared data such as packages? Personally, I bought a 2GB SD card with a reader for $12.00 and I'll just write everything there.
May 9, 200818 yr Also this is one of the reasons I had suggested the Cache logic use a directory as in /var/cache for the cached files rather then the whole root. Then the cache drive could have a complete slackware dev system or other environment without conflicting with the mover script and/or naming issues. As it is now, you would have to create a regex filter or create things in hidden directories. I think this limits it's use at the current time except for seasoned linux people.
May 9, 200818 yr Author How many people do you think will go out an purchase another flash, or another drive to store this information on? I think its reasonable to make it a pre-requisite. I mean a 1GB one is what $6? Yes it definitely complicates matters but IMO its a better long term solution. I would suggest all custom files live there be they binaries, config files or logs. I would also suggest normal system logs get dumped to it as well. The down side is we would need to customise go some more but I reckon Tom would build this into standard for us. We can probably move forward without making this decision but it would be nice to agree in principle its a solid idea and make sure all further ideas are compatible with it. Or reject it thats an option as well but i still love the idea
May 9, 200818 yr If we make the target drive defined by an environment variable, and use it to find the target device by-label, and if UNRAIDSUPP is not defined, use "UNRIAD" as the target drive to put the /custom/... hierarchy instead of the alternate labeled device, then it would work for just about anybody, even if they do not want to use a second flash drive for the add-on-scripts. For those of us that add an additional drive, or allocate a partition somewhere for it, we can simply set the volume label and all will work. It might be good to just mount that volume on /boot/custom so all will see the same paths regardless of where the physical storage might be. Joe L.
May 23, 200818 yr Author Theres a few of us champing at the bit watching this thread for Toms comment so we can move on. Once we have this it will be a roller coaster ride of new community hacks too unRAID so.... Tom, we need you... come on down
June 25, 200818 yr Any reason why you have to use another flash drive? cant you use the cache drive as a place to place files?
June 25, 200818 yr Author Any reason why you have to use another flash drive? cant you use the cache drive as a place to place files? No reason other than alot of people wont use a cache drive and USB keys are super cheap.
June 25, 200818 yr Also, I'm not sure the cache drive is mounted in time for this to occur properly. I.E. The array has to be started, mounted then fire off your scripts. Now, if emhttp fired off the scripts, a seed script could mount the drive, then continue. Another thought is to use a 2md partition on the cache drive. I.E> Part1 would be for cache and be mounted by emhttp Part2 would be for the custom root and mounted by the go script via LABEL. Third option is to use a hidden file on the cache drive and mount it via loopback. Still depends on the cache drive being mounted before hand.
July 7, 200817 yr Author Theres a few of us champing at the bit watching this thread for Toms comment so we can move on. Once we have this it will be a roller coaster ride of new community hacks too unRAID so.... Tom, we need you... come on down Polite bump. Just to be clear this entire project is on hold until Tom voices his opinions.
July 10, 200817 yr Tom, Any thoughts on this? I'm sorta at a standstill with any future package development. There are some packages that cannot be installed correctly until emhttp believes everything is a go, and there are certain cleanup situations that must occur during shutdown so that the volumes can be cleanly unmounted. For example, If we setup pacakges scripts and daemons for torrenting.. emhttp needs to start our apps when volumes are ready to rock and run a script to tell those programs to shutdown. Can you give us some idea of yes, no, maybe so.. or other thoughts. Thanks.
Archived
This topic is now archived and is closed to further replies.