An Improved unRAID web-interface, extensible, and easy to install


Recommended Posts

Works like a champ!  Thanks Joe.

 

Now, as I look at my GO script and all the stuff I've got in there I can imagine how I might be able to clean it up and use this method to run scripts instead.  Some thoughts:

 

- would it be possible to get rc.local_startup to chmod all scripts to ensure they are executable?

--- I can kind of imagine how I'd edit the script to do this, but I hesitate to make changes to a script that other's are using for fear that I'll blow away my changes with an update that you guy's publish at some later date.  (actually, this comment hints to a much deeper rooted anxiety of mine related to management of all the cool stuff you guys make and that I add to my unraid server.)

- package managment is becoming a bit complex.  I like having the unmenu interface to manage package installation, but I'm installing other packages that aren't in unmenu (rsync, openssl, openssh, pciutils)

- pcituils is needed for the unmenu system info tab. (isn't it?)  Shouldn't at least that package be in the unmenu package manager?

- someday, would it be possible to have the package manager recognize when a newer version is available and then give an option to re-install the newer package version? (ok, I realize I'm dreaming now)

 

 

 

Link to comment
  • Replies 552
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Works like a champ!  Thanks Joe.

 

Now, as I look at my GO script and all the stuff I've got in there I can imagine how I might be able to clean it up and use this method to run scripts instead.  Some thoughts:

 

- would it be possible to get rc.local_startup to chmod all scripts to ensure they are executable?

Actually, since they are execuited via "sh -xv scriptname, I don't think they need to be anything other than readable.

--- I can kind of imagine how I'd edit the script to do this, but I hesitate to make changes to a script that other's are using for fear that I'll blow away my changes with an update that you guy's publish at some later date.  (actually, this comment hints to a much deeper rooted anxiety of mine related to management of all the cool stuff you guys make and that I add to my unraid server.)

I understand, that is why simpler is usually better.  You don't need to edit anything, just remember that any file put in /boot/custom/etc/rc.d will be execuited in turn.

 

For example, I have several others in my folder that do various tasks, from setting up a monthly parity check, to setting the editing mode for the bash command line ("bash", by default, has it set to emacs mode, I prefer "vi" mode)

 

That file, named S01-initrc in my rc.d folder,  looks like this:

if [ ! -f /root/.inputrc ]

then

        echo "set editing-mode vi" >/root/.inputrc

        echo "set keymap vi-insert" >>/root/.inputrc

fi

You can either put scripts like this in place for each of your other packages, or, if they exist in /boot/packages, put a packagename.auto_install file in /boot/packages similar to the ones created by the package manager plug-in.  The script can have any sequence of commands needed to install the package.

- package managment is becoming a bit complex.  I like having the unmenu interface to manage package installation, but I'm installing other packages that aren't in unmenu (rsync, openssl, openssh, pciutils)

I understand...

- pcituils is needed for the unmenu system info tab. (isn't it?)  Shouldn't at least that package be in the unmenu package manager?

Probably should... look for it soon... in the interim, if you are willing, perhaps you can put together a package.conf file in the style used by the package manager plug-in.

- someday, would it be possible to have the package manager recognize when a newer version is available and then give an option to re-install the newer package version? (ok, I realize I'm dreaming now)

Yeah, you are probably giving the computer too much credit... we need to leave some of the management tasks to people...  The package manager plug-in only knows the path to a given version of a file.  That file is named specifically for the version it holds.  We would have no way to know a newer version exists, or is compatible with unRAID servers.

 

Glad you like the way packages can be managed through unmenu.awk.  I'm sure it will evolve over time, but a series of files, one per package is easiest.  I've already figured out that I should not put more than one package definition in a file... It makes it so much easier if a path to a package gets out of date.  If you have other suggestions, I'm open to new ideas.  I'll not always be able to impliment them, but who knows, it will spark ideas regardless.

 

Joe L.

Link to comment

Well, Joe, I tried to put together a package.conf for the pci utils package.  I didn't succeed.  See attached.

 

I knew that I had no idea what the PACKAGE_INSTALLATION and PACKAGE_VERSION TEST values should be, but I finally got tripped up on the PACKAGE_INSTALLED value.

 

The package downloads, but upon installation I receive the following error:

 

pciutils-2.2.10-i486-1 apparently did not install properly, /sbin/lspci does not exist.

 

At least I tried :)

Link to comment

jardotufts,

 

Great start... 

The PACKAGE_INSTALLED field is the full path to a file that "if it exists" indicates the package had been installed.  In this case, /sbin/lspci will not exist unless the package is installed, but will exist after it is installed.    The PACKAGE_FILE name needed the ".tgz" suffix.  It is the name used for the downloaded file.  It needs the ".tgz" suffix because the installpkg command expects a compressed tar file with that suffix.

 

Most commands have a "version" option... I downloaded and installed the lspci package, then ran lspci --version to see its output.  It turns out the version number is the third field.  The PACKAGE_VERSION_TEST is then lspci --version piped to "awk" to print the third field.  That value is then matched to the PACKAGE_VERSION_STRING. 

 

You were very close, especially since I really did not describe how the package configuration files were defined anywhere yet.

 

You had this:

PACKAGE_NAME pci utils (pci  utilities)

PACKAGE_DESCR library required for "PCI Devices" button on unMENU "System Info" tab. 

PACKAGE_DESCR lspci displays detailed information about all pci buses and devices

PACKAGE_DESCR in the system, replacing the original /proc/pci interface. 

PACKAGE_DESCR setpci allows reading from and writing to pci device configuration

PACKAGE_DESCR registers.  For example, you can adjust the latency timers with it.

PACKAGE_URL http://slackware.mirrors.tds.net/pub/slackware/slackware-current/slackware/a/pciutils-2.2.10-i486-1.tgz

PACKAGE_FILE pciutils-2.2.10-i486-1   <-- need the .tgz suffix here, as installpkg expects it.

PACKAGE_INSTALLED /sbin/lspci

PACKAGE_MD5 12bdc234be1910f85c4e0d0afcc43da4    <--after download, use "md5sum pciutils-2.2.10-i486-1.tgz" to get correct checksum for this field

PACKAGE_DEPENDENCIES none

#PACKAGE_INSTALLATION test ! -f /usr/lib/stdc++.so.6.0.8 && installpkg cxxlibs-6.0.8-i486-4.tgz  <-- replace this with installpkg pciutils-2.2.10-i486-1.tgz

#PACKAGE_VERSION_TEST ls /usr/lib/libstdc++.so.6.0.8  <-- replace with lspci --version | awk '{print $3 }'  to get version string (third field of --version output)

PACKAGE_VERSION_STRING 2.2.10

PACKAGE_MEMORY_USAGE Light (10K to 500K)

 

With the changes, it looks like this:

PACKAGE_NAME pci utils (pci  utilities)

PACKAGE_DESCR library required for "PCI Devices" button on unMENU "System Info" tab.

PACKAGE_DESCR lspci displays detailed information about all pci buses and devices

PACKAGE_DESCR in the system, replacing the original /proc/pci interface.

PACKAGE_DESCR setpci allows reading from and writing to pci device configuration

PACKAGE_DESCR registers.  For example, you can adjust the latency timers with it.

PACKAGE_URL http://slackware.mirrors.tds.net/pub/slackware/slackware-current/slackware/a/pciutils-2.2.10-i486-1.tgz

PACKAGE_FILE pciutils-2.2.10-i486-1.tgz

PACKAGE_INSTALLED /sbin/lspci

PACKAGE_MD5 952da08ababe1dcc5c3c54477f32c995

PACKAGE_DEPENDENCIES none

PACKAGE_INSTALLATION installpkg pciutils-2.2.10-i486-1.tgz

PACKAGE_VERSION_TEST /sbin/lspci --version | awk '{ print $3 }'

PACKAGE_VERSION_STRING 2.2.10

PACKAGE_MEMORY_USAGE Light (10K to 500K)

 

I attached the corrected package.conf file here for the lspci command.  I'll also include it when I deploy the next release of unmenu.

Thanks so very much for the assist in putting together the lspci package.conf file.... 

(you can delete the attachment from your post, as this one should install correctly)

 

Joe L.

Link to comment

Joe,

 

I think we need a complete refresh of the package.conf files.  I'm running with what I think is the most recent full release of unmenu that was posted on Oct 14 (first page of this thread).  In that release there was a version of 20-unmenu-package.conf that contained two package definitions.  One for infozip and another for wget.

 

If I replace my current 20-unmenu-package.conf with this latest one it will have the effect of removing the wget package definition.

 

Now, with all my new found knowledge of package.conf files it would be no problem for me to split out the wget package definition into it's own file.  That's not my concern.  My concern is with package.conf file naming.  If everybody is making up their own names, as we continue to share these conf files there will be conflicts and duplicates over time.

 

Howabout instead of using a unique number, to keep the .conf file names unique, we use the package name with a .conf extension (i.e. infozip-5.52-i486-2.conf).

 

I just tried this by renaming "803-unmenu-package-pciutils.conf" to "pciutils-2.2.10-i486-1.conf".  It didn't work.  I believe there must be more magic in the numbering system than meets the eye. 

Link to comment

Joe,

 

I think we need a complete refresh of the package.conf files.  I'm running with what I think is the most recent full release of unmenu that was posted on Oct 14 (first page of this thread).  In that release there was a version of 20-unmenu-package.conf that contained two package definitions.  One for infozip and another for wget.

I agree... it will get confusing.. but, we are learning as we go....  I've not done this before either  ;) ;)

Howabout instead of using a unique number, to keep the .conf file names unique, we use the package name with a .conf extension (i.e. infozip-5.52-i486-2.conf).

I just tried this by renaming "803-unmenu-package-pciutils.conf" to "pciutils-2.2.10-i486-1.conf".  It didn't work.  I believe there must be more magic in the numbering system than meets the eye. 

I've done much the same thing...  I've put each package into its own file.

 

I'm tossed between naming the file for the specific version, since then downloading a new set of package files will leave the older and out of date file in place, or simply naming the files after tha base package.  That way, a newer one will overwrite an older... and when you use the package manager it will show the version difference.    I'm leaning towards this approach.

 

If you look closer, the file attached to the prior post is named 20-unmenu-package-zip.conf  so it will NOT overwrite the existing file in your directory.

 

The "magic" pattern needed to be recognized is N-unmenu-*package*.conf

where N is a leading number (I don't care if it is 1,2,3, or more digits)

and "*" is anything you desire.

 

I prefer N-unmenu-package-whatever_you_like.conf, since when you do a listing of the folder the files will all be grouped together.

 

So, to name your package file specifically for the version it applies to, it would be: NN-unmenu-package-pciutils-2.2.10-i486-1.conf

I do prefer NN-unmenu-package-pciutils.conf though, for my reasons stated above... That way, if I deploy a newer package file, for a newer version, it will overwrite the older.

 

What are your thoughts?

 

Joe L.

Link to comment

I like your thoughts of keeping the version number out of the file name so that newer versions will overwrite the old.

 

As far as grouping of files go...  I like the idea but think we might have even better grouping options if we forgo the number for something else.  For example, if the .conf is named NN-unmenu-package-pciutils.conf, this file will appear next to its ".conf cousins" and the .conf files appear at the top of the file list.  This is good, but there is no way to sort the directory such that the .conf files appear alongside their "package prodigy".

 

But, if this same .conf were named as pciutils-unmenu-package.conf it would appear alongside its "package prodigy", i.e.:

 

pciutils-unmenu-package.conf

pciutils-2.2.10-i486-1.tgz

pciutils-2.2.10-i486-1.auto_install

pciutils-2.2.10-i486-1.manual_install

 

You could still sort by filetype to see the .conf files together.

 

 

 

Link to comment

I like your thoughts of keeping the version number out of the file name so that newer versions will overwrite the old.

 

As far as grouping of files go...  I like the idea but think we might have even better grouping options if we forgo the number for something else.  For example, if the .conf is named NN-unmenu-package-pciutils.conf, this file will appear next to its ".conf cousins" and the .conf files appear at the top of the file list.  This is good, but there is no way to sort the directory such that the .conf files appear alongside their "package prodigy".

 

But, if this same .conf were named as pciutils-unmenu-package.conf it would appear alongside its "package prodigy", i.e.:

 

pciutils-unmenu-package.conf

pciutils-2.2.10-i486-1.tgz

pciutils-2.2.10-i486-1.auto_install

pciutils-2.2.10-i486-1.manual_install

 

You could still sort by filetype to see the .conf files together.

Good point...

 

The only reason for the leading number is so we can control the order in which the packages are installed.  If I relax that requirement and make the number optional, we can have the best of both worlds.

 

To make this change, in file 990-unmenu-wget.awk at around line 48, make the following tiny change in the lines shown below in bold.

Old

  # open unmenu package files,

  # look for any "NN-unmenu-package*.conf" files

  # move them to the packages directory, then

  # for each file, open it to read the desired package details

  cmd="ls " ScriptDirectory "/[0-9]*-unmenu-*package*.conf 2>/dev/null"

New

  # open unmenu package files,

  # look for any "*-unmenu-*package*.conf" files

  # move them to the packages directory, then

  # for each file, open it to read the desired package details

  cmd="ls " ScriptDirectory "/*-unmenu-*package*.conf 2>/dev/null"   

 

Also, at line 59

Old

cmd="ls " PACKAGE_DIRECTORY "/[0-9]*-unmenu*package*.conf 2>/dev/null"

New

cmd="ls " PACKAGE_DIRECTORY "/*-unmenu*package*.conf 2>/dev/null"

 

Basically, I deleted the "[0-9]" (shown in red in the "Old" above) from the "ls" command line and fixed the comment in the line above it to match.  The existing files will still work, and so will the files named as you described in your post.

 

Thanks again for your valuable feedback.

 

Joe L.

 

Edit: added additional spot to edit to remove "[0-9]" from "ls" pattern.

Link to comment
The only reason for the leading number is so we can control the order in which the packages are installed. 

 

Joe,

 

This hints to one of the reasons I was trying to imagine that the numbering system was first introduced, and that was (maybe) to satisfy dependency requirements.  Well, then as I thought of it more, since unmenu handles each .conf independently, this couldn't be the case.  Anyhow, at that point my brain was already spinning with how to address dependencies.  I'm not familiar enough with bash, awk, cgi, etc... syntax to imagine an exact solution (I'm a MS VB kind of guy so I can almost read/understand your scripting but I can't 'speak' your language(s) yet).  So, I'll share my ideas at a higher level...

 

1) I've seen in other .conf files attempts at testing the existance of 'some thing' before continueing with package installation (I think this is what I was reading, anyhow) i.e.:

 

  PACKAGE_INSTALLATION test ! -f /usr/lib/stdc++.so.6.0.8 && installpkg cxxlibs-6.0.8-i486-4.tgz

 

2) The system is already wise enough to know if a package even exists before allowing installation.

 

My thought is if the package management system could be pimped up to also download/install dependency packages that the whole system would have reached a new level of coolness.  It seems to me that some of the pieces (see the couple of examples above) already exist. 

 

If I were to imagine the best way to implement it would be for .conf files that have dependencies to reference other .conf files down the chain until .conf files with NO remaining dependencies were reached.  Keeping with the one package per .conf would remain requirement necessarry to eliminate version 'confusion'.  Though, dependency version 'conflict' would remain a potential pitfall (i.e. a new version of package A requires an updated version of package B, but the installed .conf file for package B hasn't yet been updated.)

 

 

Link to comment

The only reason for the leading number is so we can control the order in which the packages are installed. 

 

Joe,

 

This hints to one of the reasons I was trying to imagine that the numbering system was first introduced, and that was (maybe) to satisfy dependency requirements.  Well, then as I thought of it more, since unmenu handles each .conf independently, this couldn't be the case.  Anyhow, at that point my brain was already spinning with how to address dependencies.  I'm not familiar enough with bash, awk, cgi, etc... syntax to imagine an exact solution (I'm a MS VB kind of guy so I can almost read/understand your scripting but I can't 'speak' your language(s) yet).  So, I'll share my ideas at a higher level...

All you need is a smattering of "bash shell" syntax, a bit of "GNU awk" syntax, some HTML, a tiny bit of Javascript, some "sed" (stream editor) syntax, a bit of "regular expressions" and you'll be up to speed.

I do a fair about of ASP coding, so I'm somewhat familiar with MS-VB.  The last time I used stand-alone VB was version 3... (probably 15 or so years ago)

 

Good thing is most languages are quite similar... It is just where to put the semi-colons that differs...  ;)   It does help to know a few...

1) I've seen in other .conf files attempts at testing the existance of 'some thing' before continueing with package installation (I think this is what I was reading, anyhow) i.e.:

 

  PACKAGE_INSTALLATION test ! -f /usr/lib/stdc++.so.6.0.8 && installpkg cxxlibs-6.0.8-i486-4.tgz

 

2) The system is already wise enough to know if a package even exists before allowing installation.

 

