Saturday, March 4, 2017

SSSD: {DBus,Socket}-activated responders (2nd try!)

Second time's the charm! :-)


Since the first post about this topic some improvements have been done in order to fix a bug found and reported by a Debian user (Thanks Stric!).

The fix is part of SSSD 1.15.1 release and altogether with the release, some other robustness improvements have been done! Let's go through the changes ...


Avoid starting the responders before SSSD is up!


I've found out that the NSS responder had been started up before SSSD and it's quit problematic during the boot up process as libc does initgroups on pretty much any account, checking all NSS modules in order to be precise.

By calling sss_nss the NSS responder is triggered and tries to talk to the data providers (which are not up yet, as SSSD is not up yet ...), causing the boot up process to hang until libc gives up (causing a timeout on services like systemd-login and all the services depending on this one).

The fix for this issue looks like:
1
2
3
4
5
6
7
8
@@ -1,6 +1,7 @@
  [Unit]
  Description=SSSD @responder@ Service responder socket
  Documentation=man:sssd.conf(5)
+ After=sssd.service
  BindsTo=sssd.service
 
  [Socket]

And, as I've been told by systemd developers that "BindsTo=" must always come together with "After=" (although it is not documented yet ...) this fix has been applied for all responders' unit files.


Avoid starting the responders' sockets before SSSD is up!


We really want (at least for now) to have the responders' sockets completely tied up to SSSD service. We want the responders to be socket-activated only after SSSD is up and just right above this section you can see an explanation why we want to have this kind of control.

In order to achieve this some changes were needed in the sockets' units, as systemd automatically adds "Before=sockets.target" to any socket unit by default (and sockets.target is started up in an really early phase of the boot process).

And there I went again to talk to systemd developers about the best approach to do not start the responder's sockets before SSSD is up and the patch that came out as a result of the discussion looks like:

1
2
3
4
5
6
7
8
9
@@ -3,6 +3,8 @@
  Documentation=man:sssd.conf(5)
  After=sssd.service
  BindsTo=sssd.service
+ DefaultDependencies=no
+ Conflicts=shutdown.target

  [Socket]
  ListenStream=@pipepath@/@responder@

By doing this change the sockets are no longer started before sockets.target, but just after SSSD service is started. The downside of this approach is that we have to deal with conflicts by our own and that is the reason the "Conflicts=shutdown.target" has been added.


Be more robust against misconfigurations!


As now that we have two completely different ways to manage the services, we really have to be robust in order to avoid that the admins will mix them up wrongly.

So far we have been flexible enough to allow admins to have some of the services being started up by the monitor, while other services left for systemd. And it's okay! The problem would start when the monitor has been told to start a responder (by having the responder listed in the services' line of sssd.conf) and this very same responder is supposed to be socket-activated (the admin did systemctl enable sssd-@responder@.socket).

In the situation describe above we could end up with two responders' services running (for the very same responder). The best way found to fix this issue is adding a simple program to check whether the socket-activated responder is also mentioned in the sssd.conf services' line. In case it's mentioned there, just do not start the socket up and leave the whole responsibility to the monitor. Otherwise, take advantage of systemd machinery!

The change on the sockets' unit looks like:
1
2
3
4
5
6
7
8
@@ -7,6 +7,7 @@
  Conflicts=shutdown.target

  [Socket]
+ ExecStartPre=@libexecdir@/sssd/sssd_check_socket_activated_responders -r @responder@
  ListenStream=@pipepath@/@responder@
  SocketUser=@SSSD_USER@
  SocketGroup=@SSSD_USER@


Also, I've decided to be a little bit stricter on our side and also refuse manual start up of the responders' services and the change for this looks like:
1
2
3
4
5
6
7
8
@@ -3,6 +3,7 @@
  Documentation=man:sssd.conf(5)
  After=sssd.service
  BindsTo=sssd.service
+ RefuseManualStart=true

  [Install]
  Also=sssd-@responder@.socket


And how can I start using the socket-activated services?


As by default we still use the monitor to manage services, some little configuration change is need.

See the example below explaining how to enable the PAM and AutoFS services to be socket-activated.

Considering your /etc/sssd/sssd.conf has something like:

1
2
3
[sssd]
services = nss, pam, autofs
...

Enable PAM and AutoFS responders' sockets:
# systemctl enable sssd-pam.socket
# systemctl enable sssd-autofs.socket

Remove both PAM and AutoFS responders from the services' line, like:

