1:12 a.m.
So, basically, we have these files:
/etc/init.d/google-accounts-manager
/etc/init.d/google-address-manager
/etc/init/google-accounts-manager-service.conf
/etc/init/google-accounts-manager-task.conf
/etc/init/google-address-manager.conf
/usr/lib/systemd/system/google-address-manager.service
/usr/lib/systemd/system/google-accounts-manager.service
/usr/share/google/google_daemon/accounts_manager_daemon.py
/usr/share/google/google_daemon/address_manager.py
/usr/share/google/google_daemon/utils.py
/usr/share/google/google_daemon/manage_accounts.py
/usr/share/google/google_daemon/desired_accounts.py
/usr/share/google/google_daemon/accounts_manager.py
/usr/share/google/google_daemon/accounts.py
/usr/share/google/google_daemon/manage_addresses.py
My proposal:
/etc/init.d/google-accounts-manager
/etc/init.d/google-address-manager
No need for these. We can delete them... right?
/etc/init/google-accounts-manager-service.conf
/etc/init/google-accounts-manager-task.conf
/etc/init/google-address-manager.conf
Maybe these should go in /etc/sysconfig
/usr/lib/systemd/system/google-address-manager.service
/usr/lib/systemd/system/google-accounts-manager.service
Modify these so they point to /usr/share/google-daemon if possible.
/usr/share/google/google_daemon/accounts_manager_daemon.py
/usr/share/google/google_daemon/address_manager.py
/usr/share/google/google_daemon/utils.py
/usr/share/google/google_daemon/manage_accounts.py
/usr/share/google/google_daemon/desired_accounts.py
/usr/share/google/google_daemon/accounts_manager.py
/usr/share/google/google_daemon/accounts.py
/usr/share/google/google_daemon/manage_addresses.py
Move these to /usr/share/google-daemon
I'll show a spec in a little while.
--
It's hard to be free... but I love to struggle. Love isn't asked for;
it's just given. Respect isn't asked for; it's earned!
Renich Bon Ciric
http://www.woralelandia.com/
http://www.introbella.com/
2:42 a.m.
# SPEC and build script (just to fascilitate building it with mock)
https://github.com/renich/fedora-packages/tree/google-daemon
So, let me know what ya think. I know rsync might be a not-so-common
install solution but I didn't want to type it all. Anyway, they don't
provide a Makefile and they don't use submodules on the git repo;
which I've already asked for in this bug:
https://github.com/GoogleCloudPlatform/compute-image-packages/issues/82
There is another matter. /usr/share/google_daemon instead of
/usr/share/google-daemon (with a dash)... I think I can fix it in
%prep but I dunno if I should.
3:05 a.m.
Ok, just patched and tested.
It turns out systemd and config files where looking for stuff at
/usr/share/google/google_daemon; which I deliberately moved to
/usr/share/google_daemon.
Installed and the daemons are up. I'll try to add some users and see
what happens.
3:12 a.m.
Hah! Adding users works. Just noticed something odd.
jun 19 08:07:02 localhost.localdomain accounts-from-metadata[31449]:
INFO Creating account Juan
jun 19 08:07:02 localhost.localdomain useradd[31451]: new group:
name=Juan, GID=1004
jun 19 08:07:02 localhost.localdomain useradd[31451]: new user:
name=Juan, UID=1001, GID=1004, home=/home/Juan, shell=/bin/bash
jun 19 08:07:02 localhost.localdomain useradd[31451]: add 'Juan' to group
'adm'
jun 19 08:07:02 localhost.localdomain useradd[31451]: add 'Juan' to
group 'video'
jun 19 08:07:02 localhost.localdomain useradd[31451]: add 'Juan' to group
'dip'
jun 19 08:07:02 localhost.localdomain useradd[31451]: add 'Juan' to
shadow group 'adm'
jun 19 08:07:02 localhost.localdomain useradd[31451]: add 'Juan' to
shadow group 'video'
jun 19 08:07:02 localhost.localdomain useradd[31451]: add 'Juan' to
shadow group 'dip'
I dunno what the dip group is but... video?... Oh well... just sayin'
4:01 a.m.
Ok, the address manager works as well; buy you need to remove
/etc/hostname for it to work. Then, SELInux is gonna complain about
some things related to the hostname... maybe because the file does not
exist. But $HOSTNAME is set and all.
Another thing is that "add ssh key" functionality works, but it does
not remove it. I don't get messages about it on ausearch, journalctl
or any log. In short, nothing happens. This is not desirable and I
dunno if it's a bug of the daemon or something is blocking it.
The image survives a reboot and the daemons start and stay alive.
Btw, sorry if this thread seems like my journal. Just wanna keep track
of things.
9:12 a.m.
I have done that already some time ago:
https://github.com/vaijab/google-compute-daemon-rpm
On 19 June 2014 10:01, Renich Bon Ciric <renich(a)woralelandia.com> wrote:
Ok, the address manager works as well; buy you need to remove
/etc/hostname for it to work. Then, SELInux is gonna complain about
some things related to the hostname... maybe because the file does not
exist. But $HOSTNAME is set and all.
Another thing is that "add ssh key" functionality works, but it does
not remove it. I don't get messages about it on ausearch, journalctl
or any log. In short, nothing happens. This is not desirable and I
dunno if it's a bug of the daemon or something is blocking it.
The image survives a reboot and the daemons start and stay alive.
Btw, sorry if this thread seems like my journal. Just wanna keep track
of things.
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Vaidas Jablonskis
5:25 p.m.
On Thu, Jun 19, 2014 at 9:12 AM, Vaidas Jablonskis <jablonskis(a)gmail.com> wrote:
I have done that already some time ago:
https://github.com/vaijab/google-compute-daemon-rpm
Ah, great. I see you kept the /usr/share/google dir. It might be a
good idea to do that, but it is not very standard IMHO. The one I have
uses /usr/share/google_daemon with a little patch. But the rest of the
code needs the patch as well if we're to use that location. some of
the code looks for files in /usr/share/google; for example,
first-boot.
--
It's hard to be free... but I love to struggle. Love isn't asked for;
it's just given. Respect isn't asked for; it's earned!
Renich Bon Ciric
http://www.woralelandia.com/
http://www.introbella.com/
7:57 p.m.
On Thu, Jun 19, 2014 at 6:25 PM, Renich Bon Ciric
<renich(a)woralelandia.com> wrote:
On Thu, Jun 19, 2014 at 9:12 AM, Vaidas Jablonskis
<jablonskis(a)gmail.com> wrote:
> I have done that already some time ago:
> https://github.com/vaijab/google-compute-daemon-rpm
Ah, great. I see you kept the /usr/share/google dir. It might be a
good idea to do that, but it is not very standard IMHO. The one I have
uses /usr/share/google_daemon with a little patch. But the rest of the
code needs the patch as well if we're to use that location. some of
the code looks for files in /usr/share/google; for example,
first-boot.
I would vote against changing paths here. /usr/share/google is not
that strange. There are plenty of examples in /usr/share where the
next directory is for a collection of packages: games, man, java,
gems, etc. Deviating from upstream in this case just complicates
maintenance of the packages over time. (If there's some reason the
files should not be in /usr/share at all, that's a different
conversation.)
Andy
--
It's hard to be free... but I love to struggle. Love isn't asked for;
it's just given. Respect isn't asked for; it's earned!
Renich Bon Ciric
http://www.woralelandia.com/
http://www.introbella.com/
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
1:22 a.m.
On Mon, Jun 23, 2014 at 7:57 PM, Andy Grimm <agrimm(a)gmail.com> wrote:
I would vote against changing paths here. /usr/share/google is not
that strange. There are plenty of examples in /usr/share where the
next directory is for a collection of packages: games, man, java,
gems, etc. Deviating from upstream in this case just complicates
maintenance of the packages over time. (If there's some reason the
files should not be in /usr/share at all, that's a different
conversation.)
Yeah, you're right. I can think of java doing that and stuff. Besides,
I do not wanna get into the problem of maintaining my own paths.
--
It's hard to be free... but I love to struggle. Love isn't asked for;
it's just given. Respect isn't asked for; it's earned!
Renich Bon Ciric
http://www.woralelandia.com/
http://www.introbella.com/
8:52 a.m.
On 06/24/2014 01:22 AM, Renich Bon Ciric wrote:
On Mon, Jun 23, 2014 at 7:57 PM, Andy Grimm <agrimm(a)gmail.com>
wrote:
> I would vote against changing paths here. /usr/share/google is not
> that strange. There are plenty of examples in /usr/share where the
> next directory is for a collection of packages: games, man, java,
> gems, etc. Deviating from upstream in this case just complicates
> maintenance of the packages over time. (If there's some reason the
> files should not be in /usr/share at all, that's a different
> conversation.)
Yeah, you're right. I can think of java doing that and stuff. Besides,
I do not wanna get into the problem of maintaining my own paths.
Just to check, I looked at my F21 (rawhide) Fedora /usr/share directory.
There are 287 directories in there, and 1 file. So, the ratio is 287 to
1 in favor of using a directory. :)
Though ... that's not the real reason I was sending this.
I don't want to slow your progress down, but I have on my roadmap plans
to create some RHEL6 and RHEL7 images for GCE. I'm pretty sure I'll be
able to user your rpm for RHEL7, but just keep in mind that someone will
probrubly come behind you and put your package in EPEL6.
So when you get rid of the init.d files, please do that in the spec
file, and not somewhere before. That way I'll just have to make changes
to the spec file and not create a new tarball or something like that.
Thank you for all the work you've been doing on this.
Troy
9:02 a.m.
On 06/24/2014 08:52 AM, Troy Dawson wrote:
On 06/24/2014 01:22 AM, Renich Bon Ciric wrote:
> On Mon, Jun 23, 2014 at 7:57 PM, Andy Grimm <agrimm(a)gmail.com> wrote:
>> I would vote against changing paths here. /usr/share/google is not
>> that strange. There are plenty of examples in /usr/share where the
>> next directory is for a collection of packages: games, man, java,
>> gems, etc. Deviating from upstream in this case just complicates
>> maintenance of the packages over time. (If there's some reason the
>> files should not be in /usr/share at all, that's a different
>> conversation.)
>
>
> Yeah, you're right. I can think of java doing that and stuff. Besides,
> I do not wanna get into the problem of maintaining my own paths.
>
Just to check, I looked at my F21 (rawhide) Fedora /usr/share directory.
There are 287 directories in there, and 1 file. So, the ratio is 287 to
1 in favor of using a directory. :)
Though ... that's not the real reason I was sending this.
I don't want to slow your progress down, but I have on my roadmap plans
to create some RHEL6 and RHEL7 images for GCE. I'm pretty sure I'll be
able to user your rpm for RHEL7, but just keep in mind that someone will
probrubly come behind you and put your package in EPEL6.
So when you get rid of the init.d files, please do that in the spec
file, and not somewhere before. That way I'll just have to make changes
to the spec file and not create a new tarball or something like that.
Thank you for all the work you've been doing on this.
Troy
Of course, after I send this I see your emails with links to your src.rpm.
Looks good to me, and thanks for all your efforts.
Troy
9:32 a.m.
On Tue, Jun 24, 2014 at 8:52 AM, Troy Dawson <tdawson(a)redhat.com> wrote:
Just to check, I looked at my F21 (rawhide) Fedora /usr/share
directory.
There are 287 directories in there, and 1 file. So, the ratio is 287 to
1 in favor of using a directory. :)
Though ... that's not the real reason I was sending this.
Well, google-daemon is actually another directory, but I get your point ;=)
I don't want to slow your progress down, but I have on my roadmap
plans
to create some RHEL6 and RHEL7 images for GCE. I'm pretty sure I'll be
able to user your rpm for RHEL7, but just keep in mind that someone will
probrubly come behind you and put your package in EPEL6.
So when you get rid of the init.d files, please do that in the spec
file, and not somewhere before. That way I'll just have to make changes
to the spec file and not create a new tarball or something like that.
Thank you for all the work you've been doing on this.
Awesome, thanks. Cheers! We're all doing our part ;=)
--
It's hard to be free... but I love to struggle. Love isn't asked for;
it's just given. Respect isn't asked for; it's earned!
Renich Bon Ciric
http://www.woralelandia.com/
http://www.introbella.com/
1:33 p.m.
> I don't want to slow your progress down, but I have on my
roadmap plans
> to create some RHEL6 and RHEL7 images for GCE. I'm pretty sure I'll be
> able to user your rpm for RHEL7, but just keep in mind that someone will
> probrubly come behind you and put your package in EPEL6.
> So when you get rid of the init.d files, please do that in the spec
> file, and not somewhere before. That way I'll just have to make changes
> to the spec file and not create a new tarball or something like that.
Hey Troy, one of my clients actually needs CentOS7 in GCE. I will
start work on the image with virt-builder; which is the easiest tool
to accomplish the job. Does this suit you as well?
--
It's hard to be free... but I love to struggle. Love isn't asked for;
it's just given. Respect isn't asked for; it's earned!
Renich Bon Ciric
http://www.woralelandia.com/
http://www.introbella.com/
11:39 p.m.
Hi Renich,
How is your progress so far?
One other useful set of tools to include in the image is "gcutil",
"gsutil" and "gcloud".
https://developers.google.com/compute/docs/images#stronglyrecommendedpack...
I think packaging those might be tricky. I just checked the centos-6
image and they're clearly simply untarring it under
/usr/local/share/google/google-cloud-sdk and creating symlinks under
/usr/local/bin to make them available in the search path. Clearly not
ideal, I think we can do better than that.
Do you know if it would be possible to build an official GCE image
through the official build system? I mean, spin it through Koji, using
imagefactory, Oz and including the google-compute-daemon package you
built and possibly other packages for the cloud SDK as well?
Long term, I agree the way to go is towards a unified image using
cloud-init, but having a proof of concept that could serve as an
official image right away would be tremendously helpful...
Let me know how I can help!
Cheers,
Filipe
3564
days inactive
3598
days old
13 comments
5 participants
participants (5)
-
Andy Grimm -
Filipe Brandenburger -
Renich Bon Ciric -
Troy Dawson -
Vaidas Jablonskis