[Dev] Gumd usage in building images

Zaman, Imran imran.zaman at intel.com
Tue Oct 21 12:22:38 GMT 2014


Thanks Rafal!

Do you have an example for the lock file which is robust to corner case like the lock file may stay in case daemon crashes?

rafal, r u available on any irc channel and with what name?

BR
imran
________________________________________
From: Rafał Krypa [r.krypa at samsung.com]
Sent: 20 October 2014 19:12
To: Zaman, Imran
Cc: Ohly, Patrick; dev at lists.tizen.org; Roman Kubiak; Dominig Ar Foll
Subject: Re: [Dev] Gumd usage in building images

On 2014-10-20 17:54, Zaman, Imran wrote:

Hi Rafal!

I have started working on making libgum work in offline mode. Its doable and I should come back to you within 2-3 days.

That's a good news, thank you.


I will also add support for "offline" to gum-utils. One thing to keep in mind is that you guys should use libgum (with offline support) instead of gum-utils to avoid cases like error handling etc.

The way I will change libgum is that user should specify the offline mode when calling the APIs at object creation time.
e.g. GumUser * gum_user_get_sync (gboolean offline, uid_t uid);

Its better to let the 'user' of the 'libgum'/'gum-utils' to decide whether it wants offline mode or not rather than automagically switching to one or the other mode on the fly.

It's obviously your decision to make. But why do you find the explicit version better?
The API gets complicated and incompatible with previous version. And the client might have difficulties choosing between online and offline. I think for example of a package providing user configuration. The package could call gum-utils in postinst section. But it will work differently when installed by mic (image creation) and by developer for testing (run-time). I bet that most use cases will include some detection for gumd daemon process anyway.


Btw how do you detect if a daemon is running or not? iterating through 'proc' may not be the best solution that can work out in environments like yocto or at image creation time.

The idea is to use a lock file. It's simple and should work in all environments.


Best regards,
Rafal Krypa


____________________________________
From: Rafał Krypa [r.krypa at samsung.com<mailto:r.krypa at samsung.com>]
Sent: 17 October 2014 20:25
To: Zaman, Imran
Cc: Ohly, Patrick; dev at lists.tizen.org<mailto:dev at lists.tizen.org>; r.kubiak at samsung.com<mailto:r.kubiak at samsung.com>; dominig.arfoll at fridu.net<mailto:dominig.arfoll at fridu.net>
Subject: Re: [Dev] Gumd usage in building images

On 2014-10-17 16:14, Zaman, Imran wrote:


Hi Rafal/Roman!

I agree with patrick, and consequently:

In order to make life easier, I have added "offline" support in gumd, which means that gumd can be run as simple binary to add/del/update/get user/group.
No (p2p) dbus is needed.

offline mode:  user will be added and gumd will exit immediately
# gumd -o -a --username=user1 --usertype=4               (e.g.)



This is fine and solves the problem. But I'd like to suggest other approach, already mentioned by Patrick:



For gumd, a mode where the client tool embeds the daemon code directly
would be the best solution IMHO.



This is the same approach that we used in cynara and security-manager. It greatly simplifies usage of the client library, making the client work (to some extent) in the same way for both off-line and on-line modes.
The exact approach we used was to:
- move some parts of the deamon code to a separate library
- link daemon with it to keep it working as usual
- link client with it to enable offline mode
- inside client implementation, if daemon is not running, invoke the target routines directly instead of sending requests to daemon

What do you think about doing something similar for gumd? This would allow simple usage of "gum-utils" during both image-creation time and run-time.


Best regards,
Rafal Krypa




non-offline mode (it needs either p2p dbus or system bus):
# gumd

The changes have already been merged and pushed to tizen, and should show up in next Tizen common release (hopefully on monday).
Please make sure that you use gumd with version 0.0.6.

Roman, please test user creation at image level with gumd 0.0.6 and let me know if you face any issues.

BR
imran
________________________________________
From: Dev [dev-bounces at lists.tizen.org<mailto:dev-bounces at lists.tizen.org>] on behalf of Patrick Ohly [patrick.ohly at intel.com<mailto:patrick.ohly at intel.com>]
Sent: 17 October 2014 10:37
To: dev at lists.tizen.org<mailto:dev at lists.tizen.org>
Subject: Re: [Dev] Gumd usage in building images

On Fri, 2014-10-17 at 09:18 +0200, Dominig ar Foll (Intel OTC) wrote:


Hello;

when looking at off line mode (use during image creation) remember that
we have a fast growing community planing to use Yocto and so your
solution needs to work with Yocto as well.


For those not familiar with Yocto, some background:
      * Tools manipulating the root filesystem typically get compiled
        for the host system (for example, your Intel-based laptop
        running some Linux distro) and then get invoked to modify files
        used in the target (for example, ARM). Make sure that your files
        don't have architecture dependencies (LSB vs. MSB, 32 vs 64).
      * If that's not possible, tools are run under qemu.
      * chroot is not used (because it would require root privileges),
        so tools need to support manipulating files not at their final
        destination (for example, tmp/sysroot/usr/ instead of /usr).
      * The environment prepared for the tools only consists of env
        variables. There's no concept of spawning additional daemons
        (doesn't matter whether it's dbus-daemon or gumd).

For gumd, a mode where the client tool embeds the daemon code directly
would be the best solution IMHO. A --sysroot parameter similar to gcc
would probably be useful/needed, too.
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.



More information about the Dev mailing list