1
2
3
[sssd]
services = nss
...

Restart SSSD service
    # systemctl restart sssd.service
    

    And you're ready to go!


    Is there any known issue that I should be aware of?


    Yes, there is! You should avoid having PAC responder, needed by IPA domains, socket-activated for now. The reason for this is that due to an ugly hack on SSSD code this responder is added to the services' list anytime an IPA domain is detected.

    By doing this, the service is always started by the monitor and there is nothing that could be done on our socket's units to detected this situation and avoid starting up the PAC socket.

    A possible way to fix this issue is patching ipa-client-install to either explicitly add the PAC responder to the services' list (in case the admin wants to keep using the monitor) or to enable the PAC responders' socket (in case the admin wants to take advantage of socket-activation).

    Once it's done on IPA side, we would be able to drop the code that enables the PAC responder automatically from SSSD. However, doing this right now would break backwards compatibility!


    Where can I find more info about SSSD?


    More information about SSSD can be found on the project page: https://pagure.io/SSSD/sssd/

    If you want to report us a bug, please, follow this web page and file an issue in the SSSD pagure instance.

    Please, keep in mind that currently we're in the middle of a migration process from FedoraHosted to Pagure and it will take a while to have everything in place, again.

    Even though, you can find more info about SSSD's internals here.

    In case you want to contribute to the project, please, read this webpage and feel free to approach us at #sssd on freenode (irc://irc.freenode.net/sssd).

    Tuesday, January 31, 2017

    SSSD: {DBus,Socket}-activated responders!

    Since its 1.15.0 release, SSSD takes advantage of systemd machinery and introduces a new way to deal with the responders.

    Previously, in order to have a responder initialized, the admin would have to add the specific responder to the "services" line in sssd.conf file, which does make sense for the responders that are often used but not for those rarely used (as the infopipe and PAC responders for instance).

    This old way is still preserved (at least for now) and this new release is fully backwards-compatible with the old config file.

    For this new release, however, adding responders to the "services" isn't needed anymore as the admin can easily enable any of the responders' sockets and those will be {dbus,socket}-activated on demand and will be up while are still being used. In case the responder becomes idle, it will automatically shut itself down after a configurable amount of time.

    The sockets we've created are: sssd-autofs.socket, sssd-nss.socket, sssd-pac.socket, sssd-pam.socket (and sssd-pam-priv.socket, but you don't have to worry about this one), sssd-ssh.socket and sssd-sudo.socket. As an example, considering the admins want to enable the sockets for both NSS and PAM responders, they should do: `systemctl enable sssd-pam.socket sssd-nss.socket` and voilà!

    In some cases the admins may also want to set the "responder_idle_timeout" option added for each of the responders in order to tweak for how long the responder will be running in case itbecomes idle. Setting this option to 0 (zero) disables the responder_idle_timeout. For more details, please, check sssd.conf man page.

    For this release we've taken a more conservative path and are leaving up to the admins to enable the services they want to have enabled in case they would like to try to using {dbus,socket}-activated responders

    It's also important to note that while the SELinux policies are not updated in your distro you may need to have SELinux in permissive mode in order to test/use the {dbus,socket}-activated responders. A bug for this is already filed for Fedora and hopefully will be fixed before the new package is included in the distro.

    And the changes in the code were (a high-level explanation) ...

    Before this work the monitor was the piece of code responsible for handling the responders listed in the services' line of sssd.conf file. And by handling I mean:

    • Gets the list of services to be started (and, consequently, the total number of services);
    • For each service:
      • Gets the service configuration;
      • Starts the service;
      • Adds the service to the services' list;
      • Once the service is up, a dbus message is sent to the monitor, which ...
        • Sets up the sbus* connection to communicate with the service;
        • Marks the service as started;

    Now, the monitor does (considering an empty services' line):

    • Once the service is up, a dbus message is sent to the monitor;
      • The number of services is increased;
      • Gets the service configuration;
      • Adds the service to the services' list
      • Sets up the sbus connection to communicate with the service;
      • Sets up a destructor to the sbus connection in order to properly shutdown the service when this connection is closed;
      • Marks the service as started;

    By looking at those two different processes done by the monitor, some of you may have realized an extra step needed when the service has been {dbus,socket}-activated that was needed at all before. Yep, "Sets up a destructor to the sbus connection in order to properly shutdown the service when this connection is closed" is a completely new thing as, previously, the services were just shut down when SSSD was shut down and now the services are shutdown when they become idle.

    So, what's basically done now is:
     - Once there's no communication to the service, it's (sbus) connection with the monitor is closed;
     - Closing the (sbus) connection triggers the following actions:
        - The number of services is decreased;
        - The connection destructor is unset (otherwise it would be called again on the service has been freed);
        - Service is shut down:

    *sbus: SSSD uses dbus protocol over a private socket to handle its internal communication, so the services do not talk over system bus.

    And how do the unit files look like?

    SSSD has 7 services: autofs, ifp, nss, pac, pam, ssh and sudo. From those 7 services 4 of them have pretty much these unit files:

    AutoFS, PAC, SSH and Sudo unit files:


    sssd-$responder.service:
    [Unit]
    Description=SSSD $(responder) Service responder
    Documentation=man:sssd.conf(5)
    After=sssd.service
    BindsTo=sssd.service
    
    [Install]
    Also=sssd-$responder.socket
    
    [Service]
    ExecStartPre=-/bin/chown $sssd_user:$sssd_user /var/log/sssd/sssd_autofs.log
    ExecStart=/usr/libexec/sssd/sssd_$responder --debug-to-files --socket-activated
    Restart=on-failure
    User=$sssd_user
    Group=$ssd_user
    PermissionsStartOnly=true

    sssd-$responder.socket:
    
    
    
    
    [Unit]
    Description=SSSD $(responder) Service responder socket
    Documentation=man:sssd.conf(5)
    BindsTo=sssd.service
    
    [Socket]
    ListenStream=/var/lib/sss/pipes/$responder
    SocketUser=$sssd_user
    SocketGroup=$sssd_user
    
    [Install]
    WantedBy=sssd.service
    


    And about the different ones? We will get there ... and also explain why they are different.

    The infopipe (ifp) unit file:

    As the infopipe won't be socket-activated, it doesn't have the its respective .socket unit.
    Also, differently than the others responders the infopipe responder can only be run as root nowadays.
    In the end, its .service unit looks like:

    sssd-ifp.service:
    [Unit]
    Description=SSSD IFP Service responder
    Documentation=man:sssd-ifp(5)
    After=sssd.service
    BindsTo=sssd.service
    
    [Service]
    Type=dbus
    BusName=org.freedesktop.sssd.infopipe
    ExecStart=/usr/libexec/sssd/sssd_ifp --uid 0 --gid 0 --debug-to-files --dbus-activated
    Restart=on-failure

    The PAM unit files:

    The main difference between PAM responder and the others is that PAM has two sockets that can end up socket-activating its service. Also, these sockets have a special permission.
    In the end, its unit files look like:

    sssd-pam.service:
    [Unit]
    Description=SSSD PAM Service responder
    Documentation=man:sssd.conf(5)
    After=sssd.service
    BindsTo=sssd.service
    
    [Install]
    Also=sssd-pam.socket sssd-pam-priv.socket
    
    [Service]
    ExecStartPre=-/bin/chown $sssd_user:$sssd_user @logpath@/sssd_pam.log
    ExecStart=@libexecdir@/sssd/sssd_pam --debug-to-files --socket-activated
    Restart=on-failure
    User=$sssd_user
    Group=$sssd_user
    PermissionsStartOnly=true
    

    sssd-pam.socket:
    [Unit]
    Description=SSSD PAM Service responder socket
    Documentation=man:sssd.conf(5)
    BindsTo=sssd.service
    BindsTo=sssd-pam-priv.socket
    
    [Socket]
    ListenStream=@pipepath@/pam
    SocketUser=root
    SocketGroup=root
    
    [Install]
    WantedBy=sssd.service
    

    sssd-pam-priv.socket:
    [Unit]
    Description=SSSD PAM Service responder private socket
    Documentation=man:sssd.conf(5)
    BindsTo=sssd.service
    BindsTo=sssd-pam.socket
    
    [Socket]
    Service=sssd-pam.service
    ListenStream=@pipepath@/private/pam
    SocketUser=root
    SocketGroup=root
    SocketMode=0600
    
    [Install]
    WantedBy=sssd.service
    

    The NSS unit files:

    The NSS responder was the trickiest one to have working properly, mainly because when socket-activated it has to run as root.
    The reason behind this is that systemd calls getpwnam() and getgrnam() when using "User="/"Group=" different than root. By doing this libc ends up querying for $sssd_user, trying to talk to NSS responder which is not up yet and then the clients would end up hanging for a few minutes (due to our default_client_timeout) which is something we really want to avoid.

    In the end, its unit files look like:

    sssd-nss.service:
    Description=SSSD NSS Service responder
    Documentation=man:sssd.conf(5)
    After=sssd.service
    BindsTo=sssd.service
    
    [Install]
    Also=sssd-nss.socket
    
    [Service]
    ExecStartPre=-/bin/chown root:root @logpath@/sssd_nss.log
    ExecStart=@libexecdir@/sssd/sssd_nss --debug-to-files --socket-activated
    Restart=on-failure
    

    sssd-nss.socket:
    [Unit]
    Description=SSSD NSS Service responder socket
    Documentation=man:sssd.conf(5)
    BindsTo=sssd.service
    
    [Socket]
    ListenStream=@pipepath@/nss
    SocketUser=$sssd_user
    SocketGroup=$sssd_user
    

    All the services' units have a "BindsTo=sssd.service" in order to ensure that the service will be stopped when sssd.service is stopped so in case SSSD is shutdown/restart those actions will be propagated to the responders as well.

    Similarly to "BindsTo=ssssd.service" there's "WantedBy=sssd.service" in every socket unit and it's there to ensure that, once the socket is enabled it will be automatically started by SSSD when SSSD is started.

    And that's pretty much all changes that I've covered with this work.

    I really have to say a big thank you to ...

    • Lukas Nykryn and Michal Sekletar who patiently reviewed the unit files we're using and gave me a lot if good tips while doing this work;
    • Sumit Bose who helped me to find out the issue with the NSS responder when trying to run it as a non-privileged user;
    • Jakub Hrozek, Lukas Slebodnik and Pavel Brezina for reviewing and helping me to find bugs, crashes, regressions that fortunately were avoided.

    And what's next?

    There's already a patch making the {dbus,socket}-activated automatically enabled when SSSD starts, which changes our approach from having to explicit enable the sockets in order to take advantage of this work to explicitly mask the disable (actually, mask) the sockets of the processes that shouldn't be {dbus,socket}-activated.

    Also, a bigger work for the future is to also have the providers being socket-activated, but this is material for a different blob post. ;-)

    Nice, nice. But I'm having issues with what you've described!

    In case it happens to you, please, keep in mind that the referred way to diagnose any issues would be:

    • Inspecting sssd.conf in order to check which are the explicitly activated responders in the services' line;
    • `systemctl status sssd.service`;
    • `systemctl status sssd-$responder.service` (for the {dbus,socket}-activated ones);
    • `journalctl -u sssd.service`;
    • `journalctl -u sssd-$responder.service` (for the {dbus,socket}-activated ones);
    • `journalctl -br`;
    • Checking SSSD debug logs in order to see whether SSSD sockets where communicated

    Sunday, December 25, 2016

    2016

    It's been quite a long time I don't write anything here and the main reason is that I've been quite busy lately. But, well, as the end of the year has been approaching quite faster than expected I guess this is the right time to, at least, sum up what happened during the last year or so.

    2016 hasn't been exactly what I'd call the "best year of my life" but some important stuff have happened and are worth to mention ...

    Pain! A lot of pain!
    By the beginning of the year I had a few back problems. They were not exactly related to each other, but all of them related to overweight. :-\.

    So, in February I had a pilonidal cyst, which came back a few times over the year just to remind me to update my definition of pain. It's something quite simple to treat, but the pain can be really horrible
    There's a surgery that can be done in order to (try to) fix the root cause of the issue but the recovering process seems way less appealing than treating it a few times per year when needed.

    Apart from this issue, I've started feeling some pain on my lower-back that, after a few days, went all the way down to my knee and for a few weeks limited my movements. Finding the root-cause of this issue was not so easy, but thanks to Pavel Grunt's mother I ended up visiting a neurologist who found it out: a slipped disc!
    Again, there's a surgery that can be done and, again, I decided to try to work it around.

    Time to change?
    I clearly remember a friend of mine who told you "(...) at some point you'll have to re-think your habits (...)". Seems that the time has arrived and there were a lot of things that weren't making me exactly happy about my life. So, I've decided to give a try and change two of those.

    So long, SPICE!
    I've worked on SPICE for circa 2 years, mainly working on the client-side (spice-gtk and virt-viewer) for both Windows and Linux. An experience that I, sincerely, can't complain.

    Both the project and the people there are amazing but I wasn't feeling as excited as I knew I could feel. So, with the heart-broken and quite uncertain about the future, I've decided to leave the project. I've decided to search for something else and have a completely new thing to occupy my mind during 8+ hours/day.

    Nice to meet you, SSSD!
    SSSD was my primary target and choice.  Why? Well, I'm not sure I could answer this question by that time. I'm still not sure I could answer this question right now.
    What I can tell, for sure, is that I feel more and more like I've chosen wisely.

    Work-wise the change has been quite satisfactory. I'm spending way more time writing code than I was when working for the SPICE team. As pretty much everything related to Identity Management is new to me, I'm (naturally) spending way more time learning stuff than I was during the last year working for the SPICE team.

    Adaptation period
    It's really important to mention that the adaptation period was not as smooth as I thought it would be. I moved from a completely international team to a team where I'm the only "foreigner" (well, the team is a mix of Czechs and Slovaks, but they speak their local language when talking to each other) and it was a big culture shock as, due to the language barrier, I wasn't able to feel part of the team, I wasn't able to feel comfortable to interact with the team and it was really really hard for me.

    Talk to people! Just calm down and talk to people!
    It seems quite obvious but, well, it isn't!

    After a lot of talks with my manager, with some people from the office that went through the same shock ... I've decided to talk to my colleagues. After the talk, the situation has been improving quite a lot. And, for sure, what I felt during the first weeks is just a water over the bridge nowadays.

    An important point to bring up here is the reason behind this whole situation. People (usually) won't speak their local language because they don't want you to understand the context or anything similar (although, is really hard to avoid that impression). Of course, it may happen, but in the most part of the cases it just happens because they don't even know the impact it may cause in their colleagues. In case it happens to you, at some point of your life, just let them know about the situation (in a polite way, of course) and I guess the outcome will be beneficial for both sides.

    After the storm comes the calm
    Now, after a few months working on SSSD (and together with FreeIPA) I finally feel comfortable enough to say that my decision to join this team was the really good.

    During this whole changing period, some meetings happened inside Brno's office in order to find out what could be done to improve the "well-being" for foreigners here. Some points were raised, some changes already can be seen, which is quite good. Those changes have been pushed (mainly) by Jana Chvalkovska and her team. So, sincerely, I'm proud to see things moving to a good direction.

    Also, as I mentioned before in the "Pain! A lot of pain!" section, a common cause for both problems that I had was my overweight. Well, I've been working on this as well. So far I've been able to lose 45+kg and there are 30kg more to go along this year that is coming. Let's see whether I'll be able to reach my goal ...

    Am I happy in the end?
    Yes. Happier than in the beginning of the year, for sure. Personal life has been going well. Work has been going well.

    So, I guess there's nothing really serious that I could complain about ...

    Any expectation for the next year?
    As, at some point of my life, I've learned that the most effective way to avoid frustrations is to lower the expectations, let's say that outlive 2017 with less pain would be good enough. :-)
    And if things keep going as they are right now there's a big chance it can easily happen.

    Sunday, February 22, 2015

    Willing to talk about Czech history? I'm willing to hear what you have to say!

    Last Friday, when I was leaving Šelepka, I was approached by a small group of Czech people that, among other things, gave me a (though "non requested") quite nice lesson of Czech history. One of the guys, who seemed to be a History teacher, told us about Pod Kaštany, a concentration camp where over 600 people were executed or tortured to death ... and it was just in the place where we were. Although I have to admit that stopping people in the streets talking about concentration camps may not be the best approach to start a conversation, I was more than happy to learn a bit about what happened there.

    An interesting thing is that they have a monument there that, even I'm passing by in front of it almost every day, I've never stopped and tried to understand what was written there. Quite sad, right? I do agree and that's the reason I'm trying to start a "project" (if I can call it in this way ...). Every Wednesday I'll try to go to Alterna to meet with Czech people willing to share histories about Brno (or Czech Republic in general), people that are willing to sit, drink a beer and talk about the history of their own Country. What can I offer for these people? Not much, actually. I can be a partner for beer, a good listener and, if agreed beforehand, I can share a bit of the Brazilian history (I'm kinda into social movements, women rights, gay rights, drugs' decriminalization ... and I can talk a bit about interesting stuff we had [or not] in all of these topics in the last centuries in Brazil). :-)

    So, interested? Drop me a message and we can arrange something!

    Saturday, November 29, 2014

    Yesterday a Genius passed away

    First thing, sorry for this completely non-technical post going to technical planets. If you don't want to ready about a completely emotional stuff, just stop reading now.

    I'm a Brazilian that was born in the end of the 80's and grew up in the beginning of the 90's. Took me some time to have a telly at home, my parents were not so in favor of it. till the time they gave up following the religious rules ...
    I remember the telly installed in a up corner of the room, it was a small one (14"). At that point I was experimenting a new world of four non-paid channels that we had access to. News, movies (from the 70's), culinary programs ... but one thing, in special, got my attention. It was a TV show about a "guy", with no name, with no family, living in a villa with: a poor widower dad and his smart daughter (the mom died during the birth), a middle-class widow mother and her spoiled son (the dad was a sailor that died in one of his travels), an old single woman (that loves the single dad), a teacher of the kids' school (in love with the single mom) and the owner of the villa, a rich and generous fat man that shows up every now and then to collect the rent, never paid by the widower dad. It was amazing, goddamn, it *is* amazing. A ~30 minutes episode (in Brazil we never had access to more than ~100 episodes), right after lunch, about this villa and the central character. The original name of the show is "El Chavo del 8". Episodes of "El Chavo del 8" where interleaved with episodes of "El Chapulín Colorado", a not strong, not smart, not fast, not powerful and not handsome hero, that always showed up to help anyone who asked for, usually in the most jumbled way, causing more confusion than actually helping. He was a perfect anti-hero. Goddamn, I cannot say how much I like these stupid TV shows. I remember my family sitting together and watching the Christmas special, the same one, for 10 years in a row. And it was better than the Christmas itself. Yesterday the genius who wrote these TV shows, and played the main character of both, passed way. Latino Americans with my age (+/- 10) are, for sure, sad today.
    If you don't know this genius but are interested in: http://en.wikipedia.org/wiki/Chespirito
    For those who feel the same pain, let's think that the man died, the legend will always be alive in our memories/hearts.



    Buenas noches, maestro Bolaños!

    Thursday, November 27, 2014

    virt-viewer (using gtk3) for Windows

    For the last few weeks I've been spending some time to have virt-viewer,
    using gtk3, running on Windows. And it finally works!

    Here is a not so brief description about the projects that I've hacked on (and the problems I've faced out during the process). if you're not interested in the process, just scroll down till the end of the email, where you will find the installer and a few instructions about what you need to generate the installer by yourself.

    - msitools:
    Apart from the broken build system on F21[0] and the wixl-heat generating the same ID for dirs used by other libraries/components[1] I have added .wxi files for the virt-viewer dependencies in order to have a build using gtk3. The dependencies are basically 3: 
    - gtk3 itself[2]
    - spice-gtk3[3]
    - gtk-vnc2[4].
    All the .wxi files were generated following the "How To" in the msitools webpage[5].
    [0]: https://git.gnome.org/browse/msitools/commit/?id=c4c397438b797de4e68bb6d7fb891872db9e7bab
    [1]: https://git.gnome.org/browse/msitools/commit/?id=41db587bae5a6c4cbc8f40a52bf2d6f25416653f
    [2]: https://git.gnome.org/browse/msitools/commit/?id=c03676f95a348fd7da511355398f3a073400f819
    [3]: https://git.gnome.org/browse/msitools/commit/?id=08cdc65a46f9eaaf49cd0acde0c3aaead341973d
    [4]: https://git.gnome.org/browse/msitools/commit/?id=19c465b9f89583cdc905609abfd9cfb2c6beb26f
    [5]: https://wiki.gnome.org/msitools/HowTo/CreateLibraryWxi

    - virt-viewer:
    Once that msitools has all the necessary bits included, it is time to hack a bit on virt-viewer and provide a way to generate the .msi file for virt-viewer using gtk3[6]. It is quite simple and basically a copy and paste from the file we already have been using for gtk2. just changing the dependencies and installation folder (just to avoid myself getting confused with the versions and so on).
    [6]: https://fedorapeople.org/cgit/fidencio/public_git/virt-viewer.git/commit/?h=wip/msi-gtk3&id=4495b42a23ba5a795185bea0cadc540126b58751

    After generate and install the .msi file on my Windows VM I crossed my fingers and ran remote-viewer!
    Well, the results were not exactly the expected ones. A crash in libGdk-3.0.dll with no more info could be seen and also a lack of icons.

    Okay, okay. First things first. Let me try to hunt this crash. Where can I start from? Hmmm. What about getting a debugger? :-)

    - gdb:
    Just got the binary from the mingw sourceforge webpage[7]
    [7]: http://sourceforge.net/projects/mingw/files/MinGW/Extension/gdb/

    Now I have the gdb, let me hunt the crash!
    gdb.exe remote-viewer.exe ... and more problems! There were no debug-symbols in any of the packages I've been using ... and I need them!

    - debugging:
     - approach 1 - -debug packages are your friends: well, not always. I've
    installed the -debug packages and have added the new installed files
    into the respective .wxi files. Then I've generated a new build and ... same crash, same poor info I had before (and nothing more). :-(
     - approach 2 - compile everything by yourself: this is what worked for me, but we have to agree that it's not exactly the most handy thing to do when you just want to debug something. Also, it inserted new bugs when launching the application, something about missing files that, for sure, were in the correct path. Anyways, it helped me to debug and I found that the Gdk crash could be avoided with a simple patch on spice-gtk[8].
    [8]: http://cgit.freedesktop.org/spice/spice-gtk/commit/?id=b0703419bf15facc0527a81afbb3b07e67de909b

    Yay! Now I have the virt-viewer working, but still no icons (apart from
    the ones provided by virt-viewer itself).

    For the icons problem, here is the basic solution:
    - Build the .msi file using only the needed icons from the system installed adwaita-icon-theme. It works pretty well for virt-viewer, but if any other app tries to take advantage of the gtk3 on Windows, the app *must* have to do the same.

    Yay, again! virt-viewer shows all the icons! Let's do some tests ... I've started by clicking in the menu options. The first one: "File -> Screenshot" ... and then crash!
    Okay, this is an easy one. Basically I had to include the schemas.compiled[9] and schemas.dtd[10] into our gtk3 .wxi file, They are not being included because these files are not distributed with the .rpm, they are generated during the rpm's installation process.
    [9]: https://fedorapeople.org/cgit/fidencio/public_git/msitools.git/commit/?h=wip/gtk3&id=e8990a125537ead4fad5d1adedc028cd72f5c932
    [10]: https://fedorapeople.org/cgit/fidencio/public_git/msitools.git/commit/?h=wip/gtk3&id=97eefd9a3279a1766c81e54b0eb0e5660fece737

    And now, finally, we are able to have a functional build of virt-viewer for windows using gtk3!

    Do you want to try the build?
    https://fidencio.fedorapeople.org/virt-viewer-gtk3-x86-2.0.msi
    https://fidencio.fedorapeople.org/virt-viewer-gtk3-x64-2.0.msi

    Do you want to build it by your self?
    Okay, you'll need to:
    - mingw-spice-gtk with my patch (build already pushed to f21):
    https://fidencio.fedorapeople.org/mingw-spice-gtk/

    - virt-viewer with my patches:
    https://fedorapeople.org/cgit/fidencio/public_git/virt-viewer.git/log/?h=wip/msi-gtk3

    Compile and install msitools from git. Install mingw-spice-gtk and gtk-vnc2 packages. Then, inside the virt-viewer folder, do:
     $ mingw32-configure --with-spice-gtk --with-gtk=3.0
     $ make
     $ make -C data/ msi-gtk3

    Next steps:
    - generate the gtk2 or gtk3 build according to the configure options.
    - add support for foreign menu for Windows.

    Saturday, August 2, 2014

    and GUADEC is over!

    The conference was great, as usual, and quite more organized than I've expected (maybe I got a wrong impression due the issues that happened a few weeks before).
    Kudos for Monsieur and Madame Franke for all the time spent on that. Special thanks for all volunteers as well!

    I'm really happy that I had the opportunity to meet a few people there, that I've been working with but, till GUADEC, were just an IRC name. :-)

    I want to thank Bastien Nocera, Felipe Borges, Rafael Martins, Victor Toso and Yuuma Sato (the dealers of Brazilian food), you guys made a couple really happy! \o/
    I also want to thank Nimit for the Taj Mahal gift, man, it's awesome! And Parin/Nimit for testing Eliane's work and finding the (I hope so) last bugs to fix before push it upstream!

    Next GUADEC is going to happen in Gothenburg, Sweden, the cradle of the Swedish Conspiracy and it will have at least a bit Carimbó! Maybe we will meet there again! :-)