Suggestions? Prerequisities Install Script

[delicatepc]

Hi Folks,

 

Putting together a script that would install/download most (if not all) of the core community prerequisites onto a unRAID install. So far I have the following I would like add:

 

Scripts: S.N.A.P, unMenu, Preclear

Packages: unZip, Nano, Java Runtime Environment, InfoZip, PowerDown, Apcupsd

Nice Things:Code so machine beeps when go file completed,

 

Can anyone suggest any other tools or things they religiously use when working on unRAID? I want to make this script for my convenience as well as other folks.

 

thanks,

~dpc

[S80_UK]

I would always have the apcupsd package installed (via unmenu in my case).

[kizer]

cache_dirs

http://lime-technology.com/forum/index.php?topic=4500.0

[kizer]

I wouldn't say bundle it, but if you could make some for

Crashplan and PS3MediaServer it would be awesome for some people.

 

If you need a place to store files let me know. I've had a domain setting for a while that Ive been using for email for the past 6years.

[delicatepc]

Noted noted noted and noted! Excellent

 

OMG i just met Subsonic....  :o :o BLOWS MY MIND! Amazing amazing amazing - script for that is coming too!!!

 

My end goal is to have a post that has a list of packages/scripts I put together to share.

 

~dpc

[Joe L.]

Noted noted noted and noted! Excellent

 

OMG i just met Subsonic....   :o :o BLOWS MY MIND! Amazing amazing amazing - script for that is coming too!!!

 

My end goal is to have a post that has a list of packages/scripts I put together to share.

 

~dpc

Please DO NOT include any of my scripts in your UNLESS you download them dynamically from their affiliated threads when the script is invoked and can deal with the script logging into the forum to be able to access the download attachments.     Otherwise the scripts will quickly get out of date with respect to the latest versions.

 

Of those listed so far, my scripts that you should not copy would then basically be unmenu, preclear, cache_dirs and those affiliated with setting up apcupsd in an unRAID environment.