My thought is if the package management system could be pimped up to also download/install dependency packages that the whole system would have reached a new level of coolness.  It seems to me that some of the pieces (see the couple of examples above) already exist. 

 

If I were to imagine the best way to implement it would be for .conf files that have dependencies to reference other .conf files down the chain until .conf files with NO remaining dependencies were reached.  Keeping with the one package per .conf would remain requirement necessarry to eliminate version 'confusion'.  Though, dependency version 'conflict' would remain a potential pitfall (i.e. a new version of package A requires an updated version of package B, but the installed .conf file for package B hasn't yet been updated.)

Unfortunately, the attempt at numbering the "dependency" stuff is flawed anyway, the "auto_install" files are executed in the order they appear in the "ls" listing of files when the machine is rebooted.  The leading numbers of their affiliated package.conf files are not referenced at all, in fact, at that time, the package.conf files are not used at all.  Their contents have already been parsed and placed in the "auto_install" files.

 

The only thing the leading numbers did was to set the order in which the packages appeared in the package manager listing in unenu.awk.  For that, they did not really add much value.  I honestly think we need to just document the dependencies, make note of any special needs in the package description, and perhaps add logic where possible to the installation itself... in most cases, it will be up to us to manage what we add to out servers.

 

You are correct in that I coded a tiny bit of logic in the install for the missing "C++" library.  That is because if it exists I did not want to install it again.  It overwrites other files and links to a common library name when installed.    There are some things I just like to be cautious about.

Since Tom forgot to include it in the current 4.4-beta-2 , odds are very high it will be in the next beta.  At that point, It just won't install the missing library any more.

 

The "bash" syntax of "test ! -f filename && command_if_test_is_true" works as follows:

 

The "test ! -f" tests if the file exists or not, if it does not exist the "test" command exits with a status of "0" and the subsequent command is executed.   

 

Joe L.

Link to comment

When I read your reply, at first I thought we weren't on the same page or that you might be using your /packages directory for more than for purposes of unmenu package managment. 

 

But, then it occured to me that you are talking about a startup script that consumes the .auto_install scripts in the packages directory and queues them up for package installation in some certain order (based on a leading number in the file name) as a dependency handling mechanisim. 

 

Well, what I'm imagining is a system where the .auto_install scripts are queued in any order.  If dependencies are already installed then the .auto_install script installs the package, else it installs the missing (yet already downloaded, thanks to the .conf script), package.  Oooo... It just occured to me that in order for this to work the dependency handling mechanism I was imagining for the .conf files would have to be extended (at least in part) from the .conf file to the .auto_install file. 

 

The .conf file would have to check to ensure that all dependent packages have been sucessfully downloaded and installed prior to installing the package that the .conf defines.  And, prior to allowing creation of an associated .auto_install script. 

 

The .auto_install have to do the same (at least at this point the .auto_install could safely assume the necessary packages have been downloaded.  At this point in the game proper order of package installation is the only remaining issue).  From what I can tell, at present, the .auto_install scripts are nothing more than pointers to packages that are 'to be installed' at startup and only the file name allows for any control over sequence of installation.

 

Hmmm....  Well, I still believe the mechanism as currently conceived is a wonderful framework.  That's most of the battle.

Link to comment

I tested the changes to 990-unmenu-wget.awk that you suggested.  I renamed one of my .conf files to "pciutils-unmenu-package.conf". 

 

It worked like a CHAMP.  However, I discovered the the PACKAGE_MD5 value was incorrect.  See attached for an updated .conf that should work for everyone. (provided they have made the changes to their 990-unmenu-wget.awk that allow for the alternate .conf file nameing).

 

Link to comment

When I read your reply, at first I thought we weren't on the same page or that you might be using your /packages directory for more than for purposes of unmenu package managment. 

/boot/package holds the downloaded package files, and the package.conf files, and also "if elected" the .manual_install and .auto_install files.

But, then it occurred to me that you are talking about a startup script that consumes the .auto_install scripts in the packages directory and queues them up for package installation in some certain order (based on a leading number in the file name) as a dependency handling mechanism. 

as currently implemented, the .auto_install files are executed in alphabetic  "*.auto_install" order by the one line I either append to the "go" script, or put in a new file I add to /boot/custom/etc/rc.d if that folder exists.

 

That one line finds all the matching *.auto_install, sorts them alphabetically, passes the output (eventually) to sh -c, each in turn.  Basically, they are executed, each in turn, as "sh -c package_name.auto_install" 

That one line is: cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c

 

You can see the order the files are executed by cd'ing to /boot/packages and then typing:

find . -name '*.auto_install' -type f -print | sort

 

The "one line script" again uses the "bash" "&&" operator to only execute the "find ...." if the "cd /boot/packages" is successful.  If something happens where it does not exist, nothing more is executed.

Well, what I'm imagining is a system where the .auto_install scripts are queued in any order.  If dependencies are already installed then the .auto_install script installs the package, else it installs the missing (yet already downloaded, thanks to the .conf script), package.  Oooo... It just occurred to me that in order for this to work the dependency handling mechanism I was imagining for the .conf files would have to be extended (at least in part) from the .conf file to the .auto_install file. 

Exactly, and the complexity goes up, and the need to think of everything up front goes up... 

The .conf file would have to check to ensure that all dependent packages have been sucessfully downloaded and installed prior to installing the package that the .conf defines.  And, prior to allowing creation of an associated .auto_install script. 

 

The .auto_install have to do the same (at least at this point the .auto_install could safely assume the necessary packages have been downloaded.  At this point in the game proper order of package installation is the only remaining issue).  From what I can tell, at present, the .auto_install scripts are nothing more than pointers to packages that are 'to be installed' at startup and only the file name allows for any control over sequence of installation.

Thanks... I'll be happy to refine it based on any input... I know the package-manager plug-in is a beginning... and a framework to build on...  I'm sure it can be improved.

 

There can be multiple PACKAGE_INSTALLATION lines in a .conf file. They can hold multiple commands to be run as a shell script.  If anywhere, that is where the logic needs to be to deal with dependencies...

Hmmm....  Well, I still believe the mechanism as currently conceived is a wonderful framework.  That's most of the battle.

I'm just happy to have had so few complaints about how the whole unmenu.awk interface works... ;D    All I can figure is that it is working, as most all the issues were identified during the initial beta releases.

 

Joe L.

Link to comment

I have used the unmenu web-interface for "pre-testing" on my Windows XP machine (which I am hoping to migrate to unRAID ) to aid me in my testing for data corruption issues related to the nForce4 chipset.

 

The plan was to use unmenu for easy access to my existing NTFS drives on the XP machine, and easy SAMBA sharing in unRAID of those same NTFS mounted drives.

(I would then do a binary file comparison between VERY large files shared through unRAID and the same large files on my Windows Vista machine to check for data corruption issues )

 

I performed the following tasks:

* Copied the unmenu files to the flash drive. The instructions talked about putting them in the /boot directory, so I created a boot directory on the flash drive and copied the files there

* Booted the basic unRAID 4.3 final from the flash drive

* Telnetted into the unRAID machine, and had a look around

* Discovered that the 'boot' directory I had created in the root directory (containg the unmenu files) now was mounted on /boot/boot/

* Moved the unmenu files to /boot on the flash drive from the telnet shell

* Manually started the unmenu interface as per instructions given here in the forum

* Was able to access the web-interface on http://TOWER:8080

* Selected the 'package manager' and attempted to download and install ntfs-3g. Got an error message about wrong checksum

* Found out that the URL for the ntfs-3g in the configuration file was invalid.

* Downloaded  a slightly newer ntfs-3g slackware package from another mirror (did not find the version referenced in the unmask distribution ) to my Vista PC

* Used smbmount on the unRAID machine to access a share on my Windows Vista machine where I had downloaded the alternative ntfs-3g package and copied it from there into the .../packages directory

* Manually installed the ntfs-3g package

* Then I mounted all of my NTFS drives through the unmenu web-interface, and I could also add them as a SAMBA share.

* BUT: I have 5 SATA drives on my system - 4 of them are connected to the onboard nForce4 controller, whereas 1 drive is connected to a Sil3132 PCI-Express x1 controller card

* I was able to successfully mount ALL of the NTFS partitions on all of the drives, BUT for the one drive connected to the Sil3132 controll card, the unmenu web-interface does not reflect that the drive actually has been mounted (I do get a text message at the bottom cofnorming that it is mounted, and it is because I can access the files )

* Since the web-interface somehow does not reflect that one of the drives actually is mounted, I am also not presented with the option of adding as a SAMBA share, which is a pity.

 

See the attached image..This is right after I have pressed the 'Mount /dev/sdf1' button, and the disk has been mounted.

 

 

Link to comment

Oops... looks like a classic off-by-one error in my logic.

 

 

To fix unmenu.awk so you can share that last disk, you can run the following command and it will edit the flawed function in unmenu.awk  (copy and paste it in your telnet window)

sed  -i  "s/0; a < num_partitions/1; a <= num_partitions/"  /boot/unmenu.awk

After you edit it, you will need to stop and re-start unmenu.awk to see the changes

You should be able to stop it with this command:

killall awk

 

The "sed" command will fix the three lines in function GetDiskData()

 

Those three lines are in "for" loops that basically say

for( a = 0; a < num_partitions; a++ ) {

 

They each need to be changed to say "<=" instead of "<" and to also change the "a = 0;" to "a = 1;" as follows

for( a = 1; a <= num_partitions; a++ ) {

 

I'll fix it for the next release in my official copy, but you can fix those three lines your version in the interim.  The effect would be exactly as you described, it would not find where the last disk in the array was mounted.

 

I never expected the program to be used with no protected disks... Very happy it works for you in evaluating your hardware without you having to reformat your disks.

 

Sorry about the bug... I guess now you know the truth... I'm not perfect... ;D

 

Joe L.

Link to comment

I know this is going to be a stupid question but how do I know when a smartctl short test is done??? I click the Short Smart Test button but how do I know when it is finished or if it even ran at all???

 

Thanks,

Not stupid at all...

 

Answered here: http://lime-technology.com/forum/index.php?topic=2110.msg19770#msg19770

 

Note: If no results are posted in the status report, it might be necessary to use a newer version of smartctl that can issue the command to your drives.

 

On my server, the smartctl on older versions of unRAID prior to 4.4-beta2 could not issue the tests on some of my drives.  I had to install the newer version to perform those tests.

 

The version of smartctl on 4.4-beta2 works fine, but only after installing the missing c++ library Tom forgot to include.  Hopefully, 4.4-beta3 will work without any additional effort.

 

Joe L.

Link to comment

Thanks alot. I am still running 4.3.3 so I have the old version. I followed the direction from this post:

http://lime-technology.com/forum/index.php?topic=2097.msg16658#msg16658

 

Now I know I have to add the command to install the libraries on each reboot but should I replace the original smartctl with the new one via the GO script as well and if so how  ;D

 

I am thinking I do if I want to run the smart tests via the unraid menu since the newer version would only be located in the /boot folder not where it really belongs.

 

Thanks,

Link to comment

I currently use the following command in my go script to start unmenu:

 

nohup sh -c "while true; do awk  -W re-interval -f /boot/unmenu.awk; done" >/dev/null 2>&1 &

 

I got this from one of Joe's posts in this thread.  From what I can tell from my testing, this command will output the PID of the process to kill when restarting unmenu.

 

Is there anyway to modify this command so that the PID it produces is recorded in an environment variable???  I googled to no avail and couldn't figure it out for myself.  ???

Link to comment

Thanks alot. I am still running 4.3.3 so I have the old version. I followed the direction from this post:

http://lime-technology.com/forum/index.php?topic=2097.msg16658#msg16658

 

Now I know I have to add the command to install the libraries on each reboot but should I replace the original smartctl with the new one via the GO script as well and if so how  ;D

 

I am thinking I do if I want to run the smart tests via the unraid menu since the newer version would only be located in the /boot folder not where it really belongs.

 

Thanks,

To make it easier on you, here is a unmenu.awk package-manager config file to download and

install the SMART tools version 5.38 (the current version)

 

Put it in the same folder with your other unmenu files (or in the /boot/packages folder, as it will be moved there anyway when you start the package manager.)

 

You can then download the newer smartctl version 5.38 and configure it to be installed each time you reboot.

 

It does depend on the c++ libraries, so don't forget to download and install them too.  (its package-manager .conf is also attached)

 

Joe L.

 

Link to comment

I currently use the following command in my go script to start unmenu:

 

nohup sh -c "while true; do awk  -W re-interval -f /boot/unmenu.awk; done" >/dev/null 2>&1 &

 

I got this from one of Joe's posts in this thread.  From what I can tell from my testing, this command will output the PID of the process to kill when restarting unmenu.

 

Is there anyway to modify this command so that the PID it produces is recorded in an environment variable???  I googled to no avail and couldn't figure it out for myself.  ???

If you are using that line to start up unmenu.awk, then the easiest way to "kill" it and restart it is:

killall  awk

 

It will kill the "awk" process and since it is in a "while" loop, it will start itself back up.

 

The killall command automatically figures out the PID to kill based on the process name.

 

Joe L.

Link to comment

What I was imagining was a user script (button) to kill and restart unmenu.  And, I was going to try to figure out how to make this so I could actually contribute something useful.  I figure this would help with testing changes to unmenu (I require a lot of trial and error as I'm just a pup at all this linux syntax).  The first step was determining the PID, and I figured if the PID were saved as an environment variable I might be able to read that value and then reset it upon restarting unmenu.  All this typing to figure out the PID and then typing the a long string to restart unmenu is tireing.  I'm a little leary of getting too used to using the killall command.  For now unmenu may be the only .awk thing running but that may not always be true in the future.

Link to comment

What I was imagining was a user script (button) to kill and restart unmenu.  And, I was going to try to figure out how to make this so I could actually contribute something useful.  I figure this would help with testing changes to unmenu (I require a lot of trial and error as I'm just a pup at all this linux syntax).  The first step was determining the PID, and I figured if the PID were saved as an environment variable I might be able to read that value and then reset it upon restarting unmenu.  All this typing to figure out the PID and then typing the a long string to restart unmenu is tireing.  I'm a little leary of getting too used to using the killall command.  For now unmenu may be the only .awk thing running but that may not always be true in the future.

Your point is a good one.  It should not be too hard to do what you describe as a "button" to kill the unmenu server.  Problem is, the unmenu process ID can change, so anything stored when it is invoked is soon out of date.

 

Now, when a "user-script" button is pressed, awk invokes it in a sub-shell.  In that shell, the PPID (parent process ID) variable is automatically set.  Now, that is not the unmenu "awk" process id, but its parent is.  We can issue the "ps" command and then look for the PPID of our PPID. (which if you are following this, is the unmenu.awk process)

 

Then..., we need to put the browser back at the main page... we send it a tiny bit of javascript to do that.  "window.location=/"

Lastly, we initiate a process in another process group, in the background, to sleep 10 seconds and then kill the unmenu.awk process.  (This gives it time to send the javascript)

 

Try this "button"  I named the file 1000-unmenu_user_script_restart

#define USER_SCRIPT_LABEL Kill UnMenu

#define USER_SCRIPT_DESCR Kill the unmenu.awk server process.  If it was run in a "while"  loop, it should restart

# The parent of this "button" is a shell, its parent is the awk process we want to kill it to re-start it.

# We need to get the browser back to the main page first... since it will expect to be there when restarted.

# we also need to use nohup to have another process group for the actual sleep 10 seconds/kill, otherwise

# the shell "awk" spawns waits and does not let the javascript get sent to the browser

awk_pid=`ps -fp $PPID | grep -v PPID | awk '{ print $3 }'`

echo "<script type=\"text/javascript\">window.location=\"/\"</script>"

nohup sh -c "sleep 10; kill $awk_pid" 1>/dev/null 2>&1 &

 

Oh yes, to keep from having to type frequently, I have a shell script named "u"  it has as its contents

root@Tower:/boot# cat u

nohup sh -c "while true; do awk  -W re-interval -f /boot/unmenu.awk; done" >/dev/null 2>&1 &

 

I'm lazy... and as I develop unmenu I really need to stop and re-start the unmenu server a LOT.  So I just type

u

and it starts up ( I  don't currently start it up in my "go" script and use killall to stop it)

 

Your idea for the "restart" button is a good one, but probably a tiny bit more complicated than you might have first thought.  I named the new "user-script" button "Kill UnMenu" since that is what it really does.  The description says it will restart unmenu if run in a loop.

 

edit: fixed script tag syntax

Joe L.

Link to comment

If you've made changes to your 990-unmenu-wget.awk to handle alternate .conf file naming then I've got something for you.  See this post for the changes to be made:

 

http://lime-technology.com/forum/index.php?topic=2595.msg21594#msg21594

 

The attached zip contains updated .conf files that define only one package each.  The packages included are:

 

apcupsd-3.14.3-i486-1kjz.tgz

cxxlibs-6.0.8-i486-4.tgz

file-4.21-i486-1.tgz

infozip-5.52-i486-2.tgz

lsof-4.78-i486-1.tgz

ntfs-3g-1.2216-i486-1McD.tgz

pciutils-2.2.10-i486-1.tgz

smartmontools-5.38-i486-1.tgz

wget-1.11.4-i486-1.tgz

 

 

Link to comment
  • Squid locked this topic
Guest
This topic is now closed to further replies.