[Dev] Gumd usage in building images

Rafał Krypa r.krypa at samsung.com
Fri Oct 17 17:25:07 GMT 2014


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] on behalf of Patrick Ohly [patrick.ohly at intel.com]
> Sent: 17 October 2014 10:37
> To: 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.


More information about the Dev mailing list