Biggy2872 Posted January 28, 2009 Share Posted January 28, 2009 OK, Joe... Trusting you more than I trust what I did myself, I chose another download location for the rsync package and also updated the md5sum in the conf file. After making the change you suggested to 990-unmenu-wget.awk, and after updating my conf file, all seems to be working as advertised now. Could you please check it for me. I want to make sure you agree with my work before other people download the conf for their own use. See attached. I really wish I owned the knowledge that you guys have about what is going on in the PACKAGE_VERSION_TEST line. I constructed this by reverse engineering examples from other conf files. I guess this is how we learn, but I can't wait until the day I can write this stuff without having to look at examples!!! looks good, I don't see anything wrong with it. just to give you a heads up on the version string question.... rsync --version 1>&1 | grep version | awk '{print $3}' rsync --version 1>&1 - do rsync version test (i dnon't think the 1>&1 is correct, what it is saying is "redirect stdout to stdout", seems redundant but i could be wrong) you might want to try 2>&1 which means "redirect stderr to stdout", but that is not necessary either... just plain rsync --version worked when i tested it. The output from just this command is as follows: root@Server:~# rsync --version rsync version 2.6.9 protocol version 29 Copyright (C) 1996-2006 by Andrew Tridgell, Wayne Davison, and others. <http://rsync.samba.org/> Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles, inplace, IPv6, 64-bit system inums, 64-bit internal inums rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public Licence for details. The | means to pass the stdout to another program.. in this case grep "version", which finds the line with 'version' in it and returns the whole line to stdout. here is the output of rsync --version | grep 'version' rsync version 2.6.9 protocol version 29 now the last program is awk... awk '{print $3}' finds the Nth "word" on a line as defined by blank spaces (where N is 3 in this case) the result of the whole expression is then 2.6.9 Hope that cleared some things up for you. For more information look up " man grep" and "awk" in google Cheers, Matt Link to comment
Joe L. Posted January 28, 2009 Author Share Posted January 28, 2009 OK, Joe... Trusting you more than I trust what I did myself, I chose another download location for the rsync package and also updated the md5sum in the conf file. If you had opened the file you originally downloaded you would have seen [pre]<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The requested URL /pub/slackware/slackware-current/slackware/n/rsync-3.0.4-i486-1.tgz was not found on this server.</p> <hr> <address>Apache Server at slackware.oregonstate.edu Port 80</address> </body></html>[/pre] Your new URL is much better. This is one place where I really need to improve the package manager. When the MD5 does not match iit is usually because of an error returned from the server saying the version no longer resides there. The file downloaded actually contains the text of the error. I'll need to think about how to best deal with this so you can see the error and not think the download was successful. Obviously, this is only an issue when you are creating the initial MD5 in the package.conf file, as from then on, it will mismatch the checksum if an error on the server occurs. After making the change you suggested to 990-unmenu-wget.awk, and after updating my conf file, all seems to be working as advertised now. Could you please check it for me. I want to make sure you agree with my work before other people download the conf for their own use. See attached. I really wish I owned the knowledge that you guys have about what is going on in the PACKAGE_VERSION_TEST line. I constructed this by reverse engineering examples from other conf files. I guess this is how we learn, but I can't wait until the day I can write this stuff without having to look at examples!!! The line needs one tiny change to be perfectly correct. You have: PACKAGE_VERSION_TEST rsync --version 1>&1 | grep version | awk '{print $3}' It should read: PACKAGE_VERSION_TEST rsync --version 2>&1 | grep version | awk '{print $3}' That part of the command is supposed to send the output of file-descriptor 2 to the same output as file-descriptor 1. In "C" language, &variable is evaluated as the address of "variable" I like to think of 2>&1 as sending file-descriptor 2 (standard error) to the same address as file-descriptor 1 (standard output) Your initial attempt had file-descriptor 1 (standard output) being sent to standard-output, effectively doing nothing to change the output. For future .conf files, this re-direction is needed when the version string is sent by the invoked program to file-descriptor 2 (standard error output). To process this through the following pipeline of commands it needs to be combined with the standard output, as the pipe connecting it to the following "grep" is only reading the standard output on file-descriptor 1. Just an FYI, I did improve the package-manager handling of the mismatched MD5 when the program already has a version installed. You have helped me to improve it for my next release... for now, you will need to delete the existing bad downloaded .tgz file before your version will allow you to download from a different and better URL. At line 308: Old } else { # installed, but different version theHTML = theHTML "<td><font color=\"orange\">Installed, but version is different.<br>" theHTML = theHTML "Current version='" ver_string "' expected '" package_version_string[ i ] "'</font></td>" theHTML = theHTML "<td><input type=submit name=\"manual_install-" package_file[ i ] "\" value=\"Install " package_file[ i ] "\"</td>" } Improved } else { # installed, but different version theHTML = theHTML "<td><font color=\"orange\">Installed, but version is different.<br>" theHTML = theHTML "Current version='" ver_string "' expected '" package_version_string[ i ] "'</font></td>" if ( FileExists( PACKAGE_DIRECTORY "/" package_file[ i ] ) == "yes" ) { if ( VerifyMD5( PACKAGE_DIRECTORY "/" package_file[ i ], package_md5[ i ] ) == "OK" ) { theHTML = theHTML "<td><input type=submit name=\"manual_install-" package_file[ i ] "\" value=\"Install " package_file[ i ] "\"</td>" } else { theHTML = theHTML "<td><b><font color=\"red\"> (MD5 of existing downloaded file NOT matched - download may be corrupted.)</b></font>" theHTML = theHTML "<input type=submit name=\"download-" package_file[ i ] "\" value=\"Download " package_file[ i ] "\"</td>" } } Keep learning... I still am... and I do it by looking at previously written code and trying to understand what the author did. You will quickly find some code is a lot easier to follow than others. A lot depends on the comments and structure and has nothing to do with actual syntax. Joe L. Link to comment
Joe L. Posted January 28, 2009 Author Share Posted January 28, 2009 put a line in your go file that looks like this: # Start up unmenu /boot/unmenu/uu Also, if you have not adopted the Third Party boot structure outlined here then i suggest that you do. We, as a forum, are trying to get people to move towards that structure and it will help move everything forward. I'm guessing I have something wrong here... Here is my unmenu folder when I launch "uu" manually... root@Media:/boot/boot/unmenu# uu and here is the my "go" file. #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & sleep 30 for i in /dev/md* do blockdev --setra 2048 $i done # Start up unmenu /boot/unmenu/uu Yes, apparently you created a "boot" folder, then put the unmenu files in it when the flash drive was on your PC. What you did not realize is the flash drive is mounted at /boot, so you ended up with /boot/boot. Many people have put the files in a folder named "unmenu" and that is what you show in your "go" script. To fix this, log in via telnet and type mv /boot/boot /boot/unmenu That will rename the folder to match the command in your "go" script. Joe L. Link to comment
JarDo Posted January 29, 2009 Share Posted January 29, 2009 For unMenu Package Manger users, here is a link to a zip file containing all my conf files to date. (For some reason this forum won't let me attach a file to a post.) http://www.vhahost.net/bitbucket/unRAID/unmenu_conf_files.zip I've posted this before. Additions since my last post include new conf files for: rsync-3.0.4-i486-1.tgz socat-1.7.0.0-i486-2bj.tgz lm_sensors-3.0.3-i486-1.tgz gamin-0.1.9-i486-1.tgz lighttpd-1.4.19-i486-1mad.tgz The rc.local-unmenu-package.conf file (contained in the archive) is still controversial. It helps me, but may not be compatible with how others are configuring their servers. Feedback is welcome. I'm new to Linux and script writing so I appreciate opinions of others. NOTE: Until Joe L. releases his next version of unMenu, you may have to edit your 990-unmenu-wget.awk if you plan to install the updated rsync package. My understanding is that unRaid already comes with an older version of rsync installed and the modificaion to 990-unmenu-wget.awk will allow overwriting an older version of an installed application with a newer version. See this post for more information: http://lime-technology.com/forum/index.php?topic=2595.msg27198#msg27198 Link to comment
Biggy2872 Posted January 29, 2009 Share Posted January 29, 2009 NOTE: Until Joe L. releases his next version of unMenu, you may have to edit your 990-unmenu-wget.awk if you plan to install the updated rsync package. My understanding is that unRaid already comes with an older version of rsync installed and the modificaion to 990-unmenu-wget.awk will allow overwriting an older version of an installed application with a newer version. See this post for more information: http://lime-technology.com/forum/index.php?topic=2595.msg27198#msg27198 you can install it by manually the first time by doing it in telnet.. download the package manually, and put it in your package directory... Install it in telnet by 1. cd to your package directory 2. run the installpkg line (this is just to be able to get the buttons working, don't worry about all the other "configuration lines") 3. go into package manager and click on the "install on reboot" option (which should now be available, if not you might have some dependent packages to install) 4. either a)reboot, or b)if you know what you are doing, you can run the additional configuration lines in the script to get the package working properly. I've used this a few times(update ntfs-3g for instance) when updating versions of a package... Cheers, Matt Link to comment
Biggy2872 Posted January 31, 2009 Share Posted January 31, 2009 Joe L, I have a feature request for the next version of the package manager plugin... Currently, there is no way to distinguish if the current PACKAGE_INSTALLATION lines in the a .conf are fully reflected in an .auto_install file. Could you add that functionality? I have two ideas on how to do it... But first maybe I should clarify exactly what it is I am talking about. If I installed a package, say for the sake of my argument, the rc.local-unmenu-package.conf. If I were to install this package via the package manager right now, it will populate the auto.intall file with the current lines from the PACKAGE_INSTALLATION lines in the .conf. If I susequently adjusted/edited/added/removed some of those lines in the rc.local-unmenu-package.conf file and replace the old version with the new version and start up the package manager plug-in, the package will appear to be installed correctly with no notion of a potential need to update the .auto_install file. This is because the package manager only looks for the .auto_install file and not its contents. Same theory could be applied to a locally modified package that is later adjusted to contain specific sed/other lines to conform to a specific users configuration (apcupsd for instance). An inexperienced user may add a .conf package and find out later that it is not functioning in their setup, they would adjust the .conf as suggested by others on the forum but assume(or not understand) that the contents of the auto_install file are not yet indicative of the changes they made. They could reboot to their hearts content expecting the change to occur, but never get anywhere. This will also help if a new distributed version of a package is released. Users will not necessarily be knowledgeable enough to be able compare each new .conf with the older version and identify changes that would require them to update the auto_install file(if any existed). With this feature in place, they would be informed by the package manager about the need to update the.auto_install file and be able to correct the issue. The two ways I could see it working with hopefully, little modification on your part are as follows: 1. A "dumb" "update all" button that would search for all the installed packages and recreate their .auto_install files. A very quick fix but not ideal. OR 2. compare the installed .auto_install files with the PACKAGE_INSTALLATION lines their companion .confs and verify that they are the same. If they differ, it could warn the user that the installation script needs to be updated and trigger a button for that .conf in the list to "update .auto_install file". This method is my preference. NOTE: The .manual_install files are not as important for this feature because they are not automatically run and therefore just rebooting and re-applying the manual install would be an acceptable solution, IMHO. However, alerting the user to the need to do this might also be a helpful addition to this feature. Thoughts? Matt Link to comment
JarDo Posted February 4, 2009 Share Posted February 4, 2009 Joe, Could you please tell me how to create a smartctl report just like the one that appears on the Disk Mgmt page, at the console? I tried searching through all your code looking for how to run smartctl to create this report, but I couldn't find it. What I'm trying to do is run the report for a disk that isn't in an array. The Disk Mgmt page only gives this information for disks that are in an array. Link to comment
Biggy2872 Posted February 4, 2009 Share Posted February 4, 2009 Joe, Could you please tell me how to create a smartctl report just like the one that appears on the Disk Mgmt page, at the console? I tried searching through all your code looking for how to run smartctl to create this report, but I couldn't find it. What I'm trying to do is run the report for a disk that isn't in an array. The Disk Mgmt page only gives this information for disks that are in an array. Look at lines 2056 - 2080 in unmenu.awk... the code is already there but there is a comment at line 2058: # SMART features not available on USB and SCSI devices It looks as though it does try and set-up the smart test buttons for other disks outside the array however. I am presented the option to run a smart test on my ide drive not in the protected array... see the here: Running "smarthistory" will collect the data you require as well (provided the drive can provide smart data), and I believe you can set it to collect only data from one drive. Cheers, Matt EDIT: The console/telnet commands for smart can be found in the wiki here: http://www.lime-technology.com/wiki/index.php?title=Troubleshooting#Obtaining_a_SMART_report Link to comment
Biggy2872 Posted February 4, 2009 Share Posted February 4, 2009 Also, Lines 1363-1399 contains the code that is executed to produce the smart reports (sorry I misread you post). for status he uses: smartctl -a -d ata /dev/DEVICE 2>&1 for short test he uses: smartctl -t short /dev/DEVICE 2>&1 and for the long test he uses: smartctl -t long /dev/DEVICE 2>&1 where DEVICE is the name of the drive, for example hda.. sda... etc. In the code he grabs each line outputted by the previously defined command (see above for details of the commands) and outputs it directly to html as preformatted (output as-is). I hope this answers your question. Matt Link to comment
JarDo Posted February 4, 2009 Share Posted February 4, 2009 Thank you. This is what I was looking for: smartctl -a -d ata /dev/DEVICE 2>&1 Actually, I thought I had found that. But when I tried running it the last time (before my post asking for help) it errored. I must have typed something wrong at that time but it seems to be working as advertised now. Link to comment
Mikeperaltag Posted February 4, 2009 Share Posted February 4, 2009 Im one of those that cant find how to install unmenu, where are the instructions? Link to comment
prostuff1 Posted February 4, 2009 Share Posted February 4, 2009 Im one of those that cant find how to install unmenu, where are the instructions? check the wiki Link to comment
jimwhite Posted February 4, 2009 Share Posted February 4, 2009 # SMART features not available on USB and SCSI devices What do "we" have to do to enable it on "scsi" devices which are actually SATA devices.... Link to comment
Biggy2872 Posted February 4, 2009 Share Posted February 4, 2009 # SMART features not available on USB and SCSI devices What do "we" have to do to enable it on "scsi" devices which are actually SATA devices.... That is a very good question... It's not my code and as such I am not perfectly familiar with all the details. Joe L will probably know the best method on which to do this, and may already have a fix because he is aware of the problem (it has been mentioned before). I'll see If I can find anything obvious, if not, I will likely leave it up to Joe L to determine the best course of action. (it really isn't easy trying to figure out 2400+ lines of code someone else wrote) Cheers, Matt Link to comment
Biggy2872 Posted February 4, 2009 Share Posted February 4, 2009 # SMART features not available on USB and SCSI devices What do "we" have to do to enable it on "scsi" devices which are actually SATA devices.... That is a very good question... It's not my code and as such I am not perfectly familiar with all the details. Joe L will probably know the best method on which to do this, and may already have a fix because he is aware of the problem (it has been mentioned before). I'll see If I can find anything obvious, if not, I will likely leave it up to Joe L to determine the best course of action. (it really isn't easy trying to figure out 2400+ lines of code someone else wrote) Cheers, Matt Looking through this thread, I see that Joe L already describe the fix here: http://lime-technology.com/forum/index.php?topic=2595.msg24084#msg24084 He says to: Log in via telnet, cd to the folder with the unmenu files. Then type: sed -i -e "s/\\^scsi-|//" -e "s/and SCSI //" unmenu.awk He uses a sed line to correct the two places where the scsi devices are wrongly ignored. These changes occur on lines 1910 and 2059 where if ( model_serial[a] ~ /^scsi-|^usb-/ ) { is modified to this: if ( model_serial[a] ~ /^usb-/ ) { This should be the solution to the problem you are looking for jimwhite. Cheers, Matt Link to comment
JarDo Posted February 4, 2009 Share Posted February 4, 2009 Which version of unMenu are you running. I believe I'm running the latest version (v1.1) and it appears that this edit already exists in my unmenu.awk. Link to comment
Biggy2872 Posted February 4, 2009 Share Posted February 4, 2009 Which version of unMenu are you running. I believe I'm running the latest version (v1.1) and it appears that this edit already exists in my unmenu.awk. I am running v1.1, I looked in the ORIGINAL as downloaded(downloaded at the end of December, freshly re-unzipped today) version of unmenu.awk in the v1.1 release. It does NOT contain the fix. I also just went to the google page and downloaded the most recent v1.1 files. The unmenu.awk in that package DOES NOT contain the fix. This leads me to believe that you may very well have fixed your v1.1 unmenu.awk on or around Dec 22, 2008 (when Joe L posted the fix) to address this issue. Cheers, Matt Link to comment
JarDo Posted February 5, 2009 Share Posted February 5, 2009 Sorry, my guess is that you are correct. I just have no memory of this at all. I should be better about making notes in the code when I make a change. Link to comment
RobJ Posted February 6, 2009 Share Posted February 6, 2009 ... There are three zip files attached. You will want them all. Unpack them all in the same directory where you want to put all the unmenu files. I suggest a folder name something like /boot/unmenu. ... Joe, this is clear to most of us, especially those with Linux experience, but a little confusing for new Windows-only users. Those with Linux experience automatically think of /boot as the mount point, and /boot/unmenu as a top-level folder of the flash root. But Windows users are used to the root being just '/', with /boot being a sub-folder, and /boot/unmenu being a sub-folder of the sub-folder /boot. So they often create /boot on their flash drive, and install into it. Here's one example. I wonder if a clarifying note could be added to the post above (here), in particular because the Wiki points to that post for downloading and installation instructions. Link to comment
jesseasi Posted February 14, 2009 Share Posted February 14, 2009 Quick question - I know this was covered early on in this thread - and those posts are nearly 3 months old. So I though I should ask again just incase I missed update along the way. Running Unraid 4.4.2 - unmenu does not seem to be able to report any temperatures of the drives. Something to do with smartctrl? Running unraid 4.3.3 - unmenu seems to work fine. Is there an update to unmenu that I missed? Link to comment
RobJ Posted February 14, 2009 Share Posted February 14, 2009 It was covered earlier. The newer smartctl v5.38 (included with v4.4.2) requires the cxxlibs (which aren't included with v4.4.2), so use the Package Manager to install it. Link to comment
Biggy2872 Posted February 25, 2009 Share Posted February 25, 2009 Joe L, I have a feature request for the next version of the package manager plugin... Currently, there is no way to distinguish if the current PACKAGE_INSTALLATION lines in the a .conf are fully reflected in an .auto_install file. Could you add that functionality? I have two ideas on how to do it... But first maybe I should clarify exactly what it is I am talking about. If I installed a package, say for the sake of my argument, the rc.local-unmenu-package.conf. If I were to install this package via the package manager right now, it will populate the auto.intall file with the current lines from the PACKAGE_INSTALLATION lines in the .conf. If I susequently adjusted/edited/added/removed some of those lines in the rc.local-unmenu-package.conf file and replace the old version with the new version and start up the package manager plug-in, the package will appear to be installed correctly with no notion of a potential need to update the .auto_install file. This is because the package manager only looks for the .auto_install file and not its contents. Same theory could be applied to a locally modified package that is later adjusted to contain specific sed/other lines to conform to a specific users configuration (apcupsd for instance). An inexperienced user may add a .conf package and find out later that it is not functioning in their setup, they would adjust the .conf as suggested by others on the forum but assume(or not understand) that the contents of the auto_install file are not yet indicative of the changes they made. They could reboot to their hearts content expecting the change to occur, but never get anywhere. This will also help if a new distributed version of a package is released. Users will not necessarily be knowledgeable enough to be able compare each new .conf with the older version and identify changes that would require them to update the auto_install file(if any existed). With this feature in place, they would be informed by the package manager about the need to update the.auto_install file and be able to correct the issue. The two ways I could see it working with hopefully, little modification on your part are as follows: 1. A "dumb" "update all" button that would search for all the installed packages and recreate their .auto_install files. A very quick fix but not ideal. OR 2. compare the installed .auto_install files with the PACKAGE_INSTALLATION lines their companion .confs and verify that they are the same. If they differ, it could warn the user that the installation script needs to be updated and trigger a button for that .conf in the list to "update .auto_install file". This method is my preference. NOTE: The .manual_install files are not as important for this feature because they are not automatically run and therefore just rebooting and re-applying the manual install would be an acceptable solution, IMHO. However, alerting the user to the need to do this might also be a helpful addition to this feature. Thoughts? Matt bump! - Joe L was away when I posted this originally, hoping he has had a chance to see it.... Also I found a problem with the lm_sensors package... I had just added the lm_sensor package to my package manager. (downloaded from forum, in jarodtufts .zip file here) No version is currently installed, but it is being reported as already installed with an incorrect version... So I took a second look at the .conf for lm_sensor and noticed the problem immediately... the PACKAGE_INSTALLED line for this .conf is currently: PACKAGE_INSTALLED /usr/bin/rsync which is incorrect, it should be: PACKAGE_INSTALLED /usr/bin/sensors this solved the problem of it misidentifying the package as already installed... Cheers, Matt Link to comment
Joe L. Posted February 25, 2009 Author Share Posted February 25, 2009 I've not had any time to get back to making any logic changes to the package manager to detect an updated .conf file vs. and existing auto_install script. It is a good idea, I like it a lot. As far as lm_sensors, you might send a PM to the .conf file author and ask it be corrected. Obviously, it is wrong. It is not one I had ever put on my server. Joe L. Link to comment
JarDo Posted February 25, 2009 Share Posted February 25, 2009 Matt... Good catch. I've fixed the lm_sensors-unmenu-package.conf in the download. Link to comment
Recommended Posts