On 04/12/2013 01:24 PM, Jan Pazdziora wrote: > Johannes, > > let me summarize some big picture impressions, without commenting on > every detail. > > You propose to address two situations: > > 1) clients in DMZ that cannot reach the server, with server able to > reach the clients; > > 2) overloading Spacewalk when multiple actions get (auto)scheduled for > many clients and they get woken up by osa-dispatcher/jabberd/osad > all at the same time. > > Frankly, the first scenario does not sound that interesting to me. > Access to and from DMZ is typically closed from/to all other networks > as well and only opened in a very targeted fashion. The IT of that > organization would still need to allow access _to_ the DMZ to sshd > ports on those machines. You can always have Spacewalk Proxy in > DMZ2, having client talk to the proxy and that proxy to the Spacewalk, > if your IT does not want to open the ports in the DMZ configuration > directly. In both cases, the HTTP requests run by rhn_check / yum will > end up on that Spacewalk server and if there is a way to compromise > that server that way, it will happen. I would still need to check the > patches in details to see how you solve the problem of the client IP > addresses as seen by the Spacewalk server being 127.0.0.1 for all > those requests which is hardly something you'd like to see in > production. > > You propose new scheduling service in taskomatic to initiate the SSH > Push for client ... but we already have such a functionality, it's > osa-dispatcher. So either we should get rid of osa-dispatcher and do > even the jabber/osad based notifications from taskomatic, or we should > stick with osa-dispatcher and not create very similar solution in > Java.
I agree that duplicating such functionality is not a very good thing to do and that it would make more sense to do jabber as well as ssh based push notifications from within the same component of the software. On the other hand I wonder why osa-dispatcher has been written in Python in the first place? If there is something like taskomatic, shouldn't we put such functionality in there rather than having yet another separate component? > The second scenario is however much more important and interesting > -- yes, the server will get overloaded if you use many osad-enabled > clients, and we had Spacewalk users complaining about this on the > mailing list in the past. However, is the cure really to allow ssh > access from server to the clients? How about clients that are behind > NAT, roaming, or in general unavailable? I am not saying that SSH Push should be the cure for anything. Rather I would consider it as just another contact method that can optionally be used if it is suitable to anybody's needs. OSAD should IMO stay alive and be available as a valid alternative. It should be the customer's choice. The cure for the client complaints should rather be to make the existing software more robust and stable in the first place, i.e. mitigating issues with scalability. Taskomatic even offers some generic classes that can be used to do threading and queuing (TaskQueue, QueueDriver and QueueWorker), so isn't it actually a real option to port that osa-dispatcher functionality over there? > I would assume that the majority of the Spacewalk (and downstream > products') installations has server accessible from clients because > otherwise things would currently not work. If you completely reverse > the style of operation, it will cause the disruption in our users' > setups. And still, clients for which you won't be able or willing > to enable the SSH Push functionality will not get the improvement > in timely actions that don't put the server to its knees. I don't think this would cause any disruptions. Actually it would even enable users to administrate systems using Spacewalk where it was not possible before. This means more users might even be attracted and also existing users might use Spacewalk to maintain more systems than before. You can even use ssh push to manage systems located in some public cloud overseas, as long as you can login using ssh from the server. > I would very much love to see improvements to the second problem which > could be used by all *existing* clients of Spacewalk, even those that > are behind NAT, independed from the SSH Push feature. > > Can the logic you propose to be put to taskomatic be put to > osa-dispatcher, to throttle the number of clients which get "invited" > to rhn_check? Well, it's currently implemented in Java of course, and the first layer of throttling is only queuing and threading, as mentioned before: There is a (configurable) number of threads which specifies the number of concurrent ssh connections allowed at a time. If there is actions to be performed on more clients, the oldest ones in the schedule are treated first, while the rest will be queued and revisited as soon as there is free threads available. This was all done using existing classes from the taskomatic framework. The logic that was implemented to call back to the clients before the "System not checking in" timeout is reached could be ported to Python of course. There is currently no plans for it though. Basically it's a randomized algorithm which periodically looks for systems we have to call back to. The closer we get to reaching the timeout for a certain system, the more probable it is that this system will actually be contacted in the current iteration. > Can we move the osad functionality (which we use purely for > notification) to rhnsd and maybe have rhnsd keep connection open > (WebSockets, maybe?) so that the server can wake the clients up in > timely (yet well managed) fashion? I guess we could, even though I am unsure if we really would want to keep connections open. Doesn't sound like a very good idea to me, since it probably won't really scale to any large number of managed systems. Would this still require the client to connect to the server or do you think of this as an alternative to ssh push, in terms of all communication is initiated by the server? Regards, Johannes -- SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
