https://wiki.amahi.org/api.php?action=feedcontributions&feedformat=atom&user=Matt+ClarkAmahi Wiki - User contributions [en]2026-04-10T07:08:25ZUser contributionsMediaWiki 1.34.2https://wiki.amahi.org/index.php?title=Plex_Media_Server&diff=105521Plex Media Server2016-10-12T02:29:55Z<p>Matt Clark: /* Source Install */</p>
<hr />
<div>{{MessageBox|backgroundcolor = #FBB|<br />
image =Warning.png|<br />
heading =WARNING|<br />
message = Manually upgrading <b>may break the Amahi 7 or greater Plex Media Server app</b> or your HDA.<br />
<br />
<b>Amahi or Plex Inc. cannot provide support to help or correct any issues resulting from this upgrade if you chose to do it.</b>}}<br />
<br />
= Recent "White Page" Issue =<br />
There is an issue in recent releases of the Plex Media Server app. If reaching the server yields a white page, please access it with this work-around link until (Plex fixes the issue): [http://hda:32400/web http://hda:32400/web].<br />
<br />
= Source Install =<br />
<b>WARNING:</b> This is a user contributed tutorial. Proceed with this guide at your own risk. If it breaks your HDA or you need assistance, Amahi cannot provide support.<br />
<br />
This is a quick guide on how to install manually the PlexMediaServer (not the Amahi web app) on Amahi 7 or greater (Fedora). Find out the latest version by checking '''<nowiki>https://plex.tv/downloads</nowiki>''' and copy the link under the Fedora icon. Note that PlexPass users occassionally have access to preview versions of Plex that may contain additional functionality not yet released to other users. Use the toggle to download the preview release if you have a PlexPass.<br />
<br />
* Install the current Plex server version from the link above, where x.x.x.x-xxxxxxx is the current version (1.2.2.2857-d34b464 at October 2017)<br />
:<u>64-bit</u><br />
<pre>wget <nowiki>https://downloads.plex.tv/plex-media-server/x.x.x.x-xxxxxxx/plexmediaserver-x.x.x.x-xxxxxxx.x86_64.rpm</nowiki><br />
sudo yum localinstall plexmediaserver-x.x.x.x-xxxxxxx.x86_64.rpm</pre><br />
:<u>32-bit</u><br />
<pre>wget <nowiki>https://downloads.plex.tv/plex-media-server/x.x.x.x-xxxxxxx/plexmediaserver-x.x.x.x-xxxxxxx.i386.rpm</nowiki><br />
sudo yum localinstall plexmediaserver-x.x.x.x-xxxxxxx.i386.rpm</pre><br />
<br />
* Start the service: Next up we actually have to start Plex, the following command will do just that as well as create a symlink to always start Plex at boot.<br />
sudo systemctl enable plexmediaserver.service && systemctl start plexmediaserver<br />
:<b>NOTE:</b> <i>If you get an error with the above command while connected to the server with SSH through a terminal, it seems you have to relogin as root.</i><br />
<br />
* Run at least once the PlexMediaServer (and do nothing, just run once), from any browser in your network enter <br /><br />
''<nowiki>http://localhost:32400/web/index.html#!/dashboard</nowiki>''<br />
<br />
* Stop the PlexMediaServer (preferably log in with a terminal):<br />
sudo systemctl stop plexmediaserver<br />
<br />
* File permissions and access: Our first big problem (although it’s not really) is to allow Plex to access any of our files. PMS runs as it’s own user (surprisingly a user called plex), not you by default. So we need to give that user access to your files. The easiest way to do this is to add the plex user to your users group. Type the following command in a terminal:<br />
sudo gpasswd -a plex users<br />
<br />
* Restart the PlexMediaServer, wait 1-2 minutes and log in again to edit your libraries:<br />
sudo systemctl start plexmediaserver<br />
<br />
:<b>NOTE:</b> Don't forget if you are using Greyhole, that in this case you have always to use your files "inside" from the [[Mount_Shares_Locally|mounted local files]]<br />
<br />
* Either by auto update (done so around midnight), or if you ask manually for updating the system, amahi will replace the original PlexMediaServer package with it's own amahi-plex (webapp). In order to prevent that you have to exclude the auto-update in the amahi-repo. Edit (as root) /etc/yum.conf (Amahi 8) or /etc/dnf/dnf.conf (Amahi 9) and add the following at the bottom:<br />
exclude=amahi-plex<br />
<br />
= Use with Greyhole =<br />
If you add a library section connected to a folder that is part of your drive pool and thus handled by [[Greyhole]], you should <b>NOT</b> check the option to allow clients to <i>delete media</i> in the Plex Media Server preferences dialog. <br />
<br />
If you want to enable this feature you should [[Mount_Shares_Locally|mount your shares locally]] on your HDA and point [http://www.amahi.org/apps/plex-media-server Plex Media Server] to these mount points instead. Otherwise deletes could cause orphan files in the storage pool since only the symlink would actually be deleted and not the actual file.<br />
<br />
= Locally Mounted Shares (Ubuntu & Fedora) =<br />
If you access your media files using [https://wiki.amahi.org/index.php/Mount_Shares_Locally locally mounted shares] (eg if you are a [https://wiki.amahi.org/index.php/Greyhole Greyhole] user as suggested above), you will need to change the permissions of your plex server user. The Plex Media Server is run by a special user <i>plex</i> who doesnt have access to the local shares by default.<br />
<br />
for <b>Ubuntu</b> <br />
To fix, open terminal as root user and type:<br />
sudo usermod -a -G users plex<br />
<br />
for <b>Fedora</b> <br />
To fix, open terminal as root user and type:<br />
sudo gpasswd -a plex users<br />
<br />
You may need to restart Plex. Now when you want to add directories using the web interface all your shares should be accessible.<br />
<br />
= Update Plex Media Server =<br />
<br />
* If you have installed manually by source the PlexMediaServer, it now has the ability to update itself through the settings' webpage<br />
<br />
* If you are using amahi-plex it will auto update itself as so as the developers push the new version into amahi's repo. Don't try to update the amahi-plex web app although in the setting's webpage it will inform you that a new version of PlexServer is available. Most probably it will fail or it will brake down your system !!!<br />
<br />
= Troubleshooting =<br />
<br />
== Data not shown with Main page login ==<br />
<br />
We noticed that when logging in to <nowiki>http://plexms/</nowiki> plex does not seem to list any data from the plex server, allow you to set up libraries, or allow logins going through this front-door. It does not seem to "be able to connect to this server" on the left side. However, going through <nowiki>http://hda:32400/web/index.html</nowiki> it all works well.<br />
<br />
The work-around is this: going to<br />
<nowiki>http://hda:32400/web/index.html#!/settings/server/</nowiki><br />
Then login to plex on this page and give it a friendly name there."My Amahi server" or similar should do.<br />
<br />
After that, it should show up under <nowiki>http://plexms/</nowiki>.<br />
<br />
== Dashboard Link Workaround ==<br />
If the launch icon and link for Plex Media Server in the dashboard does not properly load the server, you may need to try a workaround.<br />
<br />
First, try just restarting httpd.This should hold for as long as your server is running. <br />
systemctl restart httpd<br />
<br />
If that does not work, or you are restarting your server often, this longer workaround also works. <br />
Start by finding your ####-plexms.conf file in /etc/httpd/conf.d/ Open this file up in a text editor like vi or nano and remove (or comment out) the following two lines: <br />
<br />
ProxyPass / <nowiki>http://hda:32400/manage/</nowiki><br />
ProxyPassReverse / <nowiki>http://hda:32400/manage/</nowiki><br />
<br />
<u>Option 1</u><br /><br />
:Add the following three lines below the two you commented out above:<br />
RewriteEngine On<br />
RewriteCond %{SERVER_PORT} 80<br />
RewriteRule (.*) <nowiki>http://%{HTTP_HOST}:32400/manage/</nowiki> [R,L]<br />
<br />
:After completing the changes, restart httpd<br />
systemctl restart httpd<br />
<br />
<u>Option 2</u><br /><br />
:Create a text file called "index.html" and save that file in /var/hda/web-apps/plexms/html The contents of the file is a simple redirect. It should read:<br />
<br />
<html><br />
<head><meta http-equiv="refresh" content="0; url=<nowiki>http://hda:32400/manage/</nowiki>" /><br />
</head><br />
<body></body></hmtl><br />
<br />
:Set the file ownership permissions:<br />
chown apache:users index.html;<br />
<br />
The Plex Media server page should now load when you click on the icon or link in the dashboard.<br />
<br />
[[Category:apps]]</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Secure_App_Access&diff=93341Secure App Access2015-05-04T00:24:19Z<p>Matt Clark: /* Configure apps */</p>
<hr />
<div>{{MessageBox|<br />
backgroundcolor = #faa|<br />
image =Warning.png|<br />
heading =WARNING|<br />
message = This is recommended only for advanced users, proceed with caution.}}<br />
= Amahi 6 =<br />
This is an example of how to force web app access via HTTPS. For this example, AjaXplorer will be used but this will work with any web app.<br />
<br />
* Go to your config file for apache:<br />
cd /etc/httpd/conf<br />
* Now it is time to create a key and a crt. It will ask you a few questions, just make sure that the '''Common Name''' is the domain name:<br />
openssl genrsa -out filename.key 1024<br />
openssl req -new -key filename.key -x509 -days 1000 -out filename.crt<br />
* Next open up '''/etc/httpd/conf/httpd.conf''' and add the following to the end (skip if you implemented [[Access HDA over SSL]]):<br />
NameVirtualHost *:443<br />
* Open terminal and do (skip if you implemented [[Access HDA over SSL]]):<br />
yum -y install mod_ssl<br />
* Find the file that has ajaxplorer in its name (i.e. '''1026-ajaxplorer.conf'''):<br />
cd /etc/httpd/conf.d<br />
* Edit it to like this (change username.yourhda.com):<br />
<pre><VirtualHost *:443><br />
ServerName ajaxplorer<br />
ServerAlias username.yourhda.com<br />
SSLEngine On<br />
SSLCertificateFile /etc/httpd/conf/filename.crt<br />
SSLCertificateKeyFile /etc/httpd/conf/filename.key<br />
<br />
DocumentRoot /var/hda/web-apps/ajaxplorer/html<br />
<br />
<Directory "/var/hda/web-apps/ajaxplorer/html"><br />
Options Indexes FollowSymLinks +ExecCGI<br />
AddHandler fcgid-script .fcg<br />
AllowOverride AuthConfig<br />
Order allow,deny<br />
Allow from all<br />
</Directory><br />
<br />
</VirtualHost></pre><br />
* Finally create a file called '''1026-ajaxplorerhttp.conf''' (number may be different for you) and add this code (change username.hda.com):<br />
<pre><VirtualHost *:80><br />
ServerName ajaxplorer<br />
ServerAlias username.yourhda.com<br />
RewriteEngine On<br />
RewriteCond %{SERVER_PORT} !^443$<br />
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]<br />
<br />
ExpiresDefault "access plus 10 years"<br />
<br />
AddOutputFilterByType DEFLATE text/html text/plain text/xml<br />
<br />
</VirtualHost></pre><br />
* Now you need to restart apache:<br />
service httpd restart<br />
* And that's all, you now have 128 bit encryption for AjaXplorer. Note that when you uninstall the app, you will need to manually remove the '''1026-ajaxplorerhttp.conf''' file you created.<br />
<br />
= Amahi 7 =<br />
These instructions are for advanced users that wish to set up https access to apps on Amahi 7 (Fedora 19). Use at your own risk.<br />
<br />
== Set up certificates ==<br />
As a root user, run:<br />
<pre>yum install -y openssl mod_ssl<br />
cd /etc/pki/tls/certs <br />
make server.key</pre><br />
You should get prompts to enter and confirm a passphrase. Now we want to remove the passphrase from the private key:<br />
<pre>openssl rsa -in server.key -out server.key </pre><br />
You'll be prompted to add the passphrase again to confirm. Now we make a certificate server request file<br />
<pre>make server.csr</pre><br />
You'll now enter the information that will appear on the certificate request. Make sure that the "Common Name" matches your server domain.<br />
Once you've entered these, you want to generate your private key:<br />
<pre>openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 3650</pre><br />
You should get a message saying Signature ok, with the details for the certificate that you just entered, followed by "Getting private key".<br />
<br />
== Modify httpd==<br />
Still as root, edit /etc/httpd/conf.d/ssl.conf as follows:<br />
<pre>#Line 59: uncomment<br />
DocumentRoot "/var/www/html"<br />
<br />
#Line 60: uncomment and specify server name (use your server name)<br />
ServerName www.exampleserver.com:443<br />
<br />
#Line 100: specify certificate<br />
SSLCertificateFile /etc/pki/tls/certs/server.crt<br />
<br />
#Line 107: specify certification key<br />
SSLCertificateKeyFile /etc/pki/tls/certs/server.key</pre><br />
<br />
== Configure apps==<br />
Go to /etc/httpd/conf.d and edit the conf file for the app you want to move to ssl. For this example I will use owncloud. On my HDA the owncloud conf was 1005-owncould8.conf; the number may differ for you. Remember to back up the original in case you make an error.<br />
<pre>cd /etc/httpd/conf.d<br />
ls -l #check the filename of the relevant conf file.<br />
cp 1005-owncloud8.conf 1006-owncloud8.conf.old<br />
vi 1005-owncloud.conf</pre><br />
Edit your file to change the virtualhost to port 443, and turn on SSL encryption. Your files should look something like the following, with appropriate edits to suit your internal and external server names:<br />
<pre><VirtualHost *:443><br />
<br />
ServerName owncloud8<br />
ServerAlias owncloud8.home.com <br />
ServerAlias owncloud8.exampleserver.com<br />
<br />
SSLEngine On<br />
SSLCertificateFile /etc/pki/tls/certs/server.crt<br />
SSLCertificateKeyFile /etc/pki/tls/certs/server.key<br />
<br />
DocumentRoot /var/hda/web-apps/owncloud8/html<br />
<br />
<Directory "/var/hda/web-apps/owncloud8/html"><br />
Options Indexes FollowSymLinks MultiViews<br />
AllowOverride All<br />
Require all granted<br />
</Directory><br />
<br />
ErrorLog /var/hda/web-apps/owncloud8/logs/error_log<br />
CustomLog /var/hda/web-apps/owncloud8/logs/access_log combined env=!dontlog<br />
<br />
</VirtualHost></pre><br />
<br />
Now we need to redirect http requests to the new https instance. Create a new conf file for the redirect:<br />
vi 1006-owncloud8http.conf (number may be different for you)<br />
and add this code (change the example server to match yours):<br />
<pre><VirtualHost *:80><br />
ServerName owncloud8<br />
ServerAlias owncloud8.home.com <br />
ServerAlias owncloud8.exampleserver.com<br />
RewriteEngine On<br />
RewriteCond %{SERVER_PORT} !^443$<br />
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]<br />
<br />
ExpiresDefault "access plus 10 years"<br />
<br />
AddOutputFilterByType DEFLATE text/html text/plain text/xml<br />
<br />
</VirtualHost></pre><br />
<br />
Now you need to restart httpd. Check that the syntax of your new files is ok before restarting:<br />
httpd -t<br />
If you get an error message, check that the new content in your .conf files matches the information above and make changes as necessary. Once you get a "Syntax OK" message, run (as root)<br />
systemctl restart httpd.service<br />
<br />
== Test Access ==<br />
Direct a browser to the app link and you should now get a https link. Note that your browsers will all give a warning that the certificate is not trusted because it has not been issued by a proper authority. Once you've accepted the warning, you should have an https connection to your app.<br />
<br />
= See also =<br />
[[Access HDA over SSL]]</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Secure_App_Access&diff=93336Secure App Access2015-05-04T00:03:59Z<p>Matt Clark: /* Configure apps */</p>
<hr />
<div>{{MessageBox|<br />
backgroundcolor = #faa|<br />
image =Warning.png|<br />
heading =WARNING|<br />
message = This is recommended only for advanced users, proceed with caution.}}<br />
= Amahi 6 =<br />
This is an example of how to force web app access via HTTPS. For this example, AjaXplorer will be used but this will work with any web app.<br />
<br />
* Go to your config file for apache:<br />
cd /etc/httpd/conf<br />
* Now it is time to create a key and a crt. It will ask you a few questions, just make sure that the '''Common Name''' is the domain name:<br />
openssl genrsa -out filename.key 1024<br />
openssl req -new -key filename.key -x509 -days 1000 -out filename.crt<br />
* Next open up '''/etc/httpd/conf/httpd.conf''' and add the following to the end (skip if you implemented [[Access HDA over SSL]]):<br />
NameVirtualHost *:443<br />
* Open terminal and do (skip if you implemented [[Access HDA over SSL]]):<br />
yum -y install mod_ssl<br />
* Find the file that has ajaxplorer in its name (i.e. '''1026-ajaxplorer.conf'''):<br />
cd /etc/httpd/conf.d<br />
* Edit it to like this (change username.yourhda.com):<br />
<pre><VirtualHost *:443><br />
ServerName ajaxplorer<br />
ServerAlias username.yourhda.com<br />
SSLEngine On<br />
SSLCertificateFile /etc/httpd/conf/filename.crt<br />
SSLCertificateKeyFile /etc/httpd/conf/filename.key<br />
<br />
DocumentRoot /var/hda/web-apps/ajaxplorer/html<br />
<br />
<Directory "/var/hda/web-apps/ajaxplorer/html"><br />
Options Indexes FollowSymLinks +ExecCGI<br />
AddHandler fcgid-script .fcg<br />
AllowOverride AuthConfig<br />
Order allow,deny<br />
Allow from all<br />
</Directory><br />
<br />
</VirtualHost></pre><br />
* Finally create a file called '''1026-ajaxplorerhttp.conf''' (number may be different for you) and add this code (change username.hda.com):<br />
<pre><VirtualHost *:80><br />
ServerName ajaxplorer<br />
ServerAlias username.yourhda.com<br />
RewriteEngine On<br />
RewriteCond %{SERVER_PORT} !^443$<br />
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]<br />
<br />
ExpiresDefault "access plus 10 years"<br />
<br />
AddOutputFilterByType DEFLATE text/html text/plain text/xml<br />
<br />
</VirtualHost></pre><br />
* Now you need to restart apache:<br />
service httpd restart<br />
* And that's all, you now have 128 bit encryption for AjaXplorer. Note that when you uninstall the app, you will need to manually remove the '''1026-ajaxplorerhttp.conf''' file you created.<br />
<br />
= Amahi 7 =<br />
These instructions are for advanced users that wish to set up https access to apps on Amahi 7 (Fedora 19). Use at your own risk.<br />
<br />
== Set up certificates ==<br />
As a root user, run:<br />
<pre>yum install -y openssl mod_ssl<br />
cd /etc/pki/tls/certs <br />
make server.key</pre><br />
You should get prompts to enter and confirm a passphrase. Now we want to remove the passphrase from the private key:<br />
<pre>openssl rsa -in server.key -out server.key </pre><br />
You'll be prompted to add the passphrase again to confirm. Now we make a certificate server request file<br />
<pre>make server.csr</pre><br />
You'll now enter the information that will appear on the certificate request. Make sure that the "Common Name" matches your server domain.<br />
Once you've entered these, you want to generate your private key:<br />
<pre>openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 3650</pre><br />
You should get a message saying Signature ok, with the details for the certificate that you just entered, followed by "Getting private key".<br />
<br />
== Modify httpd==<br />
Still as root, edit /etc/httpd/conf.d/ssl.conf as follows:<br />
<pre>#Line 59: uncomment<br />
DocumentRoot "/var/www/html"<br />
<br />
#Line 60: uncomment and specify server name (use your server name)<br />
ServerName www.exampleserver.com:443<br />
<br />
#Line 100: specify certificate<br />
SSLCertificateFile /etc/pki/tls/certs/server.crt<br />
<br />
#Line 107: specify certification key<br />
SSLCertificateKeyFile /etc/pki/tls/certs/server.key</pre><br />
<br />
== Configure apps==<br />
Go to /etc/httpd/conf.d and edit the conf file for the app you want to move to ssl. For this example I will use owncloud. On my HDA the owncloud conf was 1005-owncould8.conf; the number may differ for you. Remember to back up the original in case you make an error.<br />
<pre>cd /etc/httpd/conf.d<br />
ls -l #check the filename of the relevant conf file.<br />
cp 1005-owncloud8.conf 1006-owncloud8.conf.old<br />
vi 1005-owncloud.conf</pre><br />
Edit your file to change the virtualhost to port 443, and turn on SSL encryption. Your files should look something like the following, with appropriate edits to suit your internal and external server names:<br />
<pre><VirtualHost *:443><br />
<br />
ServerName owncloud8<br />
ServerAlias owncloud8.home.com <br />
ServerAlias owncloud8.exampleserver.com<br />
<br />
SSLEngine On<br />
SSLCertificateFile /etc/pki/tls/certs/server.crt<br />
SSLCertificateKeyFile /etc/pki/tls/certs/server.key<br />
<br />
DocumentRoot /var/hda/web-apps/owncloud8/html<br />
<br />
<Directory "/var/hda/web-apps/owncloud8/html"><br />
Options Indexes FollowSymLinks MultiViews<br />
AllowOverride All<br />
Require all granted<br />
</Directory><br />
<br />
ErrorLog /var/hda/web-apps/owncloud8/logs/error_log<br />
CustomLog /var/hda/web-apps/owncloud8/logs/access_log combined env=!dontlog<br />
<br />
</VirtualHost></pre><br />
<br />
Now we need to redirect http requests to the new https instance. Create a new conf file for the redirect:<br />
<pre>vi 1006-owncloud8http.conf (number may be different for you)</pre><br />
and add this code (change the example server to match yours):<br />
</pre><VirtualHost *:80><br />
ServerName owncloud8<br />
ServerAlias owncloud8.home.com <br />
ServerAlias owncloud8.exampleserver.com<br />
RewriteEngine On<br />
RewriteCond %{SERVER_PORT} !^443$<br />
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]<br />
<br />
ExpiresDefault "access plus 10 years"<br />
<br />
AddOutputFilterByType DEFLATE text/html text/plain text/xml<br />
<br />
</VirtualHost></pre><br />
<br />
Now you need to restart httpd:<br />
<pre>systemctl restart httpd.service</pre><br />
<br />
== Test Access ==<br />
Direct a browser to the app link and you should now get a https link. Note that your browsers will all give a warning that the certificate is not trusted because it has not been issued by a proper authority. Once you've accepted the warning, you should have an https connection to your app.<br />
<br />
= See also =<br />
[[Access HDA over SSL]]</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Pydio&diff=93286Pydio2015-05-03T03:32:11Z<p>Matt Clark: /* Changing the default location of Pydio user data */</p>
<hr />
<div><!-- <br />
This page is crated automaticaly by a script.<br />
This part is commented and shall not show<br />
--><br />
<!--At the top of the page can be vissible one of the following tags..--><br />
<!--{{WorkInProgress}}--><br />
<!--{{NeedsUpdate}}--><br />
<!--{{NeedsMerge | [[Main Page]]}}--><br />
<!--{{NeedsExpantion}}--><br />
<!--{{NeedsDelete |[[Main Page]]}}--><br />
<!--Please remove or place comment accordingly--><br />
<!--Your text bellow this line--><br />
=Changing the location of your shares in Pydio=<br />
By default, the Amahi Pydio app sets up "workspaces" (that is, file repositories which link to the default share location at <code>/var/hda/files/[share]</code>. You might have moved your shares from this location, if for example you use [[Greyhole]] and access your files through local shares at <code>/mnt/samba/[share]</code> (see [[Mount_Shares_Locally]]). Follow these steps to direct Pydio to the right location. If your shares are in a different location you will need to change the <code>/mnt/samba</code> locations below to suit your setup. Note that there is no way to navigate to the shares from the pydio UI, so you will need to make a note somewhere of the exact share locations.<br />
<br />
==1. Find the right settings==<br />
[[file:Pydio shares settings.png|thumb|The "Docs" share is highlighted]]<br />
You can navigate to the Pydio settings from any page, using the dropdown box that appears when you mouseover your user name on the top right of the screen. <br />
<br />
You need to access the "Workspaces" settings, which should be the first on the list. In the Workspaces settings you will see a list of various shares and other "workspaces" set up for the Pydio user. Right click on one of the shares - in this example I will select "Docs". Choose the "Edit" option to go to the settings page for this workspace.<br />
<br />
<br />
==2. Change the settings==<br />
[[file:Pydio_sharelocation.png|thumb|Share file location - default location highlighted]]<br />
Change the default location <code>/var/hda/files/[share]</code> to your desired location - for shares mounted locally use <code>/mnt/samba/[share]</code>. <br />
<br />
Make the same change to all the other shares. You should now be able to access your files through the pydio interface.<br />
<br />
You can create new workspaces from the same location.<br />
<br />
=Changing the default location of Pydio user data=<br />
The default location of user files is hard-coded into the Pydio app, and cannot be changed through the web interface [edit: this may be possible through the web interface at Settings > Workspaces > Common Files, and Settings > Workspaces > My Files. Try changing the file locations here first when logged in as an admin user]. You can change the location of your shares, but if you want to use Pydio to manage user data then you might want to move the default directories to a different location on your drive. For this example I will move the default file locations to a new Amahi share.<br />
<br />
==Create a new share==<br />
Using the Amahi web interface (http://hda), navigate to the "shares" settings, and create a new share called "Pydio". By default this is located in <code>/var/hda/files/pydio</code>. I moved mine to a second hard drive (see [[Adding_a_second_hard_drive_to_your_HDA]] if you need to install a new hard drive), so changed the file location to <code>/var/hda/files/drives/drive1/pydio</code> (click on the new share from the Amahi web interface, and enter the new directory name). However I also use [[Greyhole]], so want to mount the new share locally and manipulate files from that location. See [[Mount_Shares_Locally]] if you need to set this up. To mount the new share locally, restart the mount_shares_locally service (Amahi 7 / Fedora 19 commands shown):<br />
<br />
{{Code|<br />
Code = bash$ sudo systemctl restart mount_shares_locally.service}}<br />
<br />
You can check that the share is correctly mounted using <code>ls -l /mnt/samba</code>. <br />
<br />
==Changing the default location for files in Pydio==<br />
To change the default data directory in Pydio, we need to edit a configuration file which is in the web-apps directory.<br />
<br />
{{Code| Code=sudo vi /var/hda/web-apps/pydio/html/<br />
find the following line in the file (line 36): <br />
"PATH" => "AJXP_DATA_PATH/files",<br />
edit it to:<br />
"PATH" => "/mnt/samba/Pydio/files",<br />
find the following line in the file (line 75): <br />
"PATH" => "AJXP_DATA_PATH/personal/AJXP_USER",<br />
edit to suit your file location:<br />
"PATH" => "/mnt/samba/Pydio/personal/AJXP_USER",<br />
save and close}}<br />
<br />
You can check that the changes came into effect in the Pydio interface, at <code> Settings > Workspaces > Common Files and Settings > Workspaces > My Files<br />
<br />
<br />
<!--Your text above this line--><br />
<!--This page must bellong to one of the following categories please remove comment--><br />
[[category:Apps]]<br />
<!--[[Category:Fedora]]--><br />
<!--[[Category:Platform]]--><br />
<!--[[Category:Pro Version]]--><br />
<!--[[Category:Services]]--><br />
<!--[[Category:VPN]]--></div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Pydio&diff=93281Pydio2015-05-03T03:29:59Z<p>Matt Clark: /* Changing the location of your shares in Pydio */</p>
<hr />
<div><!-- <br />
This page is crated automaticaly by a script.<br />
This part is commented and shall not show<br />
--><br />
<!--At the top of the page can be vissible one of the following tags..--><br />
<!--{{WorkInProgress}}--><br />
<!--{{NeedsUpdate}}--><br />
<!--{{NeedsMerge | [[Main Page]]}}--><br />
<!--{{NeedsExpantion}}--><br />
<!--{{NeedsDelete |[[Main Page]]}}--><br />
<!--Please remove or place comment accordingly--><br />
<!--Your text bellow this line--><br />
=Changing the location of your shares in Pydio=<br />
By default, the Amahi Pydio app sets up "workspaces" (that is, file repositories which link to the default share location at <code>/var/hda/files/[share]</code>. You might have moved your shares from this location, if for example you use [[Greyhole]] and access your files through local shares at <code>/mnt/samba/[share]</code> (see [[Mount_Shares_Locally]]). Follow these steps to direct Pydio to the right location. If your shares are in a different location you will need to change the <code>/mnt/samba</code> locations below to suit your setup. Note that there is no way to navigate to the shares from the pydio UI, so you will need to make a note somewhere of the exact share locations.<br />
<br />
==1. Find the right settings==<br />
[[file:Pydio shares settings.png|thumb|The "Docs" share is highlighted]]<br />
You can navigate to the Pydio settings from any page, using the dropdown box that appears when you mouseover your user name on the top right of the screen. <br />
<br />
You need to access the "Workspaces" settings, which should be the first on the list. In the Workspaces settings you will see a list of various shares and other "workspaces" set up for the Pydio user. Right click on one of the shares - in this example I will select "Docs". Choose the "Edit" option to go to the settings page for this workspace.<br />
<br />
<br />
==2. Change the settings==<br />
[[file:Pydio_sharelocation.png|thumb|Share file location - default location highlighted]]<br />
Change the default location <code>/var/hda/files/[share]</code> to your desired location - for shares mounted locally use <code>/mnt/samba/[share]</code>. <br />
<br />
Make the same change to all the other shares. You should now be able to access your files through the pydio interface.<br />
<br />
You can create new workspaces from the same location.<br />
<br />
=Changing the default location of Pydio user data=<br />
The default location of user files is hard-coded into the Pydio app, and cannot be changed through the web interface. You can change the location of your shares, but if you want to use Pydio to manage user data then you might want to move the default directories to a different location on your drive. For this example I will move the default file locations to a new Amahi share.<br />
<br />
==Create a new share==<br />
Using the Amahi web interface (http://hda), navigate to the "shares" settings, and create a new share called "Pydio". By default this is located in <code>/var/hda/files/pydio</code>. I moved mine to a second hard drive (see [[Adding_a_second_hard_drive_to_your_HDA]] if you need to install a new hard drive), so changed the file location to <code>/var/hda/files/drives/drive1/pydio</code> (click on the new share from the Amahi web interface, and enter the new directory name). However I also use [[Greyhole]], so want to mount the new share locally and manipulate files from that location. See [[Mount_Shares_Locally]] if you need to set this up. To mount the new share locally, restart the mount_shares_locally service (Amahi 7 / Fedora 19 commands shown):<br />
<br />
{{Code|<br />
Code = bash$ sudo systemctl restart mount_shares_locally.service}}<br />
<br />
You can check that the share is correctly mounted using <code>ls -l /mnt/samba</code>. <br />
<br />
==Changing the default location for files in Pydio==<br />
To change the default data directory in Pydio, we need to edit a configuration file which is in the web-apps directory.<br />
<br />
{{Code| Code=sudo vi /var/hda/web-apps/pydio/html/<br />
find the following line in the file (line 36): <br />
"PATH" => "AJXP_DATA_PATH/files",<br />
edit it to:<br />
"PATH" => "/mnt/samba/Pydio/files",<br />
find the following line in the file (line 75): <br />
"PATH" => "AJXP_DATA_PATH/personal/AJXP_USER",<br />
edit to suit your file location:<br />
"PATH" => "/mnt/samba/Pydio/personal/AJXP_USER",<br />
save and close}}<br />
<br />
You can check that the changes came into effect in the Pydio interface, at <code> Settings > Workspaces > Common Files and Settings > Workspaces > My Files<br />
<br />
<br />
<!--Your text above this line--><br />
<!--This page must bellong to one of the following categories please remove comment--><br />
[[category:Apps]]<br />
<!--[[Category:Fedora]]--><br />
<!--[[Category:Platform]]--><br />
<!--[[Category:Pro Version]]--><br />
<!--[[Category:Services]]--><br />
<!--[[Category:VPN]]--></div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Pydio&diff=93276Pydio2015-05-03T03:00:52Z<p>Matt Clark: Created page with "<!-- This page is crated automaticaly by a script. This part is commented and shall not show --> <!--At the top of the page can be vissible one of the following tags..--> <!-..."</p>
<hr />
<div><!-- <br />
This page is crated automaticaly by a script.<br />
This part is commented and shall not show<br />
--><br />
<!--At the top of the page can be vissible one of the following tags..--><br />
<!--{{WorkInProgress}}--><br />
<!--{{NeedsUpdate}}--><br />
<!--{{NeedsMerge | [[Main Page]]}}--><br />
<!--{{NeedsExpantion}}--><br />
<!--{{NeedsDelete |[[Main Page]]}}--><br />
<!--Please remove or place comment accordingly--><br />
<!--Your text bellow this line--><br />
=Changing the location of your shares in Pydio=<br />
By default, the Amahi Pydio app sets up "workspaces" (that is, file repositories" which link to the default share location at <code>/var/hda/files/[share]</code>. You might have moved your shares from this location, if for example you use [[Greyhole]] and access your files through local shares at <code>/mnt/samba/[share]</code> (see [[Mount_Shares_Locally]]). Follow these steps to direct Pydio to the right location. If your shares are in a different location you will need to change the <code>/mnt/samba</code> locations below to suit your setup. Note that there is no way to navigate to the shares from the pydio UI, so you will need to make a note somewhere of the exact share locations.<br />
<br />
==1. Find the right settings==<br />
[[file:Pydio shares settings.png|thumb|The "Docs" share is highlighted]]<br />
You can navigate to the Pydio settings from any page, using the dropdown box that appears when you mouseover your user name on the top right of the screen. <br />
<br />
You need to access the "Workspaces" settings, which should be the first on the list. In the Workspaces settings you will see a list of various shares and other "workspaces" set up for the Pydio user. Right click on one of the shares - in this example I will select "Docs". Choose the "Edit" option to go to the settings page for this workspace.<br />
<br />
<br />
==2. Change the settings==<br />
[[file:Pydio_sharelocation.png|thumb|Share file location - default location highlighted]]<br />
Change the default location <code>/var/hda/files/[share]</code> to your desired location - for shares mounted locally use <code>/mnt/samba/[share]</code>. <br />
<br />
Make the same change to all the other shares. You should now be able to access your files through the pydio interface.<br />
<br />
You can create new workspaces from the same location.<br />
<br />
<br />
<br />
=Changing the default location of Pydio user data=<br />
The default location of user files is hard-coded into the Pydio app, and cannot be changed through the web interface. You can change the location of your shares, but if you want to use Pydio to manage user data then you might want to move the default directories to a different location on your drive. For this example I will move the default file locations to a new Amahi share.<br />
<br />
==Create a new share==<br />
Using the Amahi web interface (http://hda), navigate to the "shares" settings, and create a new share called "Pydio". By default this is located in <code>/var/hda/files/pydio</code>. I moved mine to a second hard drive (see [[Adding_a_second_hard_drive_to_your_HDA]] if you need to install a new hard drive), so changed the file location to <code>/var/hda/files/drives/drive1/pydio</code> (click on the new share from the Amahi web interface, and enter the new directory name). However I also use [[Greyhole]], so want to mount the new share locally and manipulate files from that location. See [[Mount_Shares_Locally]] if you need to set this up. To mount the new share locally, restart the mount_shares_locally service (Amahi 7 / Fedora 19 commands shown):<br />
<br />
{{Code|<br />
Code = bash$ sudo systemctl restart mount_shares_locally.service}}<br />
<br />
You can check that the share is correctly mounted using <code>ls -l /mnt/samba</code>. <br />
<br />
==Changing the default location for files in Pydio==<br />
To change the default data directory in Pydio, we need to edit a configuration file which is in the web-apps directory.<br />
<br />
{{Code| Code=sudo vi /var/hda/web-apps/pydio/html/<br />
find the following line in the file (line 36): <br />
"PATH" => "AJXP_DATA_PATH/files",<br />
edit it to:<br />
"PATH" => "/mnt/samba/Pydio/files",<br />
find the following line in the file (line 75): <br />
"PATH" => "AJXP_DATA_PATH/personal/AJXP_USER",<br />
edit to suit your file location:<br />
"PATH" => "/mnt/samba/Pydio/personal/AJXP_USER",<br />
save and close}}<br />
<br />
You can check that the changes came into effect in the Pydio interface, at <code> Settings > Workspaces > Common Files and Settings > Workspaces > My Files<br />
<br />
<br />
<!--Your text above this line--><br />
<!--This page must bellong to one of the following categories please remove comment--><br />
[[category:Apps]]<br />
<!--[[Category:Fedora]]--><br />
<!--[[Category:Platform]]--><br />
<!--[[Category:Pro Version]]--><br />
<!--[[Category:Services]]--><br />
<!--[[Category:VPN]]--></div>Matt Clarkhttps://wiki.amahi.org/index.php?title=File:Pydio_sharelocation.png&diff=93271File:Pydio sharelocation.png2015-05-03T01:07:45Z<p>Matt Clark: Location of the share files in pydio</p>
<hr />
<div>Location of the share files in pydio</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=File:Pydio_shares_settings.png&diff=93266File:Pydio shares settings.png2015-05-03T00:22:15Z<p>Matt Clark: Matt Clark uploaded a new version of &quot;File:Pydio shares settings.png&quot;: Reverted to version as of 00:16, 3 May 2015</p>
<hr />
<div>Showing the location of shares settings in pydio</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=File:Pydio_shares_settings.png&diff=93261File:Pydio shares settings.png2015-05-03T00:21:53Z<p>Matt Clark: Matt Clark uploaded a new version of &quot;File:Pydio shares settings.png&quot;: Got the wrong file again... other versions can be deleted</p>
<hr />
<div>Showing the location of shares settings in pydio</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=File:Pydio_shares_settings.png&diff=93256File:Pydio shares settings.png2015-05-03T00:16:37Z<p>Matt Clark: Matt Clark uploaded a new version of &quot;File:Pydio shares settings.png&quot;: uploaded the wrong file originally</p>
<hr />
<div>Showing the location of shares settings in pydio</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=File:Pydio_shares_settings.png&diff=93251File:Pydio shares settings.png2015-05-03T00:14:02Z<p>Matt Clark: Showing the location of shares settings in pydio</p>
<hr />
<div>Showing the location of shares settings in pydio</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=File:Pydio_welcome.png&diff=93246File:Pydio welcome.png2015-05-02T23:47:12Z<p>Matt Clark: Matt Clark uploaded a new version of &quot;File:Pydio welcome.png&quot;: smaller version</p>
<hr />
<div>Welcome screen of pydio</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=File:Pydio_welcome.png&diff=93241File:Pydio welcome.png2015-05-02T23:44:06Z<p>Matt Clark: Welcome screen of pydio</p>
<hr />
<div>Welcome screen of pydio</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Secure_App_Access&diff=93236Secure App Access2015-05-02T11:58:42Z<p>Matt Clark: /* See also */</p>
<hr />
<div>{{MessageBox|<br />
backgroundcolor = #faa|<br />
image =Warning.png|<br />
heading =WARNING|<br />
message = This is recommended only for advanced users, proceed with caution.}}<br />
= HTTPS in Amahi 6 and earlier =<br />
'''NOTE:''' This has not been tested with Amahi 7. Following this guidance is at your own risk and could break your HDA. <br />
<br />
This is an example of how to force web app access via HTTPS. For this example, AjaXplorer will be used but this will work with any web app.<br />
<br />
* Go to your config file for apache:<br />
cd /etc/httpd/conf<br />
* Now it is time to create a key and a crt. It will ask you a few questions, just make sure that the '''Common Name''' is the domain name:<br />
openssl genrsa -out filename.key 1024<br />
openssl req -new -key filename.key -x509 -days 1000 -out filename.crt<br />
* Next open up '''/etc/httpd/conf/httpd.conf''' and add the following to the end (skip if you implemented [[Access HDA over SSL]]):<br />
NameVirtualHost *:443<br />
* Open terminal and do (skip if you implemented [[Access HDA over SSL]]):<br />
yum -y install mod_ssl<br />
* Find the file that has ajaxplorer in its name (i.e. '''1026-ajaxplorer.conf'''):<br />
cd /etc/httpd/conf.d<br />
* Edit it to like this (change username.yourhda.com):<br />
<pre><VirtualHost *:443><br />
ServerName ajaxplorer<br />
ServerAlias username.yourhda.com<br />
SSLEngine On<br />
SSLCertificateFile /etc/httpd/conf/filename.crt<br />
SSLCertificateKeyFile /etc/httpd/conf/filename.key<br />
<br />
DocumentRoot /var/hda/web-apps/ajaxplorer/html<br />
<br />
<Directory "/var/hda/web-apps/ajaxplorer/html"><br />
Options Indexes FollowSymLinks +ExecCGI<br />
AddHandler fcgid-script .fcg<br />
AllowOverride AuthConfig<br />
Order allow,deny<br />
Allow from all<br />
</Directory><br />
<br />
</VirtualHost></pre><br />
* Finally create a file called '''1026-ajaxplorerhttp.conf''' (number may be different for you) and add this code (change username.hda.com):<br />
<pre><VirtualHost *:80><br />
ServerName ajaxplorer<br />
ServerAlias username.yourhda.com<br />
RewriteEngine On<br />
RewriteCond %{SERVER_PORT} !^443$<br />
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]<br />
<br />
ExpiresDefault "access plus 10 years"<br />
<br />
AddOutputFilterByType DEFLATE text/html text/plain text/xml<br />
<br />
</VirtualHost></pre><br />
* Now you need to restart apache:<br />
service httpd restart<br />
* And that's all, you now have 128 bit encryption for AjaXplorer. Note that when you uninstall the app, you will need to manually remove the '''1026-ajaxplorerhttp.conf''' file you created.<br />
<br />
= HTTPS for Amahi 7 apps =<br />
These instructions are for advanced users that wish to set up https access to apps on Amahi 7 (Fedora 19). Use at your own risk.<br />
<br />
== 1. Install prerequisite packages and set up certificates ==<br />
As a root user, run:<br />
<pre>yum install -y openssl mod_ssl<br />
cd /etc/pki/tls/certs <br />
make server.key</pre><br />
You should get prompts to enter and confirm a passphrase. Now we want to remove the passphrase from the private key:<br />
<pre>openssl rsa -in server.key -out server.key </pre><br />
You'll be prompted to add the passphrase again to confirm. Now we make a certificate server request file<br />
<pre>make server.csr</pre><br />
You'll now enter the information that will appear on the certificate request. Make sure that the "Common Name" matches your server domain.<br />
Once you've entered these, you want to generate your private key:<br />
<pre>openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 3650</pre><br />
You should get a message saying Signature ok, with the details for the certificate that you just entered, followed by "Getting private key".<br />
<br />
==2. Configure your httpd install for ssl==<br />
Still as root, edit /etc/httpd/conf.d/ssl.conf as follows:<br />
<pre>#Line 59: uncomment<br />
DocumentRoot "/var/www/html"<br />
<br />
#Line 60: uncomment and specify server name (use your server name)<br />
ServerName www.exampleserver.com:443<br />
<br />
#Line 100: specify certificate<br />
SSLCertificateFile /etc/pki/tls/certs/server.crt<br />
<br />
#Line 107: specify certification key<br />
SSLCertificateKeyFile /etc/pki/tls/certs/server.key</pre><br />
<br />
==3. Configure the web apps you want to make accessible by SSL==<br />
Go to /etc/httpd/conf.d and edit the conf file for the app you want to move to ssl. For this example I will use owncloud. On my HDA the owncloud conf was 1005-owncould8.conf; the number may differ for you. Remember to back up the original in case you make an error.<br />
<pre>cd /etc/httpd/conf.d<br />
ls -l #check the filename of the relevant conf file.<br />
cp 1005-owncloud8.conf 1006-owncloud8.conf.old<br />
vi 1005-owncloud.conf</pre><br />
Edit your file to change the virtualhost to port 443, and turn on SSL encryption. Your files should look something like the following, with appropriate edits to suit your internal and external server names:<br />
<pre><VirtualHost *:443><br />
<br />
ServerName owncloud8<br />
ServerAlias owncloud8.home.com <br />
ServerAlias owncloud8.exampleserver.com<br />
<br />
SSLEngine On<br />
SSLCertificateFile /etc/pki/tls/certs/server.crt<br />
SSLCertificateKeyFile /etc/pki/tls/certs/server.key<br />
<br />
DocumentRoot /var/hda/web-apps/owncloud8/html<br />
<br />
<Directory "/var/hda/web-apps/owncloud8/html"><br />
Options Indexes FollowSymLinks MultiViews<br />
AllowOverride All<br />
Require all granted<br />
</Directory><br />
<br />
ErrorLog /var/hda/web-apps/owncloud8/logs/error_log<br />
CustomLog /var/hda/web-apps/owncloud8/logs/access_log combined env=!dontlog<br />
<br />
</VirtualHost></pre><br />
<br />
Now we need to redirect http requests to the new https instance. Create a new conf file for the redirect:<br />
<pre>vi 1006-owncloud8http.conf (number may be different for you) and add this code (change the example server to match yours):<br />
<VirtualHost *:80><br />
ServerName ajaxplorer<br />
ServerAlias owncloud8.home.com <br />
ServerAlias owncloud8.exampleserver.com<br />
RewriteEngine On<br />
RewriteCond %{SERVER_PORT} !^443$<br />
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]<br />
<br />
ExpiresDefault "access plus 10 years"<br />
<br />
AddOutputFilterByType DEFLATE text/html text/plain text/xml<br />
<br />
</VirtualHost></pre><br />
<br />
Now you need to restart apache:<br />
<pre>systemctl restart httpd.service</pre><br />
<br />
==4. Test==<br />
Direct a browser to the app link and you should now get a https link. Note that your browsers will all give a warning that the certificate is not trusted because it has not been issued by a proper authority. Once you've accepted the warning, you should have an https connection to your app.<br />
<br />
= See also =<br />
[[Access HDA over SSL]]</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Secure_App_Access&diff=93231Secure App Access2015-05-02T11:58:08Z<p>Matt Clark: </p>
<hr />
<div>{{MessageBox|<br />
backgroundcolor = #faa|<br />
image =Warning.png|<br />
heading =WARNING|<br />
message = This is recommended only for advanced users, proceed with caution.}}<br />
= HTTPS in Amahi 6 and earlier =<br />
'''NOTE:''' This has not been tested with Amahi 7. Following this guidance is at your own risk and could break your HDA. <br />
<br />
This is an example of how to force web app access via HTTPS. For this example, AjaXplorer will be used but this will work with any web app.<br />
<br />
* Go to your config file for apache:<br />
cd /etc/httpd/conf<br />
* Now it is time to create a key and a crt. It will ask you a few questions, just make sure that the '''Common Name''' is the domain name:<br />
openssl genrsa -out filename.key 1024<br />
openssl req -new -key filename.key -x509 -days 1000 -out filename.crt<br />
* Next open up '''/etc/httpd/conf/httpd.conf''' and add the following to the end (skip if you implemented [[Access HDA over SSL]]):<br />
NameVirtualHost *:443<br />
* Open terminal and do (skip if you implemented [[Access HDA over SSL]]):<br />
yum -y install mod_ssl<br />
* Find the file that has ajaxplorer in its name (i.e. '''1026-ajaxplorer.conf'''):<br />
cd /etc/httpd/conf.d<br />
* Edit it to like this (change username.yourhda.com):<br />
<pre><VirtualHost *:443><br />
ServerName ajaxplorer<br />
ServerAlias username.yourhda.com<br />
SSLEngine On<br />
SSLCertificateFile /etc/httpd/conf/filename.crt<br />
SSLCertificateKeyFile /etc/httpd/conf/filename.key<br />
<br />
DocumentRoot /var/hda/web-apps/ajaxplorer/html<br />
<br />
<Directory "/var/hda/web-apps/ajaxplorer/html"><br />
Options Indexes FollowSymLinks +ExecCGI<br />
AddHandler fcgid-script .fcg<br />
AllowOverride AuthConfig<br />
Order allow,deny<br />
Allow from all<br />
</Directory><br />
<br />
</VirtualHost></pre><br />
* Finally create a file called '''1026-ajaxplorerhttp.conf''' (number may be different for you) and add this code (change username.hda.com):<br />
<pre><VirtualHost *:80><br />
ServerName ajaxplorer<br />
ServerAlias username.yourhda.com<br />
RewriteEngine On<br />
RewriteCond %{SERVER_PORT} !^443$<br />
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]<br />
<br />
ExpiresDefault "access plus 10 years"<br />
<br />
AddOutputFilterByType DEFLATE text/html text/plain text/xml<br />
<br />
</VirtualHost></pre><br />
* Now you need to restart apache:<br />
service httpd restart<br />
* And that's all, you now have 128 bit encryption for AjaXplorer. Note that when you uninstall the app, you will need to manually remove the '''1026-ajaxplorerhttp.conf''' file you created.<br />
<br />
= HTTPS for Amahi 7 apps =<br />
These instructions are for advanced users that wish to set up https access to apps on Amahi 7 (Fedora 19). Use at your own risk.<br />
<br />
== 1. Install prerequisite packages and set up certificates ==<br />
As a root user, run:<br />
<pre>yum install -y openssl mod_ssl<br />
cd /etc/pki/tls/certs <br />
make server.key</pre><br />
You should get prompts to enter and confirm a passphrase. Now we want to remove the passphrase from the private key:<br />
<pre>openssl rsa -in server.key -out server.key </pre><br />
You'll be prompted to add the passphrase again to confirm. Now we make a certificate server request file<br />
<pre>make server.csr</pre><br />
You'll now enter the information that will appear on the certificate request. Make sure that the "Common Name" matches your server domain.<br />
Once you've entered these, you want to generate your private key:<br />
<pre>openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 3650</pre><br />
You should get a message saying Signature ok, with the details for the certificate that you just entered, followed by "Getting private key".<br />
<br />
==2. Configure your httpd install for ssl==<br />
Still as root, edit /etc/httpd/conf.d/ssl.conf as follows:<br />
<pre>#Line 59: uncomment<br />
DocumentRoot "/var/www/html"<br />
<br />
#Line 60: uncomment and specify server name (use your server name)<br />
ServerName www.exampleserver.com:443<br />
<br />
#Line 100: specify certificate<br />
SSLCertificateFile /etc/pki/tls/certs/server.crt<br />
<br />
#Line 107: specify certification key<br />
SSLCertificateKeyFile /etc/pki/tls/certs/server.key</pre><br />
<br />
==3. Configure the web apps you want to make accessible by SSL==<br />
Go to /etc/httpd/conf.d and edit the conf file for the app you want to move to ssl. For this example I will use owncloud. On my HDA the owncloud conf was 1005-owncould8.conf; the number may differ for you. Remember to back up the original in case you make an error.<br />
<pre>cd /etc/httpd/conf.d<br />
ls -l #check the filename of the relevant conf file.<br />
cp 1005-owncloud8.conf 1006-owncloud8.conf.old<br />
vi 1005-owncloud.conf</pre><br />
Edit your file to change the virtualhost to port 443, and turn on SSL encryption. Your files should look something like the following, with appropriate edits to suit your internal and external server names:<br />
<pre><VirtualHost *:443><br />
<br />
ServerName owncloud8<br />
ServerAlias owncloud8.home.com <br />
ServerAlias owncloud8.exampleserver.com<br />
<br />
SSLEngine On<br />
SSLCertificateFile /etc/pki/tls/certs/server.crt<br />
SSLCertificateKeyFile /etc/pki/tls/certs/server.key<br />
<br />
DocumentRoot /var/hda/web-apps/owncloud8/html<br />
<br />
<Directory "/var/hda/web-apps/owncloud8/html"><br />
Options Indexes FollowSymLinks MultiViews<br />
AllowOverride All<br />
Require all granted<br />
</Directory><br />
<br />
ErrorLog /var/hda/web-apps/owncloud8/logs/error_log<br />
CustomLog /var/hda/web-apps/owncloud8/logs/access_log combined env=!dontlog<br />
<br />
</VirtualHost></pre><br />
<br />
Now we need to redirect http requests to the new https instance. Create a new conf file for the redirect:<br />
<pre>vi 1006-owncloud8http.conf (number may be different for you) and add this code (change the example server to match yours):<br />
<VirtualHost *:80><br />
ServerName ajaxplorer<br />
ServerAlias owncloud8.home.com <br />
ServerAlias owncloud8.exampleserver.com<br />
RewriteEngine On<br />
RewriteCond %{SERVER_PORT} !^443$<br />
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]<br />
<br />
ExpiresDefault "access plus 10 years"<br />
<br />
AddOutputFilterByType DEFLATE text/html text/plain text/xml<br />
<br />
</VirtualHost></pre><br />
<br />
Now you need to restart apache:<br />
<pre>systemctl restart httpd.service</pre><br />
<br />
==4. Test==<br />
Direct a browser to the app link and you should now get a https link. Note that your browsers will all give a warning that the certificate is not trusted because it has not been issued by a proper authority. Once you've accepted the warning, you should have an https connection to your app.<br />
<br />
==== See also ====<br />
[[Access HDA over SSL]]</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Squeezebox_Server&diff=84398Squeezebox Server2014-05-22T22:14:39Z<p>Matt Clark: /* unblock-us DNS issue with mysqueezebox.com Workaround (Fedora 19) */</p>
<hr />
<div>== App Fix for Squeezebox Server Upgrade ==<br />
[[Category:Apps]]<br />
[http://www.amahi.org/apps/logitech-media-server Logitech Media Server] (formerly Squeezebox Server) may not work correctly. If it shows the error message:<br />
{{Text|The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.}}<br />
<br />
'''The following steps resolve the issue:'''<br />
<br />
[[Open_Terminal_as_root|Open terminal]] on the HDA enter the following commands and accept all defaults ('''DO NOT''' copy and paste):<br />
{{Code|cpan}}<br />
<br />
'''NOTE:''' At the cpan prompt type <code>force install CGI::Cookie</code> and followed by <code>quit</code> when finished.<br />
<br />
Start squeezeboxserver:<br />
{{Code|service squeezeboxserver start}}<br />
<br />
'''NOTE:''' If you still receive the message above, a restart of the HDA may be required.<br />
<br />
<br />
== Playing AAC files on 64-bit installs ==<br />
Squeezebox server plays AAC files natively, but uses a 32-bit library. On 64-bit machines you may get an error message on your squeezebox saying<br />
{{Text|Problem: Can't open file for: [song title]}}<br />
<br />
A simple fix for this problem is to install the 32-bit glib package. [[Open_Terminal_as_root|Open terminal]] on your HDA and enter the following:<br />
{{Code|yum install glib.i686}} <br />
Your AAC files should play on successful installation.<br />
<br />
(source: [[http://forums.amahi.org/viewtopic.php?f=14&t=2734|this forum post]])<br />
<br />
==Squeezebox and locally mounted shares==<br />
If you access your media files using [https://wiki.amahi.org/index.php/Mount_Shares_Locally locally mounted shares] (eg if you are a [https://wiki.amahi.org/index.php/Greyhole Greyhole] user), you will need to change the permissions of your squeezebox server user. The squeezebox service is run by a special user <i>squeezeboxserver</i> who doesnt have access to the local shares by default.<br />
<br />
To fix, open terminal and type:<br />
{{Code|sudo usermod -a -G users squeezeboxserver}}<br />
<br />
You may need to restart your squeezebox server. Now when you want to add directories to your squeezebox using the web interface all your shares should be accessible.<br />
<br />
<br />
== unblock-us DNS issue with mysqueezebox.com Workaround (Fedora 19) ==<br />
The unblock-us.com domain name servers do not resolve mysqueezebox.com subdomains properly (eg content.mysqueezebox.com, update.mysqueezebox.com). This breaks the MySB network connection for squeezeboxes connected to the server and means they can't play pandora or other apps.<br />
<br />
Workaround:<br />
Amahi 7 uses dnsmasq for the domain name service, which has an option to use an alternative DNS for particular domains (see "using special servers" from the documentation [http://www.thekelleys.org.uk/dnsmasq/docs/setup.html|this here]). We can specify that the Amahi DNS uses the Google or OpenDNS servers instead of unblock-us.com for MySB requests.<br />
<br />
step 1. choose DNS server - I used GoogleDNS (8.8.8.8) but this should work with OpenDNS as well 208.67.222.222<br />
<br />
(optional step 1a. You may wish to make a copy of the dnsmasq.conf file before editing. Type in terminal:<br />
{{Code|sudo cp /etc/dnsmasq.conf /etc/dnsmasq.conf.old}}}<br />
<br />
step 2. add a custom setting to your dnsmasq.conf file using terminal:<br />
<br />
{{Code|sudo vi /etc/dnsmasq.conf}}<br />
<br />
Page down to the very end of the file, then press "i" to insert new text:<br />
<br />
<code>server=/mysqueezebox.com/8.8.8.8</code><br />
<br />
Press esc to exit editing mode, then :w to write to the file, :q to save it and you're done! I restarted the DNS server using the Amahi control panel as well. You can test by directing your browser to update.mysqueezebox.com - it should show a directory.</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Squeezebox_Server&diff=74066Squeezebox Server2013-11-13T22:55:08Z<p>Matt Clark: </p>
<hr />
<div>== App Fix for Squeezebox Server Upgrade ==<br />
[[Category:Apps]]<br />
[http://www.amahi.org/apps/logitech-media-server Logitech Media Server] (formerly Squeezebox Server) may not work correctly. If it shows the error message:<br />
{{Text|The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.}}<br />
<br />
'''The following steps resolve the issue:'''<br />
<br />
[[Open_Terminal_as_root|Open terminal]] on the HDA enter the following commands and accept all defaults ('''DO NOT''' copy and paste):<br />
{{Code|cpan}}<br />
<br />
'''NOTE:''' At the cpan prompt type <code>force install CGI::Cookie</code> and followed by <code>quit</code> when finished.<br />
<br />
Start squeezeboxserver:<br />
{{Code|service squeezeboxserver start}}<br />
<br />
'''NOTE:''' If you still receive the message above, a restart of the HDA may be required.<br />
<br />
<br />
== Playing AAC files on 64-bit installs ==<br />
Squeezebox server plays AAC files natively, but uses a 32-bit library. On 64-bit machines you may get an error message on your squeezebox saying<br />
{{Text|Problem: Can't open file for: [song title]}}<br />
<br />
A simple fix for this problem is to install the 32-bit glib package. [[Open_Terminal_as_root|Open terminal]] on your HDA and enter the following:<br />
{{Code|yum install glib.i686}} <br />
Your AAC files should play on successful installation.<br />
<br />
(source: [[http://forums.amahi.org/viewtopic.php?f=14&t=2734|this forum post]])<br />
<br />
==Squeezebox and locally mounted shares==<br />
If you access your media files using [https://wiki.amahi.org/index.php/Mount_Shares_Locally locally mounted shares] (eg if you are a [https://wiki.amahi.org/index.php/Greyhole Greyhole] user), you will need to change the permissions of your squeezebox server user. The squeezebox service is run by a special user <i>squeezeboxserver</i> who doesnt have access to the local shares by default.<br />
<br />
To fix, open terminal and type:<br />
{{Code|sudo usermod -a -G users squeezeboxserver}}<br />
<br />
You may need to restart your squeezebox server. Now when you want to add directories to your squeezebox using the web interface all your shares should be accessible.<br />
<br />
<br />
== Workaround for unblock-us DNS problems with mysqueezebox.com ==<br />
The unblock-us.com domain name servers do not resolve mysqueezebox.com subdomains properly (eg content.mysqueezebox.com, update.mysqueezebox.com). This breaks the MySB network connection for squeezeboxes connected to the server and means they can't play pandora or other apps.<br />
<br />
Workaround:<br />
Amahi 7 uses dnsmasq for the domain name service, which has an option to use an alternative DNS for particular domains (see "using special servers" from the documentation [http://www.thekelleys.org.uk/dnsmasq/docs/setup.html|this here]). We can specify that the Amahi DNS uses the Google or OpenDNS servers instead of unblock-us.com for MySB requests.<br />
<br />
step 1. choose DNS server - I used GoogleDNS (8.8.8.8) but this should work with OpenDNS as well 208.67.222.222<br />
<br />
(optional step 1a. You may wish to make a copy of the dnsmasq.conf file before editing. Type in terminal:<br />
{{Code|sudo cp /etc/dnsmasq.conf /etc/dnsmasq.conf.old}}}<br />
<br />
step 2. add a custom setting to your dnsmasq.conf file using terminal:<br />
<br />
{{Code|sudo vi /etc/dnsmasq.conf}}<br />
<br />
Page down to the very end of the file, then press "i" to insert new text:<br />
<br />
<code>server=/mysqueezebox.com/8.8.8.8</code><br />
<br />
Press w to write to the file, q to save it and you're done! I restarted the DNS server using the Amahi control panel as well. You can test by directing your browser to update.mysqueezebox.com - it should show a directory.</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Crashplan&diff=74048Crashplan2013-11-13T21:55:10Z<p>Matt Clark: </p>
<hr />
<div>[[Category:Apps]]<br />
==[http://www.amahi.org/apps/crashplan CrashPlan] on Amahi==<br />
<br />
Using CrashPlan on your Amahi HDA will allow you to back up, for free<sup>1</sup>, all your computers into your Amahi HDA<sup>2</sup>.<br/><br />
It will also allow you to become the backup server of friends and family, if you'd like.<br />
<br />
<sup>1</sup> While CrashPlan is free to personal use, an advanced version, CrashPlan+, is available for a fee, if you'd like to get the [http://b1.crashplan.com/consumer/features.html#CrashPlan+ features it adds to the free CrashPlan version].<br/><br />
<sup>2</sup> Technically, it's also possible to backup your HDA into your other computers if you need that.<br />
<br />
==Installing CrashPlan==<br />
<br />
To be able to use CrashPlan, you'll need to install the [http://www.amahi.org/apps/crashplan CrashPlan] application on your Amahi HDA, configure it as needed, and install the CrashPlan application on all the computers you'd like to backup to your HDA.<br />
<br />
==More about CrashPlan==<br />
<br />
To learn more about CrashPlan, you can visit the [http://www.crashplan.com/consumer/features.html CrashPlan website], where features are explained, and where you can watch CrashPlan in action in their [http://b1.crashplan.com/consumer/features-tour.html video tour].<br />
<br />
==CrashPlan Accounts==<br />
<br />
Using CrashPlan requires a (free) CrashPlan account. You'll be able to create a new account from the configuration app itself.<br />
<br />
You'll probably want to use the same account for all computers in your home. That means you'll create the account on the first computer you configure CrashPlan on (it can be your HDA, or any other computer on your home network), and then simply use that same account on all other computers, instead of creating new accounts.<br />
<br />
If you'd like to use different accounts, so that each computer (user) is the sole owner of his backed up files, this is also possible. Trying to restore such files from another computer (this is called a guest restore in CrashPlan) will require the user to enter the owner's password.<br />
<br />
==How to configure CrashPlan on your HDA==<br />
<br />
<p style="color:red">'''NOTE''' The CrashPlan UI sometimes has issues registering button clicks. If you click a button and it seems to do nothing, hit the ENTER key. That seems to help in such cases.</p><br />
<br />
===On the HDA itself===<br />
The easiest way to configure CrashPlan is to access it from the HDA desktop directly.<br />
<br />
Launch a Terminal (Applications > System > Terminal).<br />
<br />
In the terminal window (must run as root user) enter:<br />
<br />
<u>Fedora</u>: <br />
{{Code|su -<br />
CrashPlanDesktop}}<br />
<br />
<u>Ubuntu</u>: <br />
{{Code|sudo CrashPlanDesktop}}<br />
<br />
If you don't have physical access to your HDA, or if you run it headless, try the methods below.<br />
<br />
===Using VNC===<br />
If you have [[VNC]] or [[WebVNC]] setup, you can use that to configure CrashPlan remotely, instead of using the OS-dependent methods described below.<br />
<br />
Simply connect to your HDA using VNC (or WebVNC), and launch a Terminal (Applications > System > Terminal).<br />
<br />
In the terminal window enter the same commands as noted above depending on the OS you are running on your HDA.<br />
<br />
The CrashPlan configuration application will start.<br />
<br />
===Using X-Forwarding===<br />
To use X-Forwarding, you don't need X running, or even installed on your HDA.<br/><br />
All you need is an X server on your client computer, and to SSH into your HDA with X-Forwarding enabled.<br />
<br />
====Windows====<br />
=====PuTTY and Xming=====<br />
You'll need two things to be able to configure CrashPlan from Windows: PuTTY and Xming.<br />
<br />
For PuTTY, just download putty.exe from [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html here]. You can leave it on your desktop and use it from there.<br/><br />
For Xming, you'll need to download and install two files: the [https://sourceforge.net/projects/xming/files/Xming/ Xming installer], and the [https://sourceforge.net/projects/xming/files/Xming-fonts/ fonts installer].<br/><br />
You can accept all the default values for both installs.<br />
<br />
Now, you should have a start menu item for Xming. Start it from there. You should now have a black X icon in your system tray.<br />
<br />
Next, start PuTTY, and enter your HDA IP address under ''Host Name (or IP address)'', enter 22 under ''Port'' and select SSH under ''Connection Type''.<br />
<br />
[[Image:Red-S01.png]]<br />
<br />
Open the ''Connection > SSH'' item in the ''Category'' tree on the left, and select ''X11''.<br/><br />
Select the checkbox that says ''Enable X11 forwarding''.<br />
<br />
Now go back into ''Session'' in the ''Category'' tree, and give a name for this profile, so you won't have to repeat those steps next time.<br/><br />
Enter a name in the ''Saved Sessions'' text box, and hit the ''Save'' button on the right.<br/><br />
Next time your start PuTTY, you'll be able to just double-click your profile in the ''Saved Sessions'' section to connect to your HDA with X11 forwarding enabled.<br />
<br />
Now, connect to your HDA by clicking ''Open'', or double-clicking your profile name in the Saved Sessions select box (on the left of the Load, Save and Delete buttons).<br />
<br />
Enter your Fedora username and password when prompted.<br />
<br />
=====FreeXer=====<br />
FreeXer is an open source attempt to make X11 forwarding easy. It consists of PuTTY and Cygwin with a wrapper that configures both to enable X11 forwarding.<br />
<br />
First, download FreeXer [http://downloads.sourceforge.net/project/freexer/FreeXer/0.2/freeXer-installer.exe here].<br />
<br />
Once installed, open the "freeXer Session Editor" and enter a name for the session you're about to start under ''Session'', enter your HDA IP address under ''Host'', select SSH under ''Protocol'', enter your Fedora username under ''User'' and password under ''Password''. <br />
<br />
[[Image:Sess_editor_new.png]]<br />
<br />
Click on the ''Save'' button to save the session information. Once you saved the session information, the next time you need it you only need to open the session information file (or load it into the session editor) and you're done.<br />
<br />
When ready, click on the ''Launch Session'' button.<br />
<br />
=====Once logged in=====<br />
Enter the following command to start the CrashPlan configuration UI:<br />
<br />
Enter the same commands as noted above for the OS you are running on your HDA.<br />
<br />
=====Guides=====<br />
There are many guides available online that explain the steps of X11 forwarding. Here's some, if you need further help:<br />
*[http://www.youtube.com/v/EsHuZJ5gORE?hl=en_US&fs=1 X Windows Forwarding video on YouTube]<br />
*[http://www.cs.caltech.edu/courses/cs11/misc/xwindows.html Using X Forwarding on Windows at Caltech]<br />
* [http://www.math.umn.edu/systems_guide/putty_xwin32.html X Forwarding with Putty on Windows at University of Minnesota]<br />
<br />
====Mac OS X====<br />
Open a Terminal (Applications > Utilities > Terminal.app)<br/><br />
and enter the following commands:<br />
<br />
{{Code|ssh -X hda}}<br />
<br />
Then enter the same commands as outlined above for the OS you are running on the HDA.<br />
<br />
Once you're done with the CrashPlan configuration, you can close the CrashPlan app, the X11.app that appeared in your Dock, and Terminal.app<br />
<br />
====Linux====<br />
<br />
Starting on your X desktop (Gnome, KDE, ...), open a Terminal (Applications >System > Terminal in Fedora)<br/><br />
and enter the following commands:<br />
{{Code|ssh -X hda}}<br />
<br />
Follow the commands above for the specific OS you are running on your HDA.<br />
<br />
Once you're done with the CrashPlan configuration, you can close the CrashPlan app, and the Terminal.<br />
<br />
===Using a local CrashPlan client===<br />
<br />
You can follow the instructions on the CrashPlan wiki on [http://support.crashplan.com/doku.php/how_to/configure_a_headless_client how to connect to a headless CrashPlan install].<br />
<br />
It requires you to install CrashPlan on your client computer, manually editing a config file, and using SSH port forwarding.<br />
<br />
==Troubleshooting==<br />
<br />
===Fixing Java RTE errors on the CrashPlan desktop===<br />
<br />
If you use the CrashPlan desktop on version 3.5.3 you may experience a Java error - when starting the Crashplan desktop the splash image shows for a few seconds, and then vanishes, but the application doesn't open.<br />
<br />
It appears that CrashPlan 3.5.3 bundles a buggy version of the "Eclipse Standard Widget Toolkit". To fix, you just need to replace that toolkit with the latest one from the developer.<br />
<br />
<p color=red><b>Note that the fix below applies to Amahi 7 (Fedora 19) ONLY.</b></p><br />
Download swt-4.3-gtk-linux-x86.zip and swt-4.3-gtk-linux-x86_64.zip from [http://download.eclipse.org/eclipse/downloads/drops4/R-4.3-201306052000/#SWT Eclipse]. <br />
<br />
Extract swt.jar from the x86_64 file and rename it as swt-64.jar, and extract swt.jar from the second file. I saved them both to the home directory. (You can do this from terminal from the directory in which you saved the .zip files):<br />
{{Code|unzip -e swt-4.3-gtk-linux-x86_64.zip swt.jar -d ~<br />
mv ~/swt.jar ~/swt-64.jar<br />
unzip -e swt-4.3-gtk-linux-x86.zip swt.jar -d ~}} <br />
<br />
Then you need to copy these to the CrashPlan library. On my HDA CrashPlan was installed to /var/hda/web-apps/crashplan/html. If your installation is different you will need to replace the commands below this your directory.<br />
<br />
Stop the crashplan server <br />
{{Code|sudo systemctl stop crashplan.service}}<br />
<br />
Back up the old files and copy in the new ones (change the directory path to your own if it is different and remember to put the /lib at the end):<br />
{{Code|cd /var/hda/web-apps/crashplan/html/lib<br />
mv swt.jar swt.jar.old<br />
mv swt-64.jar swt-64.jar.old<br />
mv ~/swt.jar swt.jar<br />
mv ~/swt-64.jar swt-64.jar}}<br />
<br />
Restart the crashplan server<br />
{{Code|sudo systemctl start crashplan.service}}<br />
<br />
Should be working now.<br />
<br />
[Source: [https://forums.amahi.org/viewtopic.php?f=26&t=4951 this forum post]]</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Crashplan&diff=74036Crashplan2013-11-13T07:22:11Z<p>Matt Clark: /* Fixing Java RTE errors on the CrashPlan desktop */</p>
<hr />
<div>[[Category:Apps]]<br />
==[http://www.amahi.org/apps/crashplan CrashPlan] on Amahi==<br />
<br />
Using CrashPlan on your Amahi HDA will allow you to back up, for free<sup>1</sup>, all your computers into your Amahi HDA<sup>2</sup>.<br/><br />
It will also allow you to become the backup server of friends and family, if you'd like.<br />
<br />
<sup>1</sup> While CrashPlan is free to personal use, an advanced version, CrashPlan+, is available for a fee, if you'd like to get the [http://b1.crashplan.com/consumer/features.html#CrashPlan+ features it adds to the free CrashPlan version].<br/><br />
<sup>2</sup> Technically, it's also possible to backup your HDA into your other computers if you need that.<br />
<br />
==Installing CrashPlan==<br />
<br />
To be able to use CrashPlan, you'll need to install the [http://www.amahi.org/apps/crashplan CrashPlan] application on your Amahi HDA, configure it as needed, and install the CrashPlan application on all the computers you'd like to backup to your HDA.<br />
<br />
==More about CrashPlan==<br />
<br />
To learn more about CrashPlan, you can visit the [http://www.crashplan.com/consumer/features.html CrashPlan website], where features are explained, and where you can watch CrashPlan in action in their [http://b1.crashplan.com/consumer/features-tour.html video tour].<br />
<br />
==CrashPlan Accounts==<br />
<br />
Using CrashPlan requires a (free) CrashPlan account. You'll be able to create a new account from the configuration app itself.<br />
<br />
You'll probably want to use the same account for all computers in your home. That means you'll create the account on the first computer you configure CrashPlan on (it can be your HDA, or any other computer on your home network), and then simply use that same account on all other computers, instead of creating new accounts.<br />
<br />
If you'd like to use different accounts, so that each computer (user) is the sole owner of his backed up files, this is also possible. Trying to restore such files from another computer (this is called a guest restore in CrashPlan) will require the user to enter the owner's password.<br />
<br />
==How to configure CrashPlan on your HDA==<br />
<br />
<p style="color:red">'''NOTE''' The CrashPlan UI sometimes has issues registering button clicks. If you click a button and it seems to do nothing, hit the ENTER key. That seems to help in such cases.</p><br />
<br />
===On the HDA itself===<br />
The easiest way to configure CrashPlan is to access it from the HDA desktop directly.<br />
<br />
Launch a Terminal (Applications > System > Terminal).<br />
<br />
In the terminal window (must run as root user) enter:<br />
<br />
<u>Fedora</u>: <br />
{{Code|su -<br />
CrashPlanDesktop}}<br />
<br />
<u>Ubuntu</u>: <br />
{{Code|sudo CrashPlanDesktop}}<br />
<br />
If you don't have physical access to your HDA, or if you run it headless, try the methods below.<br />
<br />
===Using VNC===<br />
If you have [[VNC]] or [[WebVNC]] setup, you can use that to configure CrashPlan remotely, instead of using the OS-dependent methods described below.<br />
<br />
Simply connect to your HDA using VNC (or WebVNC), and launch a Terminal (Applications > System > Terminal).<br />
<br />
In the terminal window enter the same commands as noted above depending on the OS you are running on your HDA.<br />
<br />
The CrashPlan configuration application will start.<br />
<br />
===Using X-Forwarding===<br />
To use X-Forwarding, you don't need X running, or even installed on your HDA.<br/><br />
All you need is an X server on your client computer, and to SSH into your HDA with X-Forwarding enabled.<br />
<br />
====Windows====<br />
=====PuTTY and Xming=====<br />
You'll need two things to be able to configure CrashPlan from Windows: PuTTY and Xming.<br />
<br />
For PuTTY, just download putty.exe from [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html here]. You can leave it on your desktop and use it from there.<br/><br />
For Xming, you'll need to download and install two files: the [https://sourceforge.net/projects/xming/files/Xming/ Xming installer], and the [https://sourceforge.net/projects/xming/files/Xming-fonts/ fonts installer].<br/><br />
You can accept all the default values for both installs.<br />
<br />
Now, you should have a start menu item for Xming. Start it from there. You should now have a black X icon in your system tray.<br />
<br />
Next, start PuTTY, and enter your HDA IP address under ''Host Name (or IP address)'', enter 22 under ''Port'' and select SSH under ''Connection Type''.<br />
<br />
[[Image:Red-S01.png]]<br />
<br />
Open the ''Connection > SSH'' item in the ''Category'' tree on the left, and select ''X11''.<br/><br />
Select the checkbox that says ''Enable X11 forwarding''.<br />
<br />
Now go back into ''Session'' in the ''Category'' tree, and give a name for this profile, so you won't have to repeat those steps next time.<br/><br />
Enter a name in the ''Saved Sessions'' text box, and hit the ''Save'' button on the right.<br/><br />
Next time your start PuTTY, you'll be able to just double-click your profile in the ''Saved Sessions'' section to connect to your HDA with X11 forwarding enabled.<br />
<br />
Now, connect to your HDA by clicking ''Open'', or double-clicking your profile name in the Saved Sessions select box (on the left of the Load, Save and Delete buttons).<br />
<br />
Enter your Fedora username and password when prompted.<br />
<br />
=====FreeXer=====<br />
FreeXer is an open source attempt to make X11 forwarding easy. It consists of PuTTY and Cygwin with a wrapper that configures both to enable X11 forwarding.<br />
<br />
First, download FreeXer [http://downloads.sourceforge.net/project/freexer/FreeXer/0.2/freeXer-installer.exe here].<br />
<br />
Once installed, open the "freeXer Session Editor" and enter a name for the session you're about to start under ''Session'', enter your HDA IP address under ''Host'', select SSH under ''Protocol'', enter your Fedora username under ''User'' and password under ''Password''. <br />
<br />
[[Image:Sess_editor_new.png]]<br />
<br />
Click on the ''Save'' button to save the session information. Once you saved the session information, the next time you need it you only need to open the session information file (or load it into the session editor) and you're done.<br />
<br />
When ready, click on the ''Launch Session'' button.<br />
<br />
=====Once logged in=====<br />
Enter the following command to start the CrashPlan configuration UI:<br />
<br />
Enter the same commands as noted above for the OS you are running on your HDA.<br />
<br />
=====Guides=====<br />
There are many guides available online that explain the steps of X11 forwarding. Here's some, if you need further help:<br />
*[http://www.youtube.com/v/EsHuZJ5gORE?hl=en_US&fs=1 X Windows Forwarding video on YouTube]<br />
*[http://www.cs.caltech.edu/courses/cs11/misc/xwindows.html Using X Forwarding on Windows at Caltech]<br />
* [http://www.math.umn.edu/systems_guide/putty_xwin32.html X Forwarding with Putty on Windows at University of Minnesota]<br />
<br />
====Mac OS X====<br />
Open a Terminal (Applications > Utilities > Terminal.app)<br/><br />
and enter the following commands:<br />
<br />
{{Code|ssh -X hda}}<br />
<br />
Then enter the same commands as outlined above for the OS you are running on the HDA.<br />
<br />
Once you're done with the CrashPlan configuration, you can close the CrashPlan app, the X11.app that appeared in your Dock, and Terminal.app<br />
<br />
====Linux====<br />
<br />
Starting on your X desktop (Gnome, KDE, ...), open a Terminal (Applications >System > Terminal in Fedora)<br/><br />
and enter the following commands:<br />
{{Code|ssh -X hda}}<br />
<br />
Follow the commands above for the specific OS you are running on your HDA.<br />
<br />
Once you're done with the CrashPlan configuration, you can close the CrashPlan app, and the Terminal.<br />
<br />
===Using a local CrashPlan client===<br />
<br />
You can follow the instructions on the CrashPlan wiki on [http://support.crashplan.com/doku.php/how_to/configure_a_headless_client how to connect to a headless CrashPlan install].<br />
<br />
It requires you to install CrashPlan on your client computer, manually editing a config file, and using SSH port forwarding.<br />
<br />
==Troubleshooting==<br />
<br />
===Fixing Java RTE errors on the CrashPlan desktop===<br />
<br />
If you use the CrashPlan desktop on version 3.5.3 you may experience a Java error - when starting the Crashplan desktop the splash image shows for a few seconds, and then vanishes, but the application doesn't open.<br />
<br />
It appears that CrashPlan 3.5.3 bundles a buggy version of the "Eclipse Standard Widget Toolkit". To fix, you just need to replace that toolkit with the latest one from the developer.<br />
<br />
Download swt-4.3-gtk-linux-x86.zip and swt-4.3-gtk-linux-x86_64.zip from [http://download.eclipse.org/eclipse/downloads/drops4/R-4.3-201306052000/#SWT Eclipse]. <br />
<br />
Extract swt.jar from the x86_64 file and rename it as swt-64.jar, and extract swt.jar from the second file. I saved them both to the home directory. (You can do this from terminal from the directory in which you saved the .zip files):<br />
{{Code|unzip -e swt-4.3-gtk-linux-x86_64.zip swt.jar -d ~<br />
mv ~/swt.jar ~/swt-64.jar<br />
unzip -e swt-4.3-gtk-linux-x86.zip swt.jar -d ~}} <br />
<br />
Then you need to copy these to the CrashPlan library. On my HDA CrashPlan was installed to /var/hda/web-apps/crashplan/html. If your installation is different you will need to replace the commands below this your directory.<br />
<br />
Stop the crashplan server <br />
{{Code|sudo systemctl stop crashplan.service}}<br />
<br />
Back up the old files and copy in the new ones<br />
{{Code|cd /var/hda/web-apps/crashplan/html/lib **change this to your own installation if it is different, remember to put the /lib at the end**<br />
mv swt.jar swt.jar.old<br />
mv swt-64.jar swt-64.jar.old<br />
mv ~/swt.jar swt.jar<br />
mv ~/swt-64.jar swt-64.jar}}<br />
<br />
Restart the crashplan server<br />
{{Code|sudo systemctl start crashplan.service}}<br />
<br />
Should be working now.<br />
<br />
[Source: [https://forums.amahi.org/viewtopic.php?f=26&t=4951 this forum post]]</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Crashplan&diff=74030Crashplan2013-11-13T07:21:27Z<p>Matt Clark: </p>
<hr />
<div>[[Category:Apps]]<br />
==[http://www.amahi.org/apps/crashplan CrashPlan] on Amahi==<br />
<br />
Using CrashPlan on your Amahi HDA will allow you to back up, for free<sup>1</sup>, all your computers into your Amahi HDA<sup>2</sup>.<br/><br />
It will also allow you to become the backup server of friends and family, if you'd like.<br />
<br />
<sup>1</sup> While CrashPlan is free to personal use, an advanced version, CrashPlan+, is available for a fee, if you'd like to get the [http://b1.crashplan.com/consumer/features.html#CrashPlan+ features it adds to the free CrashPlan version].<br/><br />
<sup>2</sup> Technically, it's also possible to backup your HDA into your other computers if you need that.<br />
<br />
==Installing CrashPlan==<br />
<br />
To be able to use CrashPlan, you'll need to install the [http://www.amahi.org/apps/crashplan CrashPlan] application on your Amahi HDA, configure it as needed, and install the CrashPlan application on all the computers you'd like to backup to your HDA.<br />
<br />
==More about CrashPlan==<br />
<br />
To learn more about CrashPlan, you can visit the [http://www.crashplan.com/consumer/features.html CrashPlan website], where features are explained, and where you can watch CrashPlan in action in their [http://b1.crashplan.com/consumer/features-tour.html video tour].<br />
<br />
==CrashPlan Accounts==<br />
<br />
Using CrashPlan requires a (free) CrashPlan account. You'll be able to create a new account from the configuration app itself.<br />
<br />
You'll probably want to use the same account for all computers in your home. That means you'll create the account on the first computer you configure CrashPlan on (it can be your HDA, or any other computer on your home network), and then simply use that same account on all other computers, instead of creating new accounts.<br />
<br />
If you'd like to use different accounts, so that each computer (user) is the sole owner of his backed up files, this is also possible. Trying to restore such files from another computer (this is called a guest restore in CrashPlan) will require the user to enter the owner's password.<br />
<br />
==How to configure CrashPlan on your HDA==<br />
<br />
<p style="color:red">'''NOTE''' The CrashPlan UI sometimes has issues registering button clicks. If you click a button and it seems to do nothing, hit the ENTER key. That seems to help in such cases.</p><br />
<br />
===On the HDA itself===<br />
The easiest way to configure CrashPlan is to access it from the HDA desktop directly.<br />
<br />
Launch a Terminal (Applications > System > Terminal).<br />
<br />
In the terminal window (must run as root user) enter:<br />
<br />
<u>Fedora</u>: <br />
{{Code|su -<br />
CrashPlanDesktop}}<br />
<br />
<u>Ubuntu</u>: <br />
{{Code|sudo CrashPlanDesktop}}<br />
<br />
If you don't have physical access to your HDA, or if you run it headless, try the methods below.<br />
<br />
===Using VNC===<br />
If you have [[VNC]] or [[WebVNC]] setup, you can use that to configure CrashPlan remotely, instead of using the OS-dependent methods described below.<br />
<br />
Simply connect to your HDA using VNC (or WebVNC), and launch a Terminal (Applications > System > Terminal).<br />
<br />
In the terminal window enter the same commands as noted above depending on the OS you are running on your HDA.<br />
<br />
The CrashPlan configuration application will start.<br />
<br />
===Using X-Forwarding===<br />
To use X-Forwarding, you don't need X running, or even installed on your HDA.<br/><br />
All you need is an X server on your client computer, and to SSH into your HDA with X-Forwarding enabled.<br />
<br />
====Windows====<br />
=====PuTTY and Xming=====<br />
You'll need two things to be able to configure CrashPlan from Windows: PuTTY and Xming.<br />
<br />
For PuTTY, just download putty.exe from [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html here]. You can leave it on your desktop and use it from there.<br/><br />
For Xming, you'll need to download and install two files: the [https://sourceforge.net/projects/xming/files/Xming/ Xming installer], and the [https://sourceforge.net/projects/xming/files/Xming-fonts/ fonts installer].<br/><br />
You can accept all the default values for both installs.<br />
<br />
Now, you should have a start menu item for Xming. Start it from there. You should now have a black X icon in your system tray.<br />
<br />
Next, start PuTTY, and enter your HDA IP address under ''Host Name (or IP address)'', enter 22 under ''Port'' and select SSH under ''Connection Type''.<br />
<br />
[[Image:Red-S01.png]]<br />
<br />
Open the ''Connection > SSH'' item in the ''Category'' tree on the left, and select ''X11''.<br/><br />
Select the checkbox that says ''Enable X11 forwarding''.<br />
<br />
Now go back into ''Session'' in the ''Category'' tree, and give a name for this profile, so you won't have to repeat those steps next time.<br/><br />
Enter a name in the ''Saved Sessions'' text box, and hit the ''Save'' button on the right.<br/><br />
Next time your start PuTTY, you'll be able to just double-click your profile in the ''Saved Sessions'' section to connect to your HDA with X11 forwarding enabled.<br />
<br />
Now, connect to your HDA by clicking ''Open'', or double-clicking your profile name in the Saved Sessions select box (on the left of the Load, Save and Delete buttons).<br />
<br />
Enter your Fedora username and password when prompted.<br />
<br />
=====FreeXer=====<br />
FreeXer is an open source attempt to make X11 forwarding easy. It consists of PuTTY and Cygwin with a wrapper that configures both to enable X11 forwarding.<br />
<br />
First, download FreeXer [http://downloads.sourceforge.net/project/freexer/FreeXer/0.2/freeXer-installer.exe here].<br />
<br />
Once installed, open the "freeXer Session Editor" and enter a name for the session you're about to start under ''Session'', enter your HDA IP address under ''Host'', select SSH under ''Protocol'', enter your Fedora username under ''User'' and password under ''Password''. <br />
<br />
[[Image:Sess_editor_new.png]]<br />
<br />
Click on the ''Save'' button to save the session information. Once you saved the session information, the next time you need it you only need to open the session information file (or load it into the session editor) and you're done.<br />
<br />
When ready, click on the ''Launch Session'' button.<br />
<br />
=====Once logged in=====<br />
Enter the following command to start the CrashPlan configuration UI:<br />
<br />
Enter the same commands as noted above for the OS you are running on your HDA.<br />
<br />
=====Guides=====<br />
There are many guides available online that explain the steps of X11 forwarding. Here's some, if you need further help:<br />
*[http://www.youtube.com/v/EsHuZJ5gORE?hl=en_US&fs=1 X Windows Forwarding video on YouTube]<br />
*[http://www.cs.caltech.edu/courses/cs11/misc/xwindows.html Using X Forwarding on Windows at Caltech]<br />
* [http://www.math.umn.edu/systems_guide/putty_xwin32.html X Forwarding with Putty on Windows at University of Minnesota]<br />
<br />
====Mac OS X====<br />
Open a Terminal (Applications > Utilities > Terminal.app)<br/><br />
and enter the following commands:<br />
<br />
{{Code|ssh -X hda}}<br />
<br />
Then enter the same commands as outlined above for the OS you are running on the HDA.<br />
<br />
Once you're done with the CrashPlan configuration, you can close the CrashPlan app, the X11.app that appeared in your Dock, and Terminal.app<br />
<br />
====Linux====<br />
<br />
Starting on your X desktop (Gnome, KDE, ...), open a Terminal (Applications >System > Terminal in Fedora)<br/><br />
and enter the following commands:<br />
{{Code|ssh -X hda}}<br />
<br />
Follow the commands above for the specific OS you are running on your HDA.<br />
<br />
Once you're done with the CrashPlan configuration, you can close the CrashPlan app, and the Terminal.<br />
<br />
===Using a local CrashPlan client===<br />
<br />
You can follow the instructions on the CrashPlan wiki on [http://support.crashplan.com/doku.php/how_to/configure_a_headless_client how to connect to a headless CrashPlan install].<br />
<br />
It requires you to install CrashPlan on your client computer, manually editing a config file, and using SSH port forwarding.<br />
<br />
==Troubleshooting==<br />
<br />
===Fixing Java RTE errors on the CrashPlan desktop===<br />
<br />
If you use the CrashPlan desktop on version 3.5.3 you may experience a Java error - when starting the Crashplan desktop the splash image shows for a few seconds, and then vanishes, but the application doesn't open.<br />
<br />
It appears that CrashPlan 3.5.3 bundles a buggy version of the "Eclipse Standard Widget Toolkit". To fix, you just need to replace that toolkit with the latest one from the developer.<br />
<br />
Download swt-4.3-gtk-linux-x86.zip and swt-4.3-gtk-linux-x86_64.zip from [http://download.eclipse.org/eclipse/downloads/drops4/R-4.3-201306052000/#SWT Eclipse]. <br />
<br />
Extract swt.jar from the x86_64 file and rename it as swt-64.jar, and extract swt.jar from the second file. I saved them both to the home directory. (You can do this from terminal from the directory in which you saved the .zip files):<br />
{{Code|unzip -e swt-4.3-gtk-linux-x86_64.zip swt.jar -d ~<br />
mv ~/swt.jar ~/swt-64.jar<br />
unzip -e swt-4.3-gtk-linux-x86.zip swt.jar -d ~}} <br />
<br />
Then you need to copy these to the CrashPlan library. On my HDA CrashPlan was installed to /var/hda/web-apps/crashplan/html. If your installation is different you will need to replace the commands below this your directory.<br />
<br />
Stop the crashplan server <br />
{{Code|sudo systemctl stop crashplan.service}}<br />
<br />
Back up the old files and copy in the new ones<br />
{{Code|cd /var/hda/web-apps/crashplan/html/lib **change this to your own installation if it is different, remember to put the /lib at the end**<br />
mv swt.jar swt.jar.old<br />
mv swt-64.jar swt-64.jar.old<br />
mv ~/swt.jar swt.jar<br />
mv ~/swt-64.jar swt-64.jar}}<br />
<br />
Restart the crashplan server<br />
Stop the crashplan server <br />
{{Code|sudo systemctl start crashplan.service}}<br />
<br />
Should be working now.<br />
<br />
[Source: [https://forums.amahi.org/viewtopic.php?f=26&t=4951 this forum post]]</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Squeezebox_Server&diff=74024Squeezebox Server2013-11-13T06:26:17Z<p>Matt Clark: </p>
<hr />
<div>== App Fix for Squeezebox Server Upgrade ==<br />
[[Category:Apps]]<br />
[http://www.amahi.org/apps/logitech-media-server Logitech Media Server] (formerly Squeezebox Server) may not work correctly. If it shows the error message:<br />
{{Text|The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.}}<br />
<br />
'''The following steps resolve the issue:'''<br />
<br />
[[Open_Terminal_as_root|Open terminal]] on the HDA enter the following commands and accept all defaults ('''DO NOT''' copy and paste):<br />
{{Code|cpan}}<br />
<br />
'''NOTE:''' At the cpan prompt type <code>force install CGI::Cookie</code> and followed by <code>quit</code> when finished.<br />
<br />
Start squeezeboxserver:<br />
{{Code|service squeezeboxserver start}}<br />
<br />
'''NOTE:''' If you still receive the message above, a restart of the HDA may be required.<br />
<br />
<br />
== Playing AAC files on 64-bit installs ==<br />
Squeezebox server plays AAC files natively, but uses a 32-bit library. On 64-bit machines you may get an error message on your squeezebox saying<br />
{{Text|Problem: Can't open file for: [song title]}}<br />
<br />
A simple fix for this problem is to install the 32-bit glib package. [[Open_Terminal_as_root|Open terminal]] on your HDA and enter the following:<br />
{{Code|yum install glib.i686}} <br />
Your AAC files should play on successful installation.<br />
<br />
(source: [[http://forums.amahi.org/viewtopic.php?f=14&t=2734|this forum post]])<br />
<br />
== Workaround for unblock-us DNS problems with mysqueezebox.com ==<br />
The unblock-us.com domain name servers do not resolve mysqueezebox.com subdomains properly (eg content.mysqueezebox.com, update.mysqueezebox.com). This breaks the MySB network connection for squeezeboxes connected to the server and means they can't play pandora or other apps.<br />
<br />
Workaround:<br />
Amahi 7 uses dnsmasq for the domain name service, which has an option to use an alternative DNS for particular domains (see "using special servers" from the documentation [http://www.thekelleys.org.uk/dnsmasq/docs/setup.html|this here]). We can specify that the Amahi DNS uses the Google or OpenDNS servers instead of unblock-us.com for MySB requests.<br />
<br />
step 1. choose DNS server - I used GoogleDNS (8.8.8.8) but this should work with OpenDNS as well 208.67.222.222<br />
<br />
(optional step 1a. You may wish to make a copy of the dnsmasq.conf file before editing. Type in terminal:<br />
{{Code|sudo cp /etc/dnsmasq.conf /etc/dnsmasq.conf.old}}}<br />
<br />
step 2. add a custom setting to your dnsmasq.conf file using terminal:<br />
<br />
{{Code|sudo vi /etc/dnsmasq.conf}}<br />
<br />
Page down to the very end of the file, then press "i" to insert new text:<br />
<br />
<code>server=/mysqueezebox.com/8.8.8.8</code><br />
<br />
Press w to write to the file, q to save it and you're done! I restarted the DNS server using the Amahi control panel as well. You can test by directing your browser to update.mysqueezebox.com - it should show a directory.</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Talk:Mount_Shares_Locally&diff=71930Talk:Mount Shares Locally2013-07-29T00:57:28Z<p>Matt Clark: /* updates from testing in Amahi 7 / Fedora 19 */</p>
<hr />
<div>As an inexperienced Linux user, I was tripped up by the instructions after completing the configuration. Where it says: "To test your new mounts, you can execute service mount_shares_locally start<br />
service mount_shares_locally stop will unmount the local shares.", I didn't realize that I needed to do that using sudo or as root. (Especially since it indicates to do other steps as root earlier in the article.)<br />
<br />
I'd like to update the article to reflect this, but again, as a somewhat inexperienced user, I figured I should propose it here on the discussion page first. Any thoughts?<br />
<br />
-- Andrew Craze<br />
<br />
Page has been updated.<br />
<br />
Bigfoot65<br />
<br />
== updates from testing in Amahi 7 / Fedora 19 ==<br />
<br />
I had to make two changes to get my shares mounted properly in Amahi 7 (rc8):<br />
- dropbox link to the script hosted at dropbox is wrong - was listed as http://dl.dropbox.com/u/3022105/Amahi/mount_shares_locally but should be http://dl.dropboxusercontent.com/u/3022105/Amahi/mount_shares_locally. Have updated wiki accordingly.<br />
<br />
- it seems that the database tables have changed since the script was written (either during Amahi 7 development or earlier?). I didn't edit the wiki for this one as I thought it may be Amahi 7 specific. The script line<br />
<br />
mysql -u root -phda -e "select comment from shares" hda_production | grep -v "^comment$" | xargs -d "\n" mkdir -p<br />
<br />
doesnt work - gives error "Unknown column 'comment' in 'field list'". Checking the actual columns it seems the right one is 'name'; I changed the script on my machine to <br />
<br />
mysql -u root -phda -e "select name from shares" hda_production | grep -v "^comment$" | xargs -d "\n" mkdir -p<br />
<br />
and reran the mount_shares_locally service - now works fine.</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Talk:Mount_Shares_Locally&diff=71924Talk:Mount Shares Locally2013-07-29T00:56:56Z<p>Matt Clark: /* updates from testing in Amahi 7 / Fedora 19 */</p>
<hr />
<div>As an inexperienced Linux user, I was tripped up by the instructions after completing the configuration. Where it says: "To test your new mounts, you can execute service mount_shares_locally start<br />
service mount_shares_locally stop will unmount the local shares.", I didn't realize that I needed to do that using sudo or as root. (Especially since it indicates to do other steps as root earlier in the article.)<br />
<br />
I'd like to update the article to reflect this, but again, as a somewhat inexperienced user, I figured I should propose it here on the discussion page first. Any thoughts?<br />
<br />
-- Andrew Craze<br />
<br />
Page has been updated.<br />
<br />
Bigfoot65<br />
<br />
== updates from testing in Amahi 7 / Fedora 19 ==<br />
<br />
I had to make two changes to get my shares mounted properly in Amahi 7 (rc8):<br />
- dropbox link to the script hosted at dropbox is wrong - was listed as http://dl.dropbox.com/u/3022105/Amahi/mount_shares_locally but should be http://dl.dropboxusercontent.com/u/3022105/Amahi/mount_shares_locally. Have updated wiki accordingly.<br />
<br />
- it seems that the database tables have changed since the script was written (either during Amahi 7 development or earlier?). I didn't edit the wiki for this one as I thought it may be Amahi 7 specific. The script line<br />
<br />
mysql -u root -phda -e "select comment from shares" hda_production | grep -v "^comment$" | xargs -d "\n" mkdir -p<br />
<br />
doesnt work - gives error "Unknown column 'comment' in 'field list'". Checking the actual columns it seems the right one is 'name'; I changed the script to <br />
<br />
mysql -u root -phda -e "select name from shares" hda_production | grep -v "^comment$" | xargs -d "\n" mkdir -p<br />
<br />
and reran the mount_shares_locally service - now works fine.</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Talk:Mount_Shares_Locally&diff=71918Talk:Mount Shares Locally2013-07-29T00:56:41Z<p>Matt Clark: /* updates from testing in Amahi 7 / Fedora 19 */ new section</p>
<hr />
<div>As an inexperienced Linux user, I was tripped up by the instructions after completing the configuration. Where it says: "To test your new mounts, you can execute service mount_shares_locally start<br />
service mount_shares_locally stop will unmount the local shares.", I didn't realize that I needed to do that using sudo or as root. (Especially since it indicates to do other steps as root earlier in the article.)<br />
<br />
I'd like to update the article to reflect this, but again, as a somewhat inexperienced user, I figured I should propose it here on the discussion page first. Any thoughts?<br />
<br />
-- Andrew Craze<br />
<br />
Page has been updated.<br />
<br />
Bigfoot65<br />
<br />
== updates from testing in Amahi 7 / Fedora 19 ==<br />
<br />
I had to make two changes to get my shares mounted properly in Amahi 7 (rc7):<br />
- dropbox link to the script hosted at dropbox is wrong - was listed as http://dl.dropbox.com/u/3022105/Amahi/mount_shares_locally but should be http://dl.dropboxusercontent.com/u/3022105/Amahi/mount_shares_locally. Have updated wiki accordingly.<br />
<br />
- it seems that the database tables have changed since the script was written (either during Amahi 7 development or earlier?). I didn't edit the wiki for this one as I thought it may be Amahi 7 specific. The script line<br />
<br />
mysql -u root -phda -e "select comment from shares" hda_production | grep -v "^comment$" | xargs -d "\n" mkdir -p<br />
<br />
doesnt work - gives error "Unknown column 'comment' in 'field list'". Checking the actual columns it seems the right one is 'name'; I changed the script to <br />
<br />
mysql -u root -phda -e "select name from shares" hda_production | grep -v "^comment$" | xargs -d "\n" mkdir -p<br />
<br />
and reran the mount_shares_locally service - now works fine.</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Mount_Shares_Locally&diff=71912Mount Shares Locally2013-07-29T00:45:51Z<p>Matt Clark: /* On Fedora */</p>
<hr />
<div>{{MessageBox|<br />
backgroundcolor = #faa|<br />
image =Warning.png|<br />
heading =WARNING|<br />
message = This is recommended only for advanced users, proceed with caution.}}<br />
<br />
<b>NOTE:</b> Recommend not using copy and paste for the steps below. It often introduces hidden characters which causes failure in the script.<br />
<br />
Mounting your Samba shares locally is useful when you are using Greyhole, and want to write or in any way work with those files locally. Greyhole data should only be accessed through shares, so mounting those shares locally is an easy way to work with Greyhole data safely.<br />
<br />
== Download and Setup ==<br />
<br />
* As '''root:''' Install the mount_shares_locally initd script:<br />
=== On Ubuntu ===<br />
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px; overflow: scroll"><br />
sudo apt-get install cifs-utils curl<br />
sudo curl -o /etc/init.d/mount_shares_locally http://dl.amahi.org/mount_shares_locally<br />
sudo chmod +x /etc/init.d/mount_shares_locally<br />
sudo update-rc.d mount_shares_locally defaults<br />
</div><br />
<br />
=== On Fedora ===<br />
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px; overflow: scroll"><br />
curl -o /etc/init.d/mount_shares_locally http://dl.dropboxusercontent.com/u/3022105/Amahi/mount_shares_locally<br />
chmod +x /etc/init.d/mount_shares_locally<br />
chkconfig --add mount_shares_locally<br />
</div><br />
<br />
== Configuration ==<br />
<br />
* Edit /etc/init.d/mount_shares_locally (as user root) in a text editor, and replace ''your_username'' (on line 12) with your username. Example '''username="amahi"'''<br />
{{Code|Code= nano /etc/init.d/mount_shares_locally}}<br />
* Create the ''/home/your_username/.smb_credentials'' file. This is a simple text file (use your favorite text editor).<br />
{{Code|Code= nano /home/YourHDA_username/.smb_credentials}}<br />
*Enter the following:<br />
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px;"><br />
username=your_username<br />
password=your_password<br />
domain=HOME<br />
</div><br />
'''NOTE:''' your_username and your_password in the .smb_credentials file needs to be the original username and password you created when you installed fedora.<br />
<br />
*To test your new mounts, you can execute '''service mount_shares_locally start''' (as root user)<br/><br />
<br />
'''service mount_shares_locally stop''' (as root user) will unmount the local shares.<br/><br />
<br />
'''NOTE:''' If you used /etc/rc.local and /etc/fstab to mount shares locally in the past, you can remove what you added in those files now (<u>DO NOT</u> remove the drive mount lines). The above initd script replaces all this.<br />
<br />
== Re-mount to Add new shares ==<br />
If you added new share to greyhole via the web admin. This does not automatically mount locally. You need to restart your mount script by running '''service mount_shares_locally restart'''. This will unmount and remount all your shares, adding all the new shares you added.<br />
<br />
== Where everything is mounted ==<br />
You will find the mounted shares in ''/mnt/samba/*''<br/><br />
For example, your "Pictures" share would be located at '''/mnt/samba/Pictures'''. <br />
<br />
<b>NOTE:</b> When working with files on the HDA, access them via this share and <u>NOT</u> the traditional /var/hda/files/pictures location.<br />
<br />
== Unable to mount locally after upgrading to Amahi6 ==<br />
If you try to run mount using this script after you upgraded to Amahi6 you might get greeted by this type of error.<br />
<br />
[root@localhost ~]# /etc/init.d/mount_shares_locally start<br />
Mounting Samba shares locally: /etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory<br />
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory<br />
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory<br />
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory<br />
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory<br />
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory<br />
/etc/init.d/mount_shares_locally: line 27: /sbin/mount.cifs: No such file or directory<br />
[ OK ]<br />
<br />
It's easily fixed by installing the missing dependency.<br />
<br />
{{Code|yum install cifs-utils}}<br />
<br />
Now it should work fine to run<br />
<br />
{{Code|/etc/init.d/mount_shares_locally start}}<br />
<br />
== MySQL Problems With Newer Versions of Greyhole ==<br />
<br />
Since Greyhole moved from SQL Lite to MySQL, you may hit a problem where Greyhole and the mount_shares_locally script both attempt to start before MySQL in bootup, leading to the services not starting properly. If this happens, you can try this to fix it:<br />
<br />
{{Code|ls /etc/rc.d/rc3.d/}}<br />
* Look for any entries marked S-1. If there are any, they need to be removed. Run the following as root:<br />
<br />
{{Code|rm S-1*}}</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Squeezebox_Server&diff=52676Squeezebox Server2012-02-19T12:35:04Z<p>Matt Clark: </p>
<hr />
<div>== App Fix for Squeezebox Server Upgrade ==<br />
[[Category:Apps]]<br />
Squeezebox Server may not work correctly. If it shows the error message:<br />
{{Text|The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.}}<br />
<br />
'''The following steps resolve the issue:'''<br />
<br />
[[Open_Terminal_as_root|Open terminal]] on the HDA enter the following commands and accept all defaults ('''DO NOT''' copy and paste):<br />
{{Code|cpan}}<br />
<br />
'''NOTE:''' At the cpan prompt type <code>force install CGI::Cookie</code> and followed by <code>quit</code> when finished.<br />
<br />
Start squeezeboxserver:<br />
{{Code|service squeezeboxserver start}}<br />
<br />
'''NOTE:''' If you still receive the message above, a restart of the HDA may be required.<br />
<br />
<br />
== Playing AAC files on 64 bit installs ==<br />
Squeezebox server plays AAC files natively, but uses a 32 bit library. On 64 bit machines you may get an error message on your squeezebox saying<br />
{{Text|Problem: Can't open file for: [song title]}}<br />
<br />
A simple fix for this problem is to install the 32 bit glib package. [[Open_Terminal_as_root|Open terminal]] on your HDA and enter the following:<br />
{{Code|yum install glib.i686}} <br />
Your AAC files should play on successful installation.<br />
<br />
(source: [[http://forums.amahi.org/viewtopic.php?f=14&t=2734|this forum post]])</div>Matt Clarkhttps://wiki.amahi.org/index.php?title=Squeezebox_Server&diff=52670Squeezebox Server2012-02-19T12:34:07Z<p>Matt Clark: deployed this fix today for my squeezebox server installation, hope it helps someone else</p>
<hr />
<div>== App Fix for Squeezebox Server Upgrade ==<br />
[[Category:Apps]]<br />
Squeezebox Server may not work correctly. If it shows the error message:<br />
{{Text|The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.}}<br />
<br />
'''The following steps resolve the issue:'''<br />
<br />
[[Open_Terminal_as_root|Open terminal]] on the HDA enter the following commands and accept all defaults ('''DO NOT''' copy and paste):<br />
{{Code|cpan}}<br />
<br />
'''NOTE:''' At the cpan prompt type <code>force install CGI::Cookie</code> and followed by <code>quit</code> when finished.<br />
<br />
Start squeezeboxserver:<br />
{{Code|service squeezeboxserver start}}<br />
<br />
'''NOTE:''' If you still receive the message above, a restart of the HDA may be required.<br />
<br />
<br />
== Playing AAC files on 64 bit installs ==<br />
Squeezebox server plays AAC files natively, but uses a 32 bit library. On 64 bit machines you may get an error message on your squeezebox saying<br />
{{Error|Problem: Can't open file for: [song title]}}<br />
<br />
A simple fix for this problem is to install the 32 bit glib package. [[Open_Terminal_as_root|Open terminal]] on your HDA and enter the following:<br />
{{Code|yum install glib.i686}} <br />
Your AAC files should play on successful installation.<br />
<br />
(source: [[http://forums.amahi.org/viewtopic.php?f=14&t=2734|this forum post]])</div>Matt Clark