This happened right after the installation of ownCloud 5.0.13, when trying to log in for the first time. This failed, and the login page was simply served again (without any error message or explanation). The URL of that login page was then something like http://example.com/index.php?redirect_url=%2Findex.php%2Fapps%2Ffiles.
During installation, I also had to create an xcache admin user and password to solve the "xcache.admin.user and/or xcache.admin.pass settings is not configured" issue (for a description and instructions to solve it, see this tutorial).
However, this issue only happened when accessing the ownCloud installation from the same URL that was used for creating the admin user in the first place during installation. When using an alternative URL, like an IP based on available on most servers as http://xxx.xxx.xxx.xxx/owncloud/, login worked flawlessly (also reported here).
You have to disable xcache authentication again, and instruct your browser to forget the HTTP Basic authentication details that else get sent with every HTTP request header to the site's URL and trigger this issue again. Step by step:
- Go to the place in your php.ini or server admin panel where you configured the xcache authentication. It would look similar to this:
xcache.admin.user = "admin"
xcache.admin.pass = "798967d2527320febcf"
- Either add the line "xcache.admin.enable_auth = Off" or delete this whole section.
- Reconfigure or restart your web server (if not done by your server admin panel automatically). Depending on how your PHP gets served, it is usually one of these, on Debian and Ubuntu Linux at least:
service apache2 reload;
service php-fpm reload;
- Delete your HTTPBasic authentication details from your browser.
- In Firefox, this is done by going to "Edit -> Preferences -> Clear your recent history -> Active Logins".
- In Chrome, it can be done as shown here.
- You can confirm with a phpinfo() script, called from the ownCloud domain that would not work for login, that the HTTPBasic login details are no longer sent in HTTP headers for requests to this domain. Look for variable _SERVER[“HTTP_AUTHORIZATION”], the value should now be no value.
- The issue of the ownCloud login loop (with or without an actual redirect loop error message) is quite common and probably has multiple causes. If the above instructions did not help you, try some more solutions.
- Maybe it is possible to use "xcache.admin.enable_auth = Off" during the initial ownCloud setup already, avoiding this whole maize. I did not try.
- The issue seems to be ownCloud issue 4556, as esp. confirmed by this comment, showing the same solution.
- Disabling HTTPBasic authentication for xcache is not a security issue because these login details are normally meant only for the xcache admin interface. So simply install this admin interface on a different virtual host, and enable HTTPBasic authentication over there.
- This issue was not due to entering invalid login details for the ownCloud user; since when doing so deliberately, an error message would appear asking if one forgot the password.
- The fact that the IP-based URL worked had nothing to do with webserver setup to handle the name-based URL [as assumed here]. Instead, it simply leads to using a different web server configuration, where xcache authentication had never been enabled. This happens for example in web server setups where you modify php.ini settings with snippets added per domain.
Edit the website record in ISPConfig 3, there go to the options tab and in line "PHP open_basedir" set the value "none".
Save, wait a minute for the job to disappear from ISPConfig's job queue (Monitor -> Show Jobqueue) and confirm that your change made it into the configuration with a command like
cat /etc/php5/fpm/pool.d/web3.conf (using your website ID of course). Or even better, look into phpinfo() output from your website.
There are two main reasons for this: the next job causing an error, or a stale lock.
How to fix a job queue stuck with a job that causes an error
- Check for errors. Go to "Monitor -> Show System Log" and check if there is a message of loglevel "Error". If yes, proceed below; if no, it is more likely that you have the stale lock file issue – see next section.
- Fix the error. Fix the cause for the error and then click "Remove" in the ISPConfig system log view. This will cause ISPConfig to reprocess the stuck job when its cron job runs the next time (which is every minute in a default setup).
- If needed, use Debug log level. If it is not clear what causes the error, enable the Debug log level (in System -> Server Config -> Server -> Loglevel), wait a minute and revisit "Monitor -> Show System Log". Since ISPConfig continuously tries to process the failing job again, now you should at least see more detailed error messages.
- If needed, use direct cron output. If it is still not clear what causes the error, you can look at the direct output of the cron job by executing
/usr/local/ispconfig/server/server.sh in a console. If you see "There is already an instance of server.php running.", wait a few seconds and try again – your execution accidentally overlapped with the regular ISPConfig cron job. If you keep getting this however, it is more probable that you have the "stale lock file" issue, see below.
- Or let ISPConfig ignore the failing job. If you don't know how to fix the error, you can let ISPConfig jump over this job and proceed with the next one. For that, increment database column server.updated by one in the ISPConfig database (usually dbispconfig), in the row that belongs to the affected server. If you want to jump over several jobs: make this number correspond to the ID of the last job record which ISPConfig should consider "done". Job records are stored in table sys_datalog, and their IDs in column sys_datalog.datalog_id.
- "Delete ISPconfig job queue" thread
- ISPConfig 3 Manual 1.4, chapter 7.1 "How Do I Find Out What Is Wrong If ISPConfig Does Not Work?"
How to fix when a database creation job causes an error
This is one of the cases from the scenario above, where a job in the job queue causes an error. However, this error is particularly nasty, since it will not show up as an error in the ISPConfig job queue, and can cause teh cron job to occupy all the system's memory, so that even the web server can crash (or fail to restart) in response.
- The ISPConfig job queue is no longer processed, and the next job to process (so, the one it got stuck with) is probably a database creation or deletion job.
- You have the smpyoms of the "stale lock file" issue below, because the ISPConfig cron job does not return, and if it finally crashes, it leaves the stale lock file.
- When deleting the stale lockfile, enabling the debug log level and then starting the cron job from the command line, one gets an infinite loop of error messages like these:
23.02.2014-15:25 - WARNING - DB::query(SELECT count(syslog_id) as number FROM sys_log WHERE datalog_id = 910 AND loglevel = 2) -> mysqli_query Access denied for user 'root'@'localhost' (using password: YES)
How to fix this:
The cause of this was that the MySQL root user password was changed after installing ISPConfig, and without adding this to the ISPConfig configuration. It is needed there for ISPConfig to be able to create and delete MySQL databases. So, edit /usr/local/ispconfig/server/lib/mysql_clientdb.conf and update the MySQL root password there (entering it in plain text). [source]
How to fix a stale lock file
This reason is the most likely cause in cases where you see the following message permanently when enabling the debug log level in System -> Server Config -> Server -> Loglevel and then (repeatedly) trying to start the cron job manually on the console:
user@host:~ $ /usr/local/ispconfig/server/server.sh
user@host:~ $ 15.11.2013-19:56 – DEBUG – There is already an instance of server.php running. Exiting.
It means that the ISPConfig cron job crashed (or you killed it) when it was running the last time, leaving a stale lock file behind.
Fix this by executing:
rm -f /usr/local/ispconfig/server/temp/.ispconfig_lock
Huawei 3G USB sticks ("dongles") support a special command to control the mode how they will appear to a host computer. This allows to switch off the flipflop USB capability, also called USB modeswitching.
USB modeswitching means that these and many other USB 3G sticks at first only provide a virtual CD-ROM drive to the computer from which a (Windows) computer will install the device drivers, and then the device will switch to show only a 3G modem interface. This of course does not work with non-Windows computers like Linux and Android systems, making it a completely bad idea of course. For Linux, there is now the
usb_modeswitch utility which now switches the device to the 3G modem mode more or less automatically, but this is still not standard for Android (though possible on rooted devices, and included in the PPP Widget app for rooted devices).
So for using Huawei 3G sticks on non-rooted Android devices, we want to disable the virtual CD-ROM mode permanently. This can be done as follows on a Linux host:
- Make sure you execute these steps from a computer that can see the serial line interfaces of the device. This should be possible on any Linux computer that has
usb_modeswitch installed and configured, like done by default on at least Ubuntu 12.10 (and newer).
- Find out the first USB interface of the device by doing
ls /dev/ttyUSB* before and after plugging the 3G stick in and taking the first result.
- Open one terminal for receiving messages from the device, by executing
cat /dev/ttyUSB1 (using your device number of course).
- In another terminal, send a command to the stick to test communication with it. Execute
echo "ATi^M" > /dev/ttyUSB1. But note: You can not simply copy this over, as the
^M is just the visual representation of a single control character. Enter this character in the terminal directly by pressing Ctrl+V and afterwards Ctrl+M.
- Now, your terminal with
cat should display information that the stick sent about itself.
- If this worked, now send the command to disable the virtual CD-ROM mode:
echo "AT^U2DIAG=0^M" > /dev/ttyUSB1. Note that
^M is again a control character that you have to enter specially (see above), but
^U is just normal text, so you can copy & paste it.
- Now your
cat terminal should answer with
OK. If so, the command was successful. [source]
The basic idea for this console based process comes from the article "Send AT commands to USB modem" by brunomgalmeida.
There are also instructions on an equivalent procedure using Windows; however I was not able to follow that procedure as my Huawei K3715 3G stick did not let me talk to it through a serial terminal at all, probably because I set it up with bad connection speed etc. settings (as these were nowhere to be found …).
Also compare "Hayes command set" on Wikipedia for more information.
These instructions were tested on a Flytouch 10 (more specs here), also known as Flytouch X, Superpad 10, Superpad X. The model naming of this Shenzai stuff is a mess, so be sure to check the linked specs and photos to make sure it's your device.
For a compatible 3G stick to work, you do not need to root your device, and you do not need to install additional software.
- Choose and buy a compatible 3G stick. There is no user manual to speak of for the Flytouch 10, just a leaflet coming with the product. Means there is no official documentation what 3G sticks will work with it. Probably all that work with a stock Android 4.1 will do, but it seems safe to use the narrower list users developed for earlier generations of the Flytouch: many or most of Huawei 3G sticks will do, but these are confirmed to work:
- Disable PIN entry on the SIM card you want to use. This can be done with any mobile phone. It is needed because (to my knowledge) the Flyouch 10 has no feature to ask for the PIN before connecting. This feature is however available in the PPP Widget app, which is a more flexible solution anyway but needs a rooted device. Compare the PPP Widget author's webpage.
- Make sure you can connect with the intended 3G stick / SIM card combination using a computer. If you get an Internet connection this way, it indicates that your 3G stick / SIM card combination does not have an issue with a SIM lock. It also excludes many other failure modes, meaning the remaining ones are on the tablet then.
- If necessary, remove the SIM lock from the 3G stick. If the last step failed, you might be able to make it work by removing this SIM lock. Legal disclaimer: You are advised to only do so if your provider and jurisdiction allow this.
- Configure the APN properly. These settings are in "Settings -> Wireless and Networks -> More -> Mobile Networks -> APN Settings". You should configure them exactly as on your computer or another device where you can successfully create a 3G Internet connection using the same SIM card. Because if you do something wrong here (like: missing username and password – often they're optional but not always), you will get no error message or other feedback. The 3G stick will simply not establish a data connection. Note that sometimes, your device will fetch APN settings from your network, creating a APN config entry for you – but, this does not guarantee that this entry is correct and working. In my case, it created an APN for German E-Plus network, which did not work for simyo (also using the E-Plus network but with different APN settings).
- Maybe: Disable the USB flip-flop mode and card reader on the 3G stick. This step was needed back in 2011-01 for the Flytouch 2, but I am not sure it is still needed. Since the Flytouch 10 did create APN settings before I executed this step, meaning it could access the 3G modem hardware somehow, I think it's rather not needed. If it is needed, you can use my instructions for disabling mode switching on Huawai 3G sticks.
Note: It is normal, at least for some devices like the Huawei K3715 in my case, that the mobile network search fails (in "Settings -> Wireless and Networks -> More -> Mobile Networks -> Mobile Network Provider"). The reason for this is unknown, but such a stick can still create data connections for the tablet. However, this network scanning was also not completely broken, since when going into AP
Normal usage of a 3G stick on the Flytouch 10:
- Insert the SIM card into your 3G stick. It's important, it won't work without! 😀
- It is not necessary to disable wi-fi on the Flytouch. Contrary to instructions for earlier generations of the Flytouch, you do not have to disable it in system settings, also not using the hardware switch. Just, make sure you are disconnected from any wi-fi network, because a wi-fi connection has a higher priority for the tablet: it will try to use it even when no Internet connection is available via this, then ignoring a possibly existing 3G Internet connection.
- Insert the UMTS stick into the lower USB port. It should work with both USB ports though, but at least for the device I tested it does not: the 3G stick will not start to flash its LED at all. This might be due to different power capabilities of the ports, or maybe one of them is broken already.
- Wait approx. 20s for a connection to appear. In the case of the Huawei K3715 stick, the progress is like this: at first it flashes double-flashes regularly, then single flashes regularly, then it lights continuously; which probably corresponds to "no connection; registered in mobile network; established data connection". Shortly afterwards, the 3G icon will appear in the notification area of the screen, in the lower right corner. At the beginning, it should have flashing arrows both up and down – if only up, it usually indicates that the data network connection is established, but not working.
- Use. Open a browser and call up a www page – it should work now.
- After standby, wait again 20s for the connection. Right when switching off the screen, the Flytouch 10 enters standby mode, also cutting off power from the 3G stick. So when resuming from standby, you have to wait just as for the initial connection to appear. So it can make sense to increase the duration until standby, in "Settings -> Display -> Standby".
- Pull the 3G stick out and re-insert it. This often fixes a messed up registration in the data network, which can happen esp. when reception is poor.
- Try a different USB port. As mentioned above, at the device I tested only one of the two ports worked for the Huawei K3715 stick.
- Try a Y cable. At least the Huawei K3715 stick came with a Y cable originally, meaning that it could overchallenge the power supply of some USB ports.
- Pull the stick out, disable wi-fi and re-insert it. Should not be necessary (except if you're actually connected to a wi-fi network), but worth a try. If you want to try this, disable wi-fi both in the system settings and via the hardware switch, to be sure.
I got quite annoyed by the vendor lock-in of Plesk Panel, so now I'm looking for a free and open alternative. The requirements were quite straight-forward:
- good software quality
- free and open source software
- running on a Linux server
- multi-domain capability
- multi-client capability
- FTP, webserver and e-mail configuration support
- per-client SSH access
List of alternatives that I looked into, ranked by my subjective evaluation of matching the above requirements, the best first. First the panels that I consider the best for the above requirements, and they are all nearly on par:
- ISPConfig. My personal first choice. See Wikipedia on ISPConfig. They have a live demo version available, which looks nice and stable, and with a whole lot of functionality, incl. five different modes how to host PHP, even with naming templates for database naming etc.. My only "complaint" would be that the multi-server features are also all over the place, which is overkill / distracting for our simpler requirements.
- AlternC. I like their clean and simple user interface a lot. Their live demo version works well. Written mostly in PHP. Seems not as feature rich as ISPConfig, but simpler to use. For being used by non-techie users, I would choose this one, while for myself, I would choose ISPConfig.
- ZPanel. Also a feature-complete hosting control panel.
- Virtualmin. A variant of the well-known Webmin panel, adding website management features though additional modules. Written in Perl and modular, though due to its age the user interface is somewhat outdated and complicated, including the naming of items (such as "virtual servers" for "domains").
- GNUPanel. See its website. Nice project, but not yet feature complete and it still has to mature. Plans for version 2.0 are well under way though.
- Domain Technologie Control. Indeed still a very active project [source], but with just one main developer, so no warranties for the future. The DTC documentation however is extremely outdated (with comical overtones when they praise SysCP and Web-cp as "very good" [source], both dead since 4 resp. 8 years now). I did not like the self-praise in their docs, so did not even bother to try the software. Which I would have done however if there would be a live demo …
- OpenPanel. Interesting architecture with a core written in C++, but so far not yet the full feature set as available in, for example, ISPConfig.
- Froxlor. I have installed Froxlor on one web server, and I'm not really happy with their software quality then (2013-03), esp. the UI logic. Once it's running and you found your way around configuration issues, it works pretty stable though.
- i-MSCP. Looked quite promising until I saw it does not support per-user SSH access [source].
- Kloxo. Seems not really in active development any more [source], and its history is quite bumpy.
- Webmin. One of the oldest web-based control panels, with its first release on 1997-10-05 [source]. Virtualmin, a derivative of Webmin, seems preferrable over Webmin for webserver management since it adds the website management features directly [source], while they probably could be added to Webmin as modules.
- Usermin. A variant of Webmin, but not strictly for website management. Rather for user-level computer management. Virtualmin is the variant to choose for website management.
- ispCP. No per-user SSH support, so not applicable for our requirements. Also, superseded by the fork i-MSCP.
- SysCP. No per-user SSH support, so not applicable for our requirements. Dead since four years [source].
- Baifox. Dead since 2009.
- WebsitePanel. Only for Windows-based hosting [source].
- EHCP. No information on this.
- Ajenti. They say "Ajenti is a server control panel, not a hosting control panel." [source], means it is not possible to manage domains, clients etc. with this. Not for our purposes here, but an impressive project anyway.
- Aegir. Impressive features and even a command line client for hosting management, but it is meant only for Drupal site deployment [source], not as a generic web hosting control panel.
Just rebooting the phone should fix this if this option is at least usually shown when connecting the phone by USB cable to a computer.
It does not help to use the feature in settings to "Safely Remove SD Card" and then drawing the SD card out and plugging it in again – the SD card is accessible by the phone without problems still, just not shared to a computer.
It might be that switching the "USB Tethering" feature on and off multiple times is what triggers this issue (since, by design, the USB mass storage connection option is not shown while USB Tethering is enabled on the phone; and by error, maybe also not afterwards in some cases).