unMENU 1.6 - now available (A major upgrade in appearance)

I'm having some trouble installing unMENU. I've followed the installation instructions and have unziped the install file into /boot/unmenu. When I then attempt to run the installer nothing downloads and after a few minutes I get the following: "Unable to download release list from http://unraid-unmenu.googlecode/svn/trunk/release_list"

 

I'm currently running an older version of SimpleFeatures because I couldn't get the latest version of that to install either. I do have an internet connection on the server as I can ping various addresses with success.

 

UnRaid version is the latest ver 5RC. What the heck am I doing wrong?

 

 

don;t know...

 

What happens when you type the following:

mkdir /boot/unmenu

cd /boot/unmenu

wget http://unraid-unmenu.googlecode/svn/trunk/release_list

 

Usually it is because you do not have both a nameserver defined or a DNS-server defined in your unRAID settings.  (you need both)

don;t know...

 

What happens when you type the following:

mkdir /boot/unmenu

cd /boot/unmenu

wget http://unraid-unmenu.googlecode/svn/trunk/release_list

 

Usually it is because you do not have both a nameserver defined or a DNS-server defined in your unRAID settings.  (you need both)

 

I'm having a similar problem, cant' download the files for unmenu. It just feels like my whole unraid has fallen to shit to be honest so sad.

Had problems with slow transfers in latest RC, downgraded to Unraid version 4.7, still the same problem.

 

Tower login: root

Linux 2.6.32.9-unRAID.

root@Tower:~# wget http://unraid-unmenu.googlecode/svn/trunk/release_list

--2013-07-07 20:35:59--  http://unraid-unmenu.googlecode/svn/trunk/release_list

Resolving unraid-unmenu.googlecode... failed: Name or service not known.

wget: unable to resolve host address `unraid-unmenu.googlecode'

root@Tower:~#

 

 

don;t know...

 

What happens when you type the following:

mkdir /boot/unmenu

cd /boot/unmenu

wget http://unraid-unmenu.googlecode/svn/trunk/release_list

 

Usually it is because you do not have both a nameserver defined or a DNS-server defined in your unRAID settings.  (you need both)

 

I'm having a similar problem, cant' download the files for unmenu. It just feels like my whole unraid has fallen to shit to be honest so sad.

Had problems with slow transfers in latest RC, downgraded to Unraid version 4.7, still the same problem.

 

Tower login: root

Linux 2.6.32.9-unRAID.

root@Tower:~# wget http://unraid-unmenu.googlecode/svn/trunk/release_list

--2013-07-07 20:35:59--  http://unraid-unmenu.googlecode/svn/trunk/release_list

Resolving unraid-unmenu.googlecode... failed: Name or service not known.

wget: unable to resolve host address `unraid-unmenu.googlecode'

root@Tower:~#

Well... looks like you do not have either a name-server defined, or no DNS server defined.

What do you get when you type:

net lookup google.com

or

net lookup googlecode.com

 

What happens when you type:

ping -c 1 googlecode.com

 

What do you see when you type:

cat /boot/config/netwrk.cfg

 

On my server I get:

cat /boot/config/network.cfg

# Generated settings:

USE_DHCP=no

IPADDR=192.168.2.110

NETMASK=255.255.255.0

GATEWAY=192.168.2.1

HWADDR=

DNS_SERVER1=192.168.2.1

DNS_SERVER2=

DNS_SERVER3=

 

To work properly, you need a GATEWAY defined, and at least one valid DNS server.  In my configuration my ROUTER is at address 192.168.2.1, and it is my gateway to the internet, and also forwards DNS requests to the DNS server defined in its own configuration. (typically this is provided to it by your ISP, but it might be configured manually if you chose otherwise)

 

Those are both configured in the  Settings->Network-Settings section of the unRAID management page. (it updates the config/netwrk.cfg file when you save the new settings)

 

Joe L.

 

 

root@Tower:~# net lookup google.com

74.125.128.101

root@Tower:~# net lookup googlecode.com

74.125.128.147

root@Tower:~# ping -c 1 googlecode.com

PING googlecode.com (74.125.128.147) 56(84) bytes of data.

64 bytes from googlecode.com (74.125.128.147): icmp_seq=1 ttl=37 time=470 ms

 

--- googlecode.com ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 470.027/470.027/470.027/0.000 ms

root@Tower:~# cat /boot/config/netwrk.cfg

cat: /boot/config/netwrk.cfg: No such file or directory

 

I have 2 ethernet adapters on the motherboard. Maybe it's using the wrong one?

root@Tower:~# net lookup google.com

74.125.128.101

root@Tower:~# net lookup googlecode.com

74.125.128.147

root@Tower:~# ping -c 1 googlecode.com

PING googlecode.com (74.125.128.147) 56(84) bytes of data.

64 bytes from googlecode.com (74.125.128.147): icmp_seq=1 ttl=37 time=470 ms

 

--- googlecode.com ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 470.027/470.027/470.027/0.000 ms

root@Tower:~# cat /boot/config/netwrk.cfg

cat: /boot/config/netwrk.cfg: No such file or directory

 

I have 2 ethernet adapters on the motherboard. Maybe it's using the wrong one?

network.cfg, not netwrk.cfg.

 

You can try disabling one of the network adapters.  I see no reason why wget would fail unless blocked by your router or some firewall.

 

HOWEVER, nearly 1/2 second to ping google.com ? ? ? ? ?

 

You are probably timing out.    What kind of connection do you have to your service provider?

 

Joe L.

i just re-installed unmenu latest.. i've noticed that 29-unmenu-sysinfo.awk seems to have a lot of modifications missing... did something happen to this file recently? (svn doesnt show stuff was removed...)

 

snippet from my sysinfo..

  LoadCmds("CPU Info", 
           "ACPI CPU Info;CPU Info;Sensor Info;CPU Freq Info;DMI",
           "acpitool -c;cat /proc/cpuinfo;sensors;cpufreq-info;dmidecode --type=processor",
           ";;Consider installing the lm-sensors package, if your kernel supports hardware monitoring or you have the proper modules (.ko files) available.;;DMI Decode can be installed from the <a href=\"pkg_manager\">unMENU Package Manager.</a>",
           "CPU Info" )

 

current from svn:

LoadCmds("function", "CPU Info", "", "", "CPU Info" );

 

snippet from my sysinfo:

  LoadCmds("Uptime", 
           "Uptime;Uname;;Slackware;Unraid",
           "uptime;uname -a;cat /proc/version;cat /etc/slackware-version;cat /etc/unraid-version",
           "",
           "Up-time");

 

from svn latest:

LoadCmds("exec", "Uptime", "/usr/bin/uptime;/usr/bin/uname -a", "", "Up-time");

nm, i forgot i had tried out this guys changes:

http://lime-technology.com/forum/index.php?topic=27051.msg239955#msg239955

 

they just never made it to the official branch...  joe care to include his changes (will have to backport some of the recent changes back onto it though)

http://lime-technology.com/forum/index.php?topic=27051.msg239990#msg239990

 

nm, i forgot i had tried out this guys changes:

http://lime-technology.com/forum/index.php?topic=27051.msg239955#msg239955

 

they just never made it to the official branch...  tom care to include his changes (will have to backport some of the recent changes back onto it though)

http://lime-technology.com/forum/index.php?topic=27051.msg239990#msg239990

 

unMenu is JoeL's baby, not Tom's

Created an updated apcupsd package (untouched), includes 'sleep' hack (part of package install) for the log rotation.

 

apcupsd-3.14.10-unmenu-package.conf

 

apcupsd-3.14.10-i486-1_rlw.txz installation:
apcupsd: no process killed
Verifying package apcupsd-3.14.10-i486-1_rlw.txz.
Installing package apcupsd-3.14.10-i486-1_rlw.txz:
PACKAGE DESCRIPTION:
# apcupsd (APC UPS Daemon)
#
# Apcupsd can be used for power mangement and controlling most of APC's
# UPS models on Unix and Windows machines. Apcupsd works with most of 
# APC's Smart-UPS models as well as most simple signalling models such 
# as Back-UPS, and BackUPS-Office.
# 
# See /usr/doc/apcupsd-3.14.10/README.SLACKWARE 
# 
Executing install script for apcupsd-3.14.10-i486-1_rlw.txz.
Package apcupsd-3.14.10-i486-1_rlw.txz installed.

Starting apcupsd power management..  Done.
apcupsd-3.14.10-i486-1_rlw.txz is now installed:

 

testing right now, will release later on for others to test with

 

Jul  9 10:07:15 husky apcupsd[4243]: apcupsd 3.14.10 (13 September 2011) slackware startup succeeded
Jul  9 10:07:15 husky apcupsd[4243]: NIS server startup succeeded
Jul  9 10:11:42 husky sSMTP[5188]: Creating SSL connection to host
Jul  9 10:11:43 husky sSMTP[5188]: SSL connection using RC4-MD5
Jul  9 10:11:45 husky sSMTP[5188]: Sent mail for [email protected] (221 2.0.0 BLU0-SMTP98.phx.gbl Service closing transmission channel) uid=0 username=root outbytes=553
Jul  9 10:14:19 husky apcupsd[4243]: Power failure. (Minor Issues)
Jul  9 10:14:25 husky apcupsd[4243]: Running on UPS batteries.
Jul  9 10:14:25 husky sSMTP[5228]: Creating SSL connection to host
Jul  9 10:14:25 husky sSMTP[5231]: Creating SSL connection to host
Jul  9 10:14:25 husky sSMTP[5228]: SSL connection using RC4-MD5
Jul  9 10:14:25 husky sSMTP[5231]: SSL connection using RC4-MD5
Jul  9 10:14:28 husky sSMTP[5231]: Sent mail for [email protected] (221 2.0.0 BLU0-SMTP343.phx.gbl Service closing transmission channel) uid=0 username=root outbytes=566
Jul  9 10:14:32 husky sSMTP[5228]: Sent mail for [email protected] (221 2.0.0 BLU0-SMTP135.phx.gbl Service closing transmission channel) uid=0 username=root outbytes=1574
Jul  9 10:14:43 husky apcupsd[4243]: Mains returned. No longer on UPS batteries.
Jul  9 10:14:43 husky apcupsd[4243]: Power is back. UPS running on mains. (Minor Issues)
Jul  9 10:14:44 husky sSMTP[5271]: Creating SSL connection to host
Jul  9 10:14:44 husky sSMTP[5274]: Creating SSL connection to host
Jul  9 10:14:44 husky sSMTP[5271]: SSL connection using RC4-MD5
Jul  9 10:14:44 husky sSMTP[5274]: SSL connection using RC4-MD5
Jul  9 10:14:47 husky sSMTP[5271]: Sent mail for [email protected] (221 2.0.0 BLU0-SMTP414.phx.gbl Service closing transmission channel) uid=0 username=root outbytes=1602
Jul  9 10:14:47 husky sSMTP[5274]: Sent mail for [email protected] (221 2.0.0 BLU0-SMTP447.phx.gbl Service closing transmission channel) uid=0 username=root outbytes=551

 

so far so good. just need to figure out why i'm getting two emails

one titled 'unRAID_Server_UPS_Alert' for each action then one called 'husky Power Failure !!!' then one 'husky Power has returned'

 

update: so the previous package script took the 'wall' messages and emailed them out.. then the onbattery/offbattery scripts email their own notice. looking through, it appears that using the 'wall' messages via email just results in un-needed e-mail spam. so for now I've removed the line from the package installer that handle that. So really whats left to be tested is the weekly log rotation (can force it to happen early by modifying the it just needs to test to make sure the log rotate works as normal and that the kill ups after shutdown option works.

 

attached .conf for those to test out before joe adds it to the trunk

apcupsd-3.14.10-unmenu-package.conf.txt

Joe, did you run off on holiday?

Joe, did you run off on holiday?

No, just the opposite.  I just started working at a new job on July 1st and have been working late almost every day involved in knowledge-transfer sessions from the prior holder of the position.  There is so much that is not documented anywhere, and most code has very little (if any) comments.  It is not at all like the code I write, where you can follow it even if not a programmer. 

It is a great position at a medium size eCommerce company.  I report to the COO as their new Senior-Systems-Architect.

 

In any case... I've not yet even downloaded your new apcupsd package, but should be able to get to it this weekend.  I want to try it here and figure out how to deal with the other two apcupsd packages.  (If we should add logic to all three to un-install any existing of the three when subsequently installing any of the three as a  replacement)

 

Joe L.

 

 

Joe, did you run off on holiday?

No, just the opposite.  I just started working at a new job on July 1st and have been working late almost every day involved in knowledge-transfer sessions from the prior holder of the position.  There is so much that is not documented anywhere, and most code has very little (if any) comments.  It is not at all like the code I write, where you can follow it even if not a programmer. 

It is a great position at a medium size eCommerce company.  I report to the COO as their new Senior-Systems-Architect.

 

In any case... I've not yet even downloaded your new apcupsd package, but should be able to get to it this weekend.  I want to try it here and figure out how to deal with the other two apcupsd packages.  (If we should add logic to all three to un-install any existing of the three when subsequently installing any of the three as a  replacement)

 

Joe L.

 

Congrats on the new job!

 

" It is not at all like the code I write, where you can follow it even if not a programmer.  ", I hear ya. Even complex code can be made easy to read...

 

Joe, did you run off on holiday?

No, just the opposite.  I just started working at a new job on July 1st and have been working late almost every day involved in knowledge-transfer sessions from the prior holder of the position.  There is so much that is not documented anywhere, and most code has very little (if any) comments.  It is not at all like the code I write, where you can follow it even if not a programmer. 

It is a great position at a medium size eCommerce company.  I report to the COO as their new Senior-Systems-Architect.

 

In any case... I've not yet even downloaded your new apcupsd package, but should be able to get to it this weekend.  I want to try it here and figure out how to deal with the other two apcupsd packages.  (If we should add logic to all three to un-install any existing of the three when subsequently installing any of the three as a  replacement)

 

Joe L.

 

congrats on the job.

 

about that apcupsd script, during the install we kill the previous process and remove the previous .confg (now we do killall apcupsd rather than the recommended rc.apcupsd kill per their docs.. but prob just legacy reasons). so we should be fine there. we use the untouched package and apply the 'sleep' hack via the package install... ive been running this for almost a week now without any problems (still waiting for that weekly log rotate. didnt have the time to go hunt down the cron entry to force it early).

 

i've changed some of the options in the package variable defaults since they seem a bit dated for todays ups (usb / bigger battery / more efficient cpus). Thus for me this now is a simple install as I did not have to change any of the defaults when installing. For example the 'total seconds outage' is only to be used if the daemon cant accurately get the battery level / minutes remaining.. aka, for dumb upses. Since using this option overrides the use of the other calculations.

 

i did remove the 'wall' rewrite from the package as this just resulted in extra emails, since the onbattery/offbattery acpupsd scripts already email. now we could go about adding to those scripts to provide some extra output.. but for right now i'd rather just get this going for everyone so they can upgrade and we can clean out some of these old packages. note that i put a mirror package_url in that apcupsd conf but commented out. didn't know if your package installer supported multiple urls in-case the first one ever goes offline.

 

i just started to work on an updated python-cheetah package. I also have a few other ones that I plan on updating as well..

Zoggy

 

i hope you plan to have a look at the powerdown script too

 

Thanks in advance

Zoggy

 

i hope you plan to have a look at the powerdown script too

 

Thanks in advance

 

the powerdown package? powerdown-1.02-noarch-unRAID.tgz?

Per: http://lime-technology.com/forum/index.php?topic=27862.msg247054#msg247054

seems like the clean powerdown script works fine even on 5.x... the problem with anything like this is if the disk are in use / parity check? / somethign that wont let the system shutdown..  honestly we just need to have Tom give plugin/apps a method to issue the same shutdown process that the emhttp issues. dunno if we could just 'curl' that function..but i'd hate having to go through the emhttp process.

 

dunno, personally i'd not install the clean powerdown and just use the one thats provided with 5.x (happens to have the same name). we should note that 4.x users need that package while 5.x dont..  but not sure what happens if unraid was doing a parity check and all this happened...

Whilst your updating the apcupsd package do you plan on updating the other packages and clearing out the old redundant ones.

 

This sounds like a very good idea, keeps everything current and clean.

 

As always keep up the great work guys.

Whilst your updating the apcupsd package do you plan on updating the other packages and clearing out the old redundant ones.

 

This sounds like a very good idea, keeps everything current and clean.

 

As always keep up the great work guys.

 

yes that would be the goal. unless the package is 4.x/5.x specific... i have plans to address that though.

@Joe L, on the System Info page. Under the cpu info page, the whole content is bold because the closing </b> tag is missing the /.

@Joe L, on the System Info page. Under the cpu info page, the whole content is bold because the closing </b> tag is missing the /.

Thanks. 

@Joe L, on the System Info page. Under the cpu info page, the whole content is bold because the closing </b> tag is missing the /.

This is fixed, and your new apcupsd package is now available for download too.

After messing up with some plugins and restarting my server unmenu's menu bar became text only and with the error below in syslog.

I remove some new installed plugins and restarted again but same again.

Any idea about the problem?

 

Tower unmenu[29135]: tail: option used in invalid context -- 0

 

Edit: and no files in Pkg Manager: No Packages defined in package configuration file(s)

Edit2: i update&restart unmenu from user scripts pkg manager and skin now seems ok.

okay updated apcupsd package again slightly. previously you had to install the clean powerdown package to get it to shutdown (still true for 4.x). but for 5.x users there is the unraid powerdown script (/usr/local/sbin/powerdown) which this will use instead (only if you dont have the clean powerdown package installed).

 

now.. if unraid is in the middle of a parity check or something is holding up the disk and wont let it go for unraid to shutdown.. i'm not sure what either powerdown script does in that scenario. I personally dont have the means to test that but maybe someone kind enough can do so and report back.

 

anyways, Joe please update the unmenu package with this one if all is well with your testing

apcupsd-3.14.10-unmenu-package.conf

Joe, so I know you really want to just do 1 package per .conf file.. which makes sense but then your package manager is just going to grow and grow.

 

So in this scenario what would you recommend? (I'm going to assume you don't know anything about Python in my example so I can paint the picture accurately)

 

Python is a coding language, python 2.x and python 3.x are different languages that just happen to share some similarities but code just wont work between the two languages without making code changes/updating libraries/plugins/etc.

 

Then inside the Python 2.x trunk there are minor versions like python 2.5.x, python 2.6.x, python 2.7.x. In these versions there are features/code that have been added and depending on the api's used in the users code or the libs they may require a certain version to run.

 

For example python 2.5 does not contain any native json support. You would have to include simplejson lib in your app. python 2.6+ included native json support. So you'd either have to include simplejson in your app to provide python 2.5 support or force users to upgrade to a newer version of python.. or the user would have to install the json support.

 

Most python applications/libs it requires a specific python version (major.minor) for it to work. For example SickBeard/Sabnzbd work on python 2.5+ but not on python 3.x.

Then there are forks of Sickbeard that include additional features (which is great) but then they ended up using other python libs that bump the required python version to 2.6 or even 2.7.

 

So, we have a .conf for 'python', which is for 2.6.4. I've made a new one to bump this to the latest in the 2.6.x trunk to 2.6.6. The latest 2.x python is 2.7.5. Which I have a conf for that as well.

 

So we have a .conf for 'python-cheetah', Cheetah is a python plugin that provides template support. It only works for python 2.x (at this time), and the package we use installs into the python 2.6 library folder. Thus, this package is pretty much tied to a python 2.6 install. If you install python 2.7 then try installing the package it errors, because it gets installed to the wrong python library.

 

So in this scenario I have 3 packages:

python-2.6.6-unmenu-package.conf

python-2.7.5-unmenu-package.conf

python_cheetah-2.4.4-unmenu-package.conf

 

cheetah will only install properly for the 2.6.x.

-- Thus do you just not include python 2.7.x since other python libs may not be installed correctly?

-- Do you just include that cheetah package as a option in the python 2.6.x conf?

 

If you look at the sabnzbd package... it requires you to install python on your own. But then it installs all the python libs it depends on itself (which some of them I have updated packages for as well).

 

Then also, what about the order of package installs.. what if it tried to install cheetah but python wasn't installed yet? What if it goes to install sickbeard but cheetah and python arent installed yet?

 

To me,  it really seems that 'cheetah' should be part of the python 2.6.x package as an option. That way you also then can drop the logic in the cheetah package to detect if python is already installed (yours didnt have that.. mine did when I made an update package). This way people wouldn't install python 2.7 and then try installing the cheetah package and wonder why it doesnt work. Also this would allow one place to update python libs vs having to hunt across all the packages and update them if package x,y,z uses the same ones.. 

 

Generally just making everyone upgrade from python 2.6.x to 2.7.x wouldn't be a problem as features are added not removed when going to the newer versions.. but I just haven't found an updated version of the cheetah package installer that works with python 2.7.x. (now you could just d/l cheetah source and install it yourself and it works fine on python 2.7.x.. its just the packaged installer that has the problem).

Looking at the package manager.. there are different indenting formats being used.. its making my ocd go haywire

I started to fix things like convert the random tabs used to spaces, removing trailing spaces, using a standard 4 space tabstop, etc. Just trying to make the code more readable so I could follow the logic of everything. There are just so many packages now the list is getting a bit long and there are multiple copies of the same package (apcupsd)...

 

I was thinking we could pre-pend all the .conf with a semver of the unraid trunk the packages could be placed within. That way you could just key off the filename (since using a variable would require hitting each .conf and reading into it.. could be slow) to split what version of unraid it should fall within.

 

You have a note that: cxxlibs-6.0.9-i486.tgz library accidentally left out of unRAID 4.4-beta2 through 4.5beta5

So showing this in the list for 5.x users is pretty pointless.. it just clutters the list.

 

So a quick example we could do something like:

4.x-cxxlibs-unmenu-package.conf

apcupsd-unmenu-package

5.x-apcupsd-3.14.10-unmenu-package.conf

 

Now how to display/use this info we could go about this two ways:

 

Method 1 (backend segmenting):

In the package manager we just have two tables/fieldsets..  one for 4.x, one for 5.x. We detect what version of unraid the user is running and put that fieldset first. We'd still show all the packages but just segment them logically... and if we create a package that will only work for 5.x we somewhat add a buffer for the user of installing it incorrectly under 4.x as it would be in the other fieldset so they would have had to hunt for it.

 

Now you noticed above there was one without a prefix.. how would we handle these? Do we put them under both sections (do they support both versions)? Do we create yet a 3rd section for the catchalls (untested versions/test versions)?

 

Method 2 (frontend segmenting):

Change the whole output format slightly so that its more in a table output, we then put the required unraid version in its own column.. which we then could just sort the table off of. There is endless amounts of things we could do with this method.. but would be a bit more work.

 

Now if we wanted to go down the road with a table output we then could start doing a bit more things like adding a search/filter/logic to show the data how we want.

I contribute to 'tablesorter' which is a jquery based javascript solution.. we could do a bit of things with this.