OpieNonRoot

= Running Opie as an ordinary (non-root) user = There are two methods that achieve non-root Opie environment: running from user's shell (preferred) and using the  package.

Running directly from user's shell
Basically, the only problem with that is write access to devices:
 * 1) Video device,   -- can be usually gained by adding the user to group
 * 2) Audio devices, ,  ,   -- can be usually gained by adding the user to group
 * 3) Login terminal, eg.   -- must be owned by the user, but this is usually done by the login program
 * 4) "Current" terminal,   -- must be circumvented by manual chmod or udev rules (see below)

As for gaining access to, if you're using udev, just make the following changes to its configuration file (eg.  ):

KERNEL=="tty0", MODE="0660", GROUP="users"

and, if you have a line such as

KERNEL=="tty[0-9]*", GROUP="root"

then modify it to read

KERNEL=="tty[1-9]*", GROUP="root"

Without udev, the approach is to manually (as root) change the permissions:

chmod 660 /dev/tty0 chgrp users /dev/tty0

(This works for udev as well, but must be done again after each boot.)

Finally, add the user to the  group.

Running Opie now should be as simple as: export OPIEDIR=/opt/QtPalmtop qpe -nodaemon -terminal 1
 * 1) Boot the system without GUI
 * 2) Log into the console with your user account
 * 3) Start Opie by typing

Using opie-login
Note: This section might be incomplete, since the author does not use. Feel free to add your own experience.

The  package gives you the ability to login using a GUI, similar to XDM, KDM, etc. (As oposed to logging into the text-mode console and running Opie manually.)

On a well-configured distribution, it should work "out of the box". If it doesn't, it is most probably the scripts in  (or wherever Opie is installed) to blame.

The  script must take care of gaining access to devices and the   directory for the current user (see above). The user name (or id?) is passed as the first parameter to the script.

Optionally, the  script should revert things modified by   back to their previous state.

Finally, the  script runs the GUI (ie.  ). The call to   should include the   and   options. The  option should be the same as the   option for   (which is usually to be found in the system init scripts, such as  ).

Also see notes in the previous section.

Configuring Opie as non-root
Since most of the Opie's configuration applets require write access to system configuration files (eg. in ), they are determined to fail when run as non-root user.

Possible solutions to this problem are:
 * 1) Open the console and edit the files manually as root, using su/sudo (preferred)
 * 2) Open the console and run the configuration applet in question as root, using su/sudo (also fine)
 * 3) Make the applet binary seteuid root (untested, setegid to a group that has write access to configuration files would probably work as well)
 * 4) Run Opie as root and run, using the GUI, the configuration applet in question (ouch)

Note that if you configure an application (ie. not the system) as root, the settings will get saved into  (ie. not to your home directory).

To the author's knowledge, there is no such thing as su/sudo applet that the applications could use to ask the user for user/root password to perform certain privileged things.