(although you could dynamically download unmenu's zip archive from google.code, as that is not an attachment to a thread)

 

I know you are trying to be helpful, but it will only cause confusion when older versions are available for download.  Since you are not the one who they'll be crying to when they don't work as desired, you cannot include them except as a dynamic download.     If you want to write your own scripts, go for it and I wish you all the best.  There are plenty of examples to use as templates.  Just ensure they too can be kept current.

 

Joe L.

 

[delicatepc]

Please DO NOT include any of my scripts in your UNLESS you download them dynamically from their affiliated threads when the script is invoked and can deal with the script logging into the forum to be able to access the download attachments.     Otherwise the scripts will quickly get out of date with respect to the latest versions.

 

Of those listed so far, my scripts that you should not copy would then basically be unmenu, preclear, cache_dirs and those affiliated with setting up apcupsd in an unRAID environment.

(although you could dynamically download unmenu's zip archive from google.code, as that is not an attachment to a thread)

 

I know you are trying to be helpful, but it will only cause confusion when older versions are available for download.  Since you are not the one who they'll be crying to when they don't work as desired, you cannot include them except as a dynamic download.     If you want to write your own scripts, go for it and I wish you all the best.  There are plenty of examples to use as templates.  Just ensure they too can be kept current.

 

Joe L.

Definitely. My goal is to simply reference the scripts dynamically and have them just quickly pull them all together in one file and download them.

 

Just to clarify - I do not want to copy any scripts. Just have the script do all the click work.

 

Could definitely use any assistance on creating some of the grep/awk statements to figure out the latest versions of the files. Joe L. are you looking to move any more of your scripts to code.google.com (other than unMenu)?

 

thanks,

~dpc

[Joe L.]

Just to clarify - I do not want to copy any scripts. Just have the script do all the click work.

Your script will need to deal with the fact that forum attachments cannot be accessed until a forum member logs on with a valid/registered id/password.  That will not be an easy step with a script.  I'll be curious to see how you handle that.

Could definitely use any assistance on creating some of the grep/awk statements to figure out the latest versions of the files.

Sorry... not able to help there.

Joe L. are you looking to move any more of your scripts to code.google.com (other than unMenu)?

No.  Not at this time.

[delicatepc]

Sorry... not able to help there.

Joe L. are you looking to move any more of your scripts to code.google.com (other than unMenu)?

No.  Not at this time.

Any special reason why not?

 

I may be wrong but I get the feeling you are standoff-ish toward me. Im not sure what may have upset you (perhaps its my question regarding unMenu or perhaps me trying to recreate the wheel in a different way). You have a lot more scripting experience than me and are very knowledgeable with the unRAID. I got a fire burning on under my ass (figuratively speaking).

 

Lets work together? What do you think about hosting the attachments outside in a easily accessible area?

 

thanks,

dpc

[prostuff1]

I'm glad you have a passion to do this stuff... I wish I had more time to write up scripts similar to this.

 

While I applaud your efforts, what you are trying to do is sort of re-inventing the wheel, like you said.  That is great and all, and if you can make a "better" version of unMenu then great.

 

The unMenu package manager can do and essentially does what you are trying to do with your script, at least from what I gather.

 

My suggestion is to look into the unMenu code, and look at the large collection of packages that have been created so far for it.  The unMenu package .conf files are essentially shell scripts with goodies.  Everything you are doing... or most of it, can be done from within unMenu and provide the user a 3 click (or so) process of configuring, installing, and reinstalling for reboot, a package they want.

 

I have a list of packages I want to create... but the short fact of the matter is that I do not have the time to create them... maybe one of these days.

[delicatepc]

Hi ProStuff1,

 

I have been actually already looking at the unMenu packages and they are essentially bash scripts themselves. I have been heavily recreating some of them back into BASH scripts. They are a great resource and are nice.

 

I take issue with the following:

> unMenu does not include packages that are bleeding edge (manually can be added... but then we are back to same place). This makes sense. But as somebody who likes to use latest and greatest I decide to go back to the basics of bash script as I find it more comfortable. I will even venture to say it makes more sense to create a bash script first and then port to unMenu package when it is stable.

 

> unMenu is not testing friendly due to limitations of design (which I should gracefully add was conceived long ago and has lasted for a healthy time). unMenu is a solid system for stable packages. But when I'm trying to put together a new package running a bash script and editing with nano is lot easier than navigating to unMenu and using the buttons to test.

 

> Joe L. - You appear to take issue with having old releases being installed and users complaining. Ok I understand. I see you are comfortable with code.google.com - Host up your preclear, cache_dirs on code.google.com or an alternate easily accessible location. With the help of Queeg (of S.N.A.P.) there is a simple script snippet that could modified to dynamically pull down the latest version of your packages:

wget -q -O /tmp/snap.html http://code.google.com/p/unraid-snap/downloads/list 2>&1
snapurl=($(cat /tmp/snap.html |grep "http://unraid-snap.googlecode.com/files/snap-.*.tgz"|grep "snap-current-release"|grep -o '"http://unraid-snap.googlecode.com/files/snap-.*.tgz"'|sed s/\"//g))
wget -nv $snapurl

 

~dpc

[delicatepc]

> Joe L. - Can you please explain this statement:

Of those listed so far, my scripts that you should not copy would then basically be unmenu, preclear, cache_dirs and those affiliated with setting up apcupsd in an unRAID environment.

You mean this?:

http://unraid-unmenu.googlecode.com/svn/trunk/apcupsd-unmenu-package.conf

 

Are you saying I/community cannot use your code or recreate it into a bash script?

 

~dpc

[neilt0]

As someone who has written a couple of scripts to install apps that are not available in unMenu, I'd still say:

 

[delicatepc]

Lol I do agree - much easier for me to reinvent/recreate the wheel just the way I like it than be original. But I leave originality for my day job.

 

~dpc

[prostuff1]

I take issue with the following:

> unMenu does not include packages that are bleeding edge (manually can be added... but then we are back to same place). This makes sense. But as somebody who likes to use latest and greatest I decide to go back to the basics of bash script as I find it more comfortable. I will even venture to say it makes more sense to create a bash script first and then port to unMenu package when it is stable.

Latest and greatest is fine for some.  I dropped using latest and greatest a while back when I installed an OS X update on my laptop that kept it from booting back up.  Thankfully I had a bootable backup and was fine afterwards.

 

> unMenu is not testing friendly due to limitations of design (which I should gracefully add was conceived long ago and has lasted for a healthy time). unMenu is a solid system for stable packages. But when I'm trying to put together a new package running a bash script and editing with nano is lot easier than navigating to unMenu and using the buttons to test.

I agree that in general it is not testing user friendly... but as you stated the packages are mostly bash scripts, at least the parts that do the installing.  I usually write the script out and test it outside of unMenu to make sure it works like I want it to, then I copy it into place and test the 3 button install way.

 

> Joe L. - You appear to take issue with having old releases being installed and users complaining. Ok I understand. I see you are comfortable with code.google.com - Host up your preclear, cache_dirs on code.google.com or an alternate easily accessible location. With the help of Queeg (of S.N.A.P.) there is a simple script snippet that could modified to dynamically pull down the latest version of your packages:

wget -q -O /tmp/snap.html http://code.google.com/p/unraid-snap/downloads/list 2>&1
snapurl=($(cat /tmp/snap.html |grep "http://unraid-snap.googlecode.com/files/snap-.*.tgz"|grep "snap-current-release"|grep -o '"http://unraid-snap.googlecode.com/files/snap-.*.tgz"'|sed s/\"//g))
wget -nv $snapurl

I could be wrong but I believe the code snippet you reference was "created" by Joe L. for use in the unMenu update process.  I am sure Queeg's is a little different but Joe L.'s "Check for unMenu Updates" button and "Install unMenu Updates" button on the User Scripts page do what you mention already.

[Joe L.]

> Joe L. - Can you please explain this statement:

Of those listed so far, my scripts that you should not copy would then basically be unmenu, preclear, cache_dirs and those affiliated with setting up apcupsd in an unRAID environment.

You mean this?:

http://unraid-unmenu.googlecode.com/svn/trunk/apcupsd-unmenu-package.conf

 

Are you saying I/community cannot use your code or recreate it into a bash script?

 

~dpc

you may do as you wish, writing any shell script you like... all I'm saying is that your script will be YOUR script, and not have anything to do with unMENU.   You should write it in a way that does not conflict with people who already have unMENU and apcupsd configured. (that would upset them, if they run your script and it clobbered an existing/working installation)

 

The community has far more users who want a graphical interface than one that is command-line based.  From what I see if your sample scripts, they'll undergo a lot of revisions.   You will learn a lot, but be prepared for a lot of effort.

 

I have not had the time to deal with the changes I've been asked to do to unMENU itself.   It is not that I do not want to cooperate, I simply do not have the time.  The past few weeks have been absolutely crazy around here.

 

If you think I'm upset, I'm not.  I've recently started at a new job, so I have less time to spend coding here.  I'm just not interested in changing how I am operating at this time.  my google.code page is only for unMENU.  I do not wish to use it for other projects.   My life does not revolve around shell scripts as yours seems to, but I've been writing shell scripts long enough to pre-date bash shell, korn-shell, or bourne shell.   My first unix used "mashey shell" (John Mashey of Bell labs) http://en.wikipedia.org/wiki/PWB_shell  It still had labels and gotos...  This was all years before Linux was even thought of.

 

I've shared everything I've done with the unRAID community... and others have built on it.  You will build on what I've learned too, but you'll also grow your own skills in the process.

As I said, I wish you luck, but I think the audience who wants "everything" in a single command line script is very small.  

 

There is a framework available with entry fields and scripting in the package manager in unMENU.  It can handle very simple tasks with no downloads at all involved, and it has been able to handle pretty complex installations, with tons of configurable fields.  I'll have to see how you duplicate the installation of "airvideo" with its downloading and compiling of ffmpeg, and the dozens of configuration fields without a graphical interface.   As I said, the unMENU package.conf files are rich in embedded knowledge.   Your turn to learn.  They are, basically shell scripts.  The user-edit scripts are actually just shell scripts with a few added "comment" fields to define the button label and description.  The framework is there for you to write scripts and still make it possible for those with less skills than you to use them.

 

I recommend you start by doing one thing well.  If that works, then go for it... re-write it all.

 

Joe L.

 

[delicatepc]

I concede. As i got more in depth of the coding I realized more than one packages leads me into a problem zone.

 

So now I decided on the following:

dpcmassive.sh - This will be a "personal" script that I will basically mash everything I want and kinda drop into the community so perhaps folks can grab snippets of code or just go balls out and install the monstrosity onto their box.

 

dpc**********.sh - Shell scripts that will install specific packages completely. Unfortunately it can be messy since complete install means complete (including copies of cleanshutdown and etc.). If someone can present a some code that could check against unMenu's database of installed packages that would be excellent. Theory of this is code would be like " [ ! -f /boot/unmenu/packages/packageX.txz ] then" ... in other words would see if the package is downloaded (and if downloaded I assume is installed and exists in the /boot/config/go)

 

~dpc

[prostuff1]

" [ ! -f /boot/unmenu/packages/packageX.txz ] then" ... in other words would see if the package is downloaded (and if downloaded I assume is installed and exists in the /boot/config/go)

No, there is one line in the go file that unMenu uses to install all packages.  Anything in /boot/packages/ with a .auto_install will be installed on a reboot.

[delicatepc]

Hmm makes sense... Then I shall focus my efforts on my massive ridiculous monstrosity! lol

 

~dpc