unMENU 1.5 ... now available for download.


Recommended Posts

  • Replies 1.3k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Yes he did...... very user friendly. thanks to all who made this such a great community

 

Thanks guys.  A little encouragement goes a long way!

 

BTW, you do not want to be deleting your myMain_local.conf.  That file contains local configurations like disk attributes, user specific view settings, etc.  If you make any changes and then delete it to load the update, you've be defeating the purpose for having the local configuration file.

 

There is no harm, however, if you've never modified the file.  But, in general, the file should not be overwritten as updates are made, even if there are some changes to the file version stored in the google code repository.  I take special pains to make sure that the new versions are backward compatible with the existing _local.conf file.

Link to comment

The spin-up occurs as soon as I access http://storage:8080,'>http://storage:8080, and only to the drive that is not part of the array. There is a noticeable delay accessing this page if the drive is not spinning already.

you did not tell me which "main" screen....

 

The one with the graphics (myMain)? or the standard one without?

As soon as I access http://storage:8080

 

So the one without graphics, the one that comes first.

 

I am seeing the same thing. I have 1 disk that is not part of the array. Unmenu main (not myMain) forces it to spin up.

I'll check it out and see if there is anything I can do differently.

 

Joe L.

It turned out it was the use of "fdisk" to get the size of the un-assigned disk that was spinning up the un-assigned drive.  It should be fixed now as I'm using a different approach.  un-assigned disks should not spin up, and the main display should be quicker as it will not be waiting for them to spin up.

 

Joe L.

Link to comment

The spin-up occurs as soon as I access http://storage:8080,'>http://storage:8080, and only to the drive that is not part of the array. There is a noticeable delay accessing this page if the drive is not spinning already.

you did not tell me which "main" screen....

 

The one with the graphics (myMain)? or the standard one without?

As soon as I access http://storage:8080

 

So the one without graphics, the one that comes first.

 

I am seeing the same thing. I have 1 disk that is not part of the array. Unmenu main (not myMain) forces it to spin up.

I'll check it out and see if there is anything I can do differently.

 

Joe L.

It turned out it was the use of "fdisk" to get the size of the un-assigned disk that was spinning up the un-assigned drive.  It should be fixed now as I'm using a different approach.  un-assigned disks should not spin up, and the main display should be quicker as it will not be waiting for them to spin up.

 

Joe L.

Solved! Thanks. I hate to say it but the disk_management screen has the same issue. Too bad I didn't notice it before...

Link to comment

The spin-up occurs as soon as I access http://storage:8080,'>http://storage:8080, and only to the drive that is not part of the array. There is a noticeable delay accessing this page if the drive is not spinning already.

you did not tell me which "main" screen....

 

The one with the graphics (myMain)? or the standard one without?

As soon as I access http://storage:8080

 

So the one without graphics, the one that comes first.

 

I am seeing the same thing. I have 1 disk that is not part of the array. Unmenu main (not myMain) forces it to spin up.

I'll check it out and see if there is anything I can do differently.

 

Joe L.

It turned out it was the use of "fdisk" to get the size of the un-assigned disk that was spinning up the un-assigned drive.  It should be fixed now as I'm using a different approach.  un-assigned disks should not spin up, and the main display should be quicker as it will not be waiting for them to spin up.

 

Joe L.

Solved! Thanks. I hate to say it but the disk_management screen has the same issue. Too bad I didn't notice it before...

Also fixed.  I should have checked it too...  I did not notice it either.  (you are in good company)

 

Joe L.

Link to comment

The spin-up occurs as soon as I access http://storage:8080,'>http://storage:8080, and only to the drive that is not part of the array. There is a noticeable delay accessing this page if the drive is not spinning already.

you did not tell me which "main" screen....

 

The one with the graphics (myMain)? or the standard one without?

As soon as I access http://storage:8080

 

So the one without graphics, the one that comes first.

 

I am seeing the same thing. I have 1 disk that is not part of the array. Unmenu main (not myMain) forces it to spin up.

I'll check it out and see if there is anything I can do differently.

 

Joe L.

It turned out it was the use of "fdisk" to get the size of the un-assigned disk that was spinning up the un-assigned drive.  It should be fixed now as I'm using a different approach.  un-assigned disks should not spin up, and the main display should be quicker as it will not be waiting for them to spin up.

 

Joe L.

 

Thanks Joe!

 

So I wasn't imagining things after all  ;)

Link to comment

This is the error I get in File Browser if I navigate into a directory with a single quote in the name:

 

Jan 14 19:56:51 Beanstalk unmenu[3825]: sh: -c: line 0: unexpected EOF while looking for matching `''

Jan 14 19:56:51 Beanstalk unmenu[3825]: sh: -c: line 1: syntax error: unexpected end of file

 

For example I have a directory named America's Test Kitchen.  If I try to navigate into that directory in the unMENU File Browser, the above errors would occur.  The web page would not display any entries.

Link to comment

I just got unMenu 1371 installed and working. I Downloaded and Installed the jre package, yet when I type "java" command though a telnet session I receive "java: command not found". Have I missed a step or am I completely wrong in thinking "java" should do something? I am trying to setup Serviio and it needs Java in order to run similar to PS3 Media Server.

 

I went into the /etc/profile.d folder and then typed "jre.sh". Now when I type "java", I get the expected output.

Link to comment

Is there some notes or a how-to for creating a package that can be installed by unMenu?  I'd like to try putting SNAP into a package that can be installed from unMenu.

Yes, here: http://lime-technology.com/wiki/index.php?title=UnMENU_documentation

 

That and looking at the existing .conf files in /boot/packages

 

They range from simple to complex.

 

Joe L.

 

Ok, thanks.  Now I made a .conf file and tar'd a folder, copied both to /boot/packages and did some simple testing on unMenu package page.  

When I choose install however it only makes the folder, doesn't untar the files.  

So my question is about package files.  Are they supposed to include the .conf file or what exactly?

 

PACKAGE_NAME SNAP - Share Non-Array Partitions
PACKAGE_DESCR For sharing storage devices that aren't part of the unRAID disk array.
PACKAGE_URL none
PACKAGE_FILE snap-0.47.tgz
PACKAGE_MD5 60dcb3110a23389402df8105e5e653ea
PACKAGE_INSTALLED /boot/config/snappy/snap.sh
PACKAGE_DEPENDENCIES none

# install snap and accompanying files if it is not already installed.  If it is installed we are just changing updating some of the files.
PACKAGE_INSTALLATION SNAP_DIRECTORY=/boot/config/snappy
PACKAGE_INSTALLATION if [ ! -f "${SNAP_DIRECTORY}"/snap.sh ]
PACKAGE_INSTALLATION then
PACKAGE_INSTALLATION mkdir -p "${SNAP_DIRECTORY}"
PACKAGE_INSTALLATION ( cd "${SNAP_DIRECTORY}" ; installpkg "${PACKAGE_DIRECTORY}"/snap-0.47.tgz )
PACKAGE_INSTALLATION fi


PACKAGE_VERSION_TEST snap.sh -v 2>&1
PACKAGE_VERSION_STRING 0.47
PACKAGE_MEMORY_USAGE Light (10K to 500K)

Link to comment

queeg,

 

no expert here ... but i assume that the tgz is normally downloaded to root or maybe tmp

so i assume here you need to change this

 

PACKAGE_FILE snap-0.47.tgz

 

to

 

PACKAGE_FILE /boot/packages/snap-0.47.tgz

 

or wherever you have stored the tgz ?

 

not sure of course ... just being logically minded

never wrote a package

Link to comment

queeg,

 

no expert here ... but i assume that the tgz is normally downloaded to root or maybe tmp

so i assume here you need to change this

 

PACKAGE_FILE snap-0.47.tgz

 

to

 

PACKAGE_FILE /boot/packages/snap-0.47.tgz

 

or wherever you have stored the tgz ?

 

not sure of course ... just being logically minded

never wrote a package

Your advice was wrong.  The PACKAGE_FILE is the name the downloaded file will have when in /boot/packages.  Not the full path.

 

The error, I think is you "tar"d a folder.  You need to create a slackware package if you are going to use installpkg to install it.

 

Otherwise, you need to use "tar" to install it instead.

Link to comment

queeg,

 

no expert here ... but i assume that the tgz is normally downloaded to root or maybe tmp

so i assume here you need to change this

 

PACKAGE_FILE snap-0.47.tgz

 

to

 

PACKAGE_FILE /boot/packages/snap-0.47.tgz

 

or wherever you have stored the tgz ?

 

not sure of course ... just being logically minded

never wrote a package

Your advice was wrong.  The PACKAGE_FILE is the name the downloaded file will have when in /boot/packages.  Not the full path.

 

The error, I think is you "tar"d a folder.  You need to create a slackware package if you are going to use installpkg to install it.

 

Otherwise, you need to use "tar" to install it instead.

 

This is my first time setting up a *package*.

There are two files, the .conf and the .tgz.  So is this correct, I will need to make a .conf file for each new version?  And will the user have to download them and put them into the /boot/packages folder themselves?  There's no way to bundle them together as a single file somehow and have unMenu unpack them into the /boot/packages directory?  

 

 

Link to comment

queeg,

 

no expert here ... but i assume that the tgz is normally downloaded to root or maybe tmp

so i assume here you need to change this

 

PACKAGE_FILE snap-0.47.tgz

 

to

 

PACKAGE_FILE /boot/packages/snap-0.47.tgz

 

or wherever you have stored the tgz ?

 

not sure of course ... just being logically minded

never wrote a package

Your advice was wrong.  The PACKAGE_FILE is the name the downloaded file will have when in /boot/packages.  Not the full path.

 

The error, I think is you "tar"d a folder.  You need to create a slackware package if you are going to use installpkg to install it.

 

Otherwise, you need to use "tar" to install it instead.

 

Is the right way to make a package?  There are two files, the .conf and the .tgz.  Will the user have to download them and put them into the /boot/packages folder themselves?

I didn't see anything in your directions about how to create a package.  I did a little googling about it but was unable to guess the right course of action.

You can supply the PACKAGE_URL for a package to be downloaded automatically.  You will also need to supply a PACKAGE_MD5 line in the package that contains the md5sum checksum of the downloaded file.

 

Take a look at the existing .conf files for lots of examples. 

 

You only need to change the PACKAGE_URL line to something other than "none" for it to do the download automatically.

 

Joe L.

Link to comment

queeg,

 

no expert here ... but i assume that the tgz is normally downloaded to root or maybe tmp

so i assume here you need to change this

 

PACKAGE_FILE snap-0.47.tgz

 

to

 

PACKAGE_FILE /boot/packages/snap-0.47.tgz

 

or wherever you have stored the tgz ?

 

not sure of course ... just being logically minded

never wrote a package

Your advice was wrong.  The PACKAGE_FILE is the name the downloaded file will have when in /boot/packages.  Not the full path.

 

The error, I think is you "tar"d a folder.  You need to create a slackware package if you are going to use installpkg to install it.

 

Otherwise, you need to use "tar" to install it instead.

 

Is the right way to make a package?  There are two files, the .conf and the .tgz.  Will the user have to download them and put them into the /boot/packages folder themselves?

I didn't see anything in your directions about how to create a package.  I did a little googling about it but was unable to guess the right course of action.

You can supply the PACKAGE_URL for a package to be downloaded automatically.  You will also need to supply a PACKAGE_MD5 line in the package that contains the md5sum checksum of the downloaded file.

Take a look at the existing .conf files for lots of examples.  

You only need to change the PACKAGE_URL line to something other than "none" for it to do the download automatically.

 

Joe L.

 

I get PACKAGE_URL can point to a *package*.  But that still means that the .conf file has to exist in the /boot/packages directory - correct?  And does that mean the user has to copy it to that location?  I mean every time I make a new version of the app there will be a new .conf file as I understand it.  Am I missing something?

Maybe I should ask how the .conf files get/got to the /boot/packages directory?  Are they added to unMenu somehow or are the manually copied there?

Link to comment

You are not missing anything.

 

The .conf file can initially be put in either the unmenu directory, or the /boot/packages one.  It will get automatically moved to the /boot/packages directory by the package-manager plugin if you put it in the unmenu directory.    (It is to make it easier for deployment)

 

Yes, the URL and MD5 checksum must change every time you make a change the the downloaded file.

The .conf file has its OWN checksum, as calculated by the unmenu_install script.  It is not in the .conf file itself, but in the master "release_list" file used to perform the download from google.code.  That md5sum excluded the top #UNMENU_RELEASE line in the .conf file that I add when I add it to the official release, and also excludes any PACKAGE_VARIABLE data users might have changed.

 

So yes, any .conf file in the "official" release is under version control, using subversion, on google.code here http://code.google.com/p/unraid-unmenu/  Anybody can add any .conf file of their own, pointing to any URL for download of files from anywhere trusted, but not have it in the official release since it is not in my official release_list as seen here:

http://code.google.com/p/unraid-unmenu/source/browse/trunk/release_list

 

Joe L.

 

 

Link to comment

You are not missing anything.

 

The .conf file can initially be put in either the unmenu directory, or the /boot/packages one.  It will get automatically moved to the /boot/packages directory by the package-manager plugin if you put it in the unmenu directory.    (It is to make it easier for deployment)

 

Yes, the URL and MD5 checksum must change every time you make a change the the downloaded file.

The .conf file has its OWN checksum, as calculated by the unmenu_install script.  It is not in the .conf file itself, but in the master "release_list" file used to perform the download from google.code.  That md5sum excluded the top #UNMENU_RELEASE line in the .conf file that I add when I add it to the official release, and also excludes any PACKAGE_VARIABLE data users might have changed.

 

So yes, any .conf file in the "official" release is under version control, using subversion, on google.code here http://code.google.com/p/unraid-unmenu/   Anybody can add any .conf file of their own, pointing to any URL for download of files from anywhere trusted, but not have it in the official release since it is not in my official release_list as seen here:

http://code.google.com/p/unraid-unmenu/source/browse/trunk/release_list

 

Joe L.

 

Thanks for replying so quickly.  I'm going to digest what you have said.  But at the moment I believe you are saying there is a place on google.code I can add my .conf file to and when unMenu has an official release my new .conf file will be downloaded by unMenu to the packages directory.  But if anyone wants the new app before the official unMenu release, they would need to copy the .conf file manually - correct?

 

I must confess I can't decode this sentence entirely.  What is the it, the .conf file or the package?

Anybody can add any .conf file of their own, pointing to any URL for download of files from anywhere trusted, but not have it in the official release since it is not in my official release_list as seen here

 

Since I don't personally have anywhere to put packages where an http address can reach them, do I need to set up a google.code account or project of my own?

Link to comment

Thanks for replying so quickly.  I'm going to digest what you have said.  But at the moment I believe you are saying there is a place on google.code I can add my .conf file to

Close. Only I can add it to the official release, as only I have permissions to modify what is in my google.code project.
and when unMenu has an official release my new .conf file will be downloaded by unMenu to the packages directory.
It is downlad by unmenu_install to the /boot/unmenu directory.  The first time you run the package-manager, they are moved by it to the /boot/packages directory.
  But if anyone wants the new app before the official unMenu release, they would need to copy the .conf file manually - correct?

Correct.

I must confess I can't decode this sentence entirely.  What is the it, the .conf file or the package?

Anybody can add any .conf file of their own, pointing to any URL for download of files from anywhere trusted, but not have it in the official release since it is not in my official release_list as seen here

The .conf file.  You do not need to be part of the official release to create your own .conf file for your own package.  It is just that it (the .conf file) would need to be downloaded and put in either the /boot/packages directory, or the unmenu directory separately from the unmenu_install process. (or the buttons on the user-scripts page that invoke unmenu_install)

Since I don't personally have anywhere to put packages where an http address can reach them, do I need to set up a google.code account or project of my own?

That might be easiest.  They are free once you set up a gmail account.

I use tortiseSVN on my PC to manage my SVN repository on my unmenu google code project.  You'll need something similar if you use google code and SVN release management for your scripts.  (but you don't need SVN to have a downloadable file in your downloads area, so you can do your version control any way you like)

 

Joe L.

 

Joe L.

Link to comment

Thanks for replying so quickly.  I'm going to digest what you have said.  But at the moment I believe you are saying there is a place on google.code I can add my .conf file to

Close. Only I can add it to the official release, as only I have permissions to modify what is in my google.code project.
and when unMenu has an official release my new .conf file will be downloaded by unMenu to the packages directory.
It is downlad by unmenu_install to the /boot/unmenu directory.  The first time you run the package-manager, they are moved by it to the /boot/packages directory.
  But if anyone wants the new app before the official unMenu release, they would need to copy the .conf file manually - correct?

Correct.

I must confess I can't decode this sentence entirely.  What is the it, the .conf file or the package?

Anybody can add any .conf file of their own, pointing to any URL for download of files from anywhere trusted, but not have it in the official release since it is not in my official release_list as seen here

The .conf file.   You do not need to be part of the official release to create your own .conf file for your own package.  It is just that it (the .conf file) would need to be downloaded and put in either the /boot/packages directory, or the unmenu directory separately from the unmenu_install process. (or the buttons on the user-scripts page that invoke unmenu_install)

Since I don't personally have anywhere to put packages where an http address can reach them, do I need to set up a google.code account or project of my own?

That might be easiest.  They are free once you set up a gmail account.

I use tortiseSVN on my PC to manage my SVN repository on my unmenu google code project.  You'll need something similar if you use google code and SVN release management for your scripts.  (but you don't need SVN to have a downloadable file in your downloads area, so you can do your version control any way you like)

 

Joe L.

 

Joe L.

 

So then I could have the app install procedures create a user_script button that could check for updates and download my new .conf file and put it into the /boot/packages folder where the user would download and install the new version - correct?

Link to comment

Why doesn't something like this work as a user script? It re-starts the programs but then just hangs and unMENU has to be re-started.

 

#define USER_SCRIPT_LABEL Start Python
#define USER_SCRIPT_DESCR Start the Python Programs SAB, SickBeard and CouchPotato
python /mnt/cache/.SABnzbd/SABnzbd.py -d
python /mnt/cache/.SickBeard/SickBeard.py --daemon
python /mnt/cache/.CouchPotato/CouchPotato.py -d

 

Peter

Link to comment

Why doesn't something like this work as a user script? It re-starts the programs but then just hangs and unMENU has to be re-started.

 

#define USER_SCRIPT_LABEL Start Python
#define USER_SCRIPT_DESCR Start the Python Programs SAB, SickBeard and CouchPotato
python /mnt/cache/.SABnzbd/SABnzbd.py -d
python /mnt/cache/.SickBeard/SickBeard.py --daemon
python /mnt/cache/.CouchPotato/CouchPotato.py -d

 

Peter

Because either the standard output or std-error output of one of the commands is still open and unMENU is waiting for it to finish writing to the output before returning the result to your browser.

 

You'll probably need to re-direct the outputs like this:

python /mnt/cache/.SABnzbd/SABnzbd.py -d  >/var/log/sablog 2>&1

python /mnt/cache/.SickBeard/SickBeard.py --daemon >/var/log/sblog 2>&1

python /mnt/cache/.CouchPotato/CouchPotato.py -d >/var/log/cplog 2>&1

 

That way, they go to log files and the unMEU browser will not wait for them.

 

If you do not want the output, send it to /dev/null instead of a log file.  If you do use a log-file, be careful it does not grow to use all available RAM.

 

Joe L.

Link to comment

Joe;

 

Those lines work on the command line and they work in the go script. On the command line the command prompt always returns for each of those lines. The -d and --daemon both put the programs into doemon mode.

 

 

Peter

 

OK, ignore what I said....  But I know it is the cause.  Humor me, try it.

 

Daemon mode does not mean the programmer closed stdout and stderr out properly.  They just probably changed the program group.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.