[Spacewalk-devel] Proper Twitter Bootstrap class
Hi! There is a little fix for this commit, which keeps the full form layout on smaller screens: https://git.fedorahosted.org/cgit/spacewalk.git/commit/?id=b7f023ff07b9944f9c34022a98768cafb317df70 -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer >From 77111445906383936df236ccb07b84f8c2bfd757 Mon Sep 17 00:00:00 2001 From: Bo Maryniuk Date: Fri, 14 Feb 2014 15:36:00 +0100 Subject: [PATCH] Proper TB3 column class --- .../common/fragments/datepicker-with-label.jsp |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/java/code/webapp/WEB-INF/pages/common/fragments/datepicker-with-label.jsp b/java/code/webapp/WEB-INF/pages/common/fragments/datepicker-with-label.jsp index fb95126..f339350 100644 --- a/java/code/webapp/WEB-INF/pages/common/fragments/datepicker-with-label.jsp +++ b/java/code/webapp/WEB-INF/pages/common/fragments/datepicker-with-label.jsp @@ -1,7 +1,7 @@ <%@ taglib uri="http://struts.apache.org/tags-bean"; prefix="bean" %> - - + + -- 1.7.1 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] UI: Errata pages ASAP removal missing patches
On Mon, Feb 10, 2014 at 12:25:43PM -0500, Matej Kollar wrote: > Thanks for contribution :-). YW. :) -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer The best things in life are free *plus shipping and handling* ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] UI: Errata pages ASAP removal missing patches
On Mon, Feb 10, 2014 at 07:49:48AM -0500, Matej Kollar wrote: > Nevertheless I have a note for mentioned #0009: If > you really insist on reformatting .jsp-s, please > * do it in separate step to make review simpler, > * do not introduce trailing white-spaces, > * make consistent use of space before slash in void tags, > * make indentation of pairs of opening and closing tags match. This sounds like need of a pretty precise checkstyle. Well, fixed. -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer He can compress the most words into the smallest idea of any man I know. datepicker-ui-unification-errata-pages.tar.bz2 Description: application/bzip-compressed-tar ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] UI: Errata pages ASAP removal missing patches
Hi, errata fix (again), must be applicable this time. -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer No matter where you go in the world, there never seems to be a shortage of idiots. 0001-Datepicker-UI-unification-Errata-pages.patch.bz2 Description: application/bzip ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] UI: Errata pages ASAP removal missing patches
Hi! I am attaching patches for errata pages, where "ASAP radio button" is removed according to the rest of the pages. The number of the patch you are interested is #0009. -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer If a stranger offers you a piece of candy, take two. datepicker-ui-unification.bz2 Description: application/bzip ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Action Chain XML-RPC API
On Tue, Feb 04, 2014 at 02:03:18PM +0100, Michael Mraka wrote: > NEVRA+channel name is still more complicated than simple id. But your script does not know about the ID. It will know after fetching available packages. Then you should be adding some logic to your script in order to find out what exactly ID you need to use. And only then you use this ID. But that is like remembering ICQ account numbers or IP addresses, instead of having Jabber's e-mail or DNS. When you are are an admin, you *already* know nevra and channel. > Moreover it's volatile (someone can remove package from the channel) while > id is immutable. If somebody removed the package from the channel and still is trying to install it, then it is a process issue, and probably in THIS case it is actually is a bad idea to install the package, since somebody removed it on purpose. Actually, thanks for the nice tip: in order to keep the package in the DB but prevent it automatically installed by peripheral scripts on particular channel, simply remove the package from the channel! :) -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Assassins Inc. We aim to please. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Action Chain XML-RPC API
Hi, Milan. Thanks for the clarifications! More below. On Tue, Feb 04, 2014 at 01:33:01PM +0100, Milan Zázrivec wrote: > Say you have several "myfantasticserver" systems (i.e. the same profile > name / hostname / ip address) and add a package installation action > to an existing action chain. Which of those many "myfantasticserver" systems > will this action be scheduled for? All of them? First one? Last one? Random > picks? There's no reliable way to decide, is it? Yes, I hear you. Although I am wondering is it really important here, as long as the package finds its end point server and installs desired package? In any case this is the *same* server, right? Maybe I am missing something here, but the task is to install package from specific channel on specific machine, as long as the package *in general* is available to the machine, regardless profile. Can we actually have in the database the same servers with the same IPs but different physical boxes? Even so, MAC address can resolve this (the MAC you know right away). I am more talking about the case, where you have nice access to the host info (RPM db, ifconfig data etc) and want to "toss up" a little short almost-oneliner script that would do something, generally do as few as possible network calls. Of course, a complex dedicated software (like our Android app for the SUSE Manager/Spacewalk) does it differently. > Sure, these packages would have different checksums. But that's not the > point. Right. But they are in the different channels. So if you can specify the channel name, shouldn't it prevent the clash? But that's also pretty extreme, because if you have 100 VMs somewhere in the cloud, the management is pretty straight-forward, as they are "raw images" that you manage in pretty simple way. These parameters for package clarification can be simply optional and can be omitted, in case you have that simpler layout. > I wouldn't say it's bad. That admin script would simply use one api call to > get the package ids and we'd let the author of the script / the person > executing the script make the decision on which of those packages ids > are supposed to be installed / removed, etc. This is flexible, I agree. Still I see here that the script needs to have filtering logic, in order to find the required ID. Right now the UI gives you a system with listed packages, ready to get installed. In that list, you can get clashes? > > Leaving the "by ID" still available, isn't it better to have a convenience > > layer by name? > > I'm all for making things easier to use. But not at the costs of making > the behavior ambiguous. That's exactly what I would like to avoid. :-) -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer The number one problem in our country is apathy, but who cares! ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Action Chain XML-RPC API
On Tue, Feb 04, 2014 at 01:22:40PM +0100, Michael Mraka wrote: > That's correct. But then you have to use NEVRA+checksum which is more > complicated than simple id. Do you actually need the checksum, as long as you know the channel name? -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer I was wondering why frisbees got bigger as they got closer then it hit me. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Action Chain XML-RPC API
On Tue, Feb 04, 2014 at 11:54:13AM +0100, Milan Zázrivec wrote:
> Using "myfantasticserver" and {"name" : "alsa-lib", "version" : "1.0.22",} to
> identify server and package? Please no.
How do you remove an orphan package that is not on the channels from the
particular machine? The UI allows to do that, but the package is identified by
NEVRA (well, by a combo, which it is).
Having this API already working, logically you would like to extend that
elsewhere, even if it is an additional API.
> It's not uncommon to have the same machine registered with Spacewalk multiple
> times and use the same profile name / hostname / IP address for all these
> registrations. "myfantasticserver" simply won't be enough to uniquely identify
> the desired server -- only server id will be.
>
> Similarly, it's perfectly OK to have two packages with the same NEVRA pushed
> into one organization (for example RHEL + CentOS). In these situations, your
> concept would not be able to realiably identify desired packages -- only
> package id would be.
But I would expect two packages would either have different checksum and/or in
different channels?
> While I understand that the thought of operating with human-compatible data
> seems appealing, I'm afraid it won't work with API, where we need to model
> functions in an orthogonal manner -- i.e. one function will give you system
> id(s), another one will give you package id(s) and a third one will take these
> two ids and instruct a specific chain to remove packages from a specific
> system.
This are three calls. Fine with the software, like we've built for Android
for example, but quite bad if this is your admin script.
Leaving the "by ID" still available, isn't it better to have a convenience
layer by name?
--
Bo Maryniuk
SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
A positive attitude may not solve all your problems,
but it will annoy enough people to make it worth the effort.
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Action Chain XML-RPC API
Hello everyone.
We are developing here Action Chain feature, where you can add some actions
(install/remove/verify/etc package or other things) to the Chain, making sort
of one-shot batch. These actions won't be executed, until you execute the
entire chain.
We are also developing the XML-RPC API for it and they are already working in
our branch. :)
Here how do they look like. For example, in Python you could call:
client = xmlrpc
sid = client.login
# To list them
for chain in client.actionchains.listChains():
print chain.get("name")
# Add some package removal.
# Note: the IP is optional, IPv6 accepted too
client.actionchains.addPackageRemoval(sid,
"myfantasticserver", "12.34.56.78",
[{"name" : "alsa-lib", "version" : "1.0.22",},
{"name" : "some-name", "version" : "1.2.3.4",},],
"My Chain")
# Remove actions from some chain:
client.actionchains.removeActions("My Chain", ["Package Install", "Reboot"])
# Remove the whole chain
client.actionchains.removeChains(["My Chain"])
You may ask: Why no 101 for system instead? Why no 23445323 instead
for a package? It is simple: you, as an admin in the datacenter, you have an
RPM database, and you can --queryformat it and AWK it the way that your
XML-RPC Python script will understand it right away.
Adding IDs is possible too, but mainly we looked to operate the packages and
systems at human-compatible way.
What you think?
--
Bo Maryniuk
SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
I find television very educating. Every time somebody turns on the set, I go
into the other room and read a book.
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Action scheduling on ported pages
On Tue, Jan 28, 2014 at 06:57:25AM -0500, Jan Dobes wrote: > Nevermind, you don't have to fix it. I already corrected your patch and > pushed it to master. Thanks. :) -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer His entire job career were upgraded by the company to a shell script. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Action scheduling on ported pages
Hi, Michael.
On Wed, Jan 22, 2014 at 04:01:23PM +0100, Michael Mraka wrote:
> - SSM/Configuration/Enable: The message 'You may schedule rhncfg* package...'
> should stay above the date picker as it was originally.
Done.
> - The original text before the date picker ('You may schedule the package
> installations to take place as soon as possible, or no sooner than a
> specified time') suggests that the action might not take place immediately
> while with new wording 'Schedule at' users would expect the action is going
> to happen right after confirmation. I'd prefer something with
> similar meaning to the original.
Done. Since we removed "as soon as possible" checkbox, the same fashion we did
to the label: "Schedule no sooner than a specified time". :)
Take care.
--
Bo Maryniuk
SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
I am not young enough to know everything.
asap-removal-patches.tar.bz2
Description: application/bzip-compressed-tar
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH]es ISE fix and UI unification, phase 1
On Wed, Jan 22, 2014 at 04:32:13PM +0100, Michael Mraka wrote: > Hello Bo, > > I've commited cobbler issue fix. Thanks! > As for UI unification I've already > reviewed it and answered in the previous email. Thanks! I will take care of it ASAP. -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer A man is as young as the woman he feels. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] [PATCH]es ISE fix and UI unification, phase 1
Hi! While doing UI unification (attached here one more time again, since I didn't see it went to the mailing list archives for some odd reasons), I also accidentally step on the ISE, which happens if Cobbler is not installed (at least properly). Here are those two patches, please review. :) -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Should vegetarians eat animal crackers? 0001-Bugfix-ISE-when-cobbler-components-are-missing-not-i.patch.bz2 Description: application/bzip remove-asap-checkbox.patch.bz2 Description: application/bzip ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Action scheduling on ported pages
On Wed, Jan 08, 2014 at 01:12:06PM +0100, Michael Mraka wrote: > % > Could be. But it doesn't answer my questions. I'm asking for timeframe > % > because this is one of the blockers for Spacewalk 2.1 release and we > % > have to decide whether wait for it or not. > % > % OK, that sounds reasonable. Then I will make some more patches that will > % synchronize the rest of the pages with the current Date picker. Then we will > % introduce the new Date picker (as a tag, so it will instantly replace > % everything). Fair enough? > > Yes, that will solve it. Michael, what is the status here reviewing it, please? -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Honesty is the best policy -- when there is money in it. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Action scheduling on ported pages
On Wed, Jan 08, 2014 at 01:12:06PM +0100, Michael Mraka wrote: > % > Could be. But it doesn't answer my questions. I'm asking for timeframe > % > because this is one of the blockers for Spacewalk 2.1 release and we > % > have to decide whether wait for it or not. > % > % OK, that sounds reasonable. Then I will make some more patches that will > % synchronize the rest of the pages with the current Date picker. Then we will > % introduce the new Date picker (as a tag, so it will instantly replace > % everything). Fair enough? > > Yes, that will solve it. Hi, here is a first patch that synchronizes the rest of the pages with the current Date picker. While doing that, I found few forms are shredded and displayed wrong, so the patch fixing that will come from the side of Twitter Bootstrap saga. Thanks! -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer You have delighted us long enough. remove-asap-checkbox.patch.bz2 Description: application/bzip ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Action scheduling on ported pages
On Wed, Jan 08, 2014 at 09:07:31AM +0100, Michael Mraka wrote: > As you wrote previously you postponed finishing the changes. > Are you working on it again or not? If yes go ahead, if not please make > it compatible with other pages. Ah, OK. Probably my strange expressions misled you. Yes, we do want same pages everywhere, of course. > Could be. But it doesn't answer my questions. I'm asking for timeframe > because this is one of the blockers for Spacewalk 2.1 release and we > have to decide whether wait for it or not. OK, that sounds reasonable. Then I will make some more patches that will synchronize the rest of the pages with the current Date picker. Then we will introduce the new Date picker (as a tag, so it will instantly replace everything). Fair enough? -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer If you can smile when things go wrong, you have someone in mind to blame. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Action scheduling on ported pages
Hi, Michael, I am back. :) On Tue, Jan 07, 2014 at 11:43:18AM +0100, Michael Mraka wrote: > Yes, it's possible to simplify date picker on other pages Of course. This is what we all want, ultimately: a simplicity and better UI. > but until it's done > (consistently across all the pages) you should keep the old style. Then why to make the efforts tripple times? Let's sync it with the rest of the pages instead? You already agreed that the current way is not simple and, in fact, duplicates the functionality. There should be always only one date input, set to now by default. How you can possibly get confused with this? Otherwise it is the same as you would say "It is possible to port Perl to Java, but until it is done, let's continue invest in Perl code". :-/ > This is also possible and again until it's done you should keep > consistency with old pages. Please see above. This is why you call them "old". :) > % The feature was a bit postponed since we had first to get TB3 working. :-) > Now > % it is there, so new UI is coming, of course. > % > % > Could please take a look and update the pages so they follow original > % > workflow? > > By 'the feature' you mean new date picker or pop-up confirmation stuff? > Do you have a timeframe for their implementation? Of course. And we already did that here, BTW. Looks super-awesome and you will *love* it. :) And this is also why we kept the old way JSPs in "under-done" state in previous code only because we yet had no Twitter Bootstrap there. Adding 3rd party JavaScript libraries would be also a big mistake. The "old things" are anyway will die. And this is also why we had started Twitter Bootstrap in general: to have simpler, better, more responsive UI, yet standardized. So again, I honestly see no reasons to continue the old way duplicating the efforts, especially if we already have modern way. -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer I'm smiling. This should scare you. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Action scheduling on ported pages
On Thu, Dec 19, 2013 at 11:15:13AM +0100, Michael Mraka wrote: > First of them: the original schedule date picker on contains two choices > - Schedule action as soon as possible > - Schedule action for no sooner than: > while new contains only > - Schedule action for no sooner than Because it is the same thing: "as soon as possible" is basically now, which is already defined in the date picker. There is no need to duplicate the same thing twice. > Although we may discuss which one is better and whether it's worth of > changing it, for now I'd primarily prefer to keep it consistent across > all the pages. Actually, we were discussing to removing the option "as soon as possible" from other pages to keep it consistent. :-) > The second and IMHO major issue is - the original page (and all other pages) > implement "two phase" confirmation. The confirmation won't be any longer a bulky separate JSP page with all the hassle involved, but a little neat Twitter Bootstrap-based modal pop-up instead. The feature was a bit postponed since we had first to get TB3 working. :-) Now it is there, so new UI is coming, of course. > Could please take a look and update the pages so they follow original > workflow? Yes, sure. However, right now I am on vacations and will look at it next year. :) Happy New Year and Merry Christmas! -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer A conclusion is the place where you got tired of thinking. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Using fonts in /rhn/account/LocalePreferences.do
On Thu, Nov 28, 2013 at 02:55:59PM +0100, Michael Mraka wrote: > Is that 10KB of images really that ugly / big problem that we need to > replace them with 14MB ttf font? I don't think so. I am wondering what is the problem of once downloading 14MB in a datacenter, usually local network? It looks big vs gifs, but the benefit is incomparable. -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Love your enemies.. it makes them mad. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Problem building dev workstation
On Mon, Nov 11, 2013 at 07:09:35PM +0800, Colin Coe wrote: > Hi Bo > > Just looking at this now. I have a pre-built, working spacewalk > environment and I want to turn it into a dev environment. Does the > script cater for this? What options are applicable? Well, it does as described: 1. It puts the Spacewalk into a bare minimal JeOS, adds required stuff and sets up your dev env with an ability to deploy to a remote host (it does not uses symlinking, but rsync). 2. Then you should git-clone the repository and run "bsp -r" within the "$SPACEWALK_SOURCES/java" directory (see "--generate-config"), and it will try to assemble the whole thing from the current sources and will deploy over. You could try skipping step #1. P.S. But I am not sure if the step #1 is still working (last time it seems to be OK was around two months ago). Give it a try: after all, your VM shoud be able to make snapshots... :-) -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer You have delighted us long enough. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Problem building dev workstation
On Mon, Nov 11, 2013 at 05:43:32PM +0800, Colin Coe wrote: > I ended up rebuilding the VM and starting again. I had missed a step or two. My few cents: I wrote a little workaroung thing that could probably help you (if nothing was broken in between last commit and today): https://github.com/isbm/spacewalk-power-toys But I am using CentOS for it, not sure how it will fly on Fedora. HTH. -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Support mental health or I'll kill you! ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Merging the bootstrap-css branch
On Wed, Nov 06, 2013 at 11:15:31AM +0100, Duncan Mac-Vicar P. wrote: > About the pxt, we will put the port in another sprint in a month for > now, and we will have minimum 3 developers working on it for those two > weeks. We can tackle the perl List widget there. I would like to add that porting from Perl is sort of another topic and contributing should go *after* the Bootstrap merge, as the new JSPs should follow the Bootstrap paradigm. -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer I didn't like the play, but then I saw it under adverse conditions - the curtain was up. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Merging the bootstrap-css branch
On Tue, Nov 05, 2013 at 05:07:02PM -0500, Grant Gainey wrote: > While there's clearly work to do, everyone is on-board with merging as long > as things *work*, even if they're still ugly. The problem with checkstyle is > that it fails all our automated testing, so we wouldn't even get to junit > issues. That is what we could fix. > We'd also like to discuss plans for dealing with the remaining PXT pages. > Getting them all converted wouldn't hold up a merge - but discussing and > creating a plan for a final conversion, and who would do which pieces of it, > would be important. At least I am on it. I've already ported a bunch of stuff from Perl and I am simply going to continue it, so eventually all Perl pages will go away. In general yes, we have a plan. > Honestly, if we could get the checkstyle fixes and a first pass at The PXT > Problem, I think we'd be good to go. You got it. -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer I never admit or deny anything it makes me more interesting. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Single system "Remote Command" Perl page port to JSP patch
Hi! I've just ported Remote Command for the single system: Systems//Details/Remote Command It looks and behaves identical to SSM/Provisioning/Remote Command, exept it does not performs batches for many systems. Have fun! :) -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Marry me and I'll never look at another horse! 0001-Perl-to-JSP-port-Single-system-Remote-Command.patch.bz2 Description: application/bzip ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] SSM: "Errata" Perl page port to JSP patch
Hi! I've just ported Errata from SSM from Perl to JSP. Everything seems legit... :) Have fun! -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Marriage is the chief cause of divorce. 0001-Perl-to-JSP-port-SSM-Errata.patch.bz2 Description: application/bzip ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] SSM: "Misc/Reboot" Perl page port to JSP patch
On Wed, Aug 21, 2013 at 01:31:24PM +0200, Tomáš Kašpárek wrote: > Your patch has been committed into spacewalk as > ea8e7b8e2af1ab8aa49eeb6b58bc29ca3bf50ea1 > Thanks for contribution! Tomas, as promised, here is an additional patch to this, which optimizes listview and action. Have fun! -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Earth is the insane asylum for the universe. 0001-SSM-Misc-Reboot-Standard-system-list-optimized-actio.patch.bz2 Description: application/bzip ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] SSM: "Misc/Reboot" Perl page port to JSP patch
On Tue, Aug 20, 2013 at 06:10:09PM +0200, Bo Maryniuk wrote: > Hi! > > New "Perl to JSP" port: SSM/Misc/Reboot > > Highlights: > 1. Optimized scheduling form: reduntant "Now" and >"Now or change the date" removed. From now, date is set to "now". To >schedule it later, simply change that. > > 2. Misc Index optimized: removed redundant links and moved to the >submenu. There is left only "Custom System Information" which are still > Perl >pages (soon to be removed as well). > > 3. Selection is cleared after the scheduling. > 4. *ahem...* Checkstyle and unused imports. -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Deep down I'm a very shallow person. 0001-Perl-to-JSP-port-SSM-Misc-Reboot.patch.bz2 Description: application/bzip ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] SSM: "Misc/Reboot" Perl page port to JSP patch
Hi! New "Perl to JSP" port: SSM/Misc/Reboot Highlights: 1. Optimized scheduling form: reduntant "Now" and "Now or change the date" removed. From now, date is set to "now". To schedule it later, simply change that. 2. Misc Index optimized: removed redundant links and moved to the submenu. There is left only "Custom System Information" which are still Perl pages (soon to be removed as well). 3. Selection is cleared after the scheduling. Have fun! :) -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer I am not young enough to know everything. 0001-Perl-to-JSP-port-SSM-Misc-Reboot.patch.bz2 Description: application/bzip ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] SSM: "Remote Command" Perl page port to JSP patch
On Fri, Aug 16, 2013 at 10:30:02AM +0200, Tomáš Kašpárek wrote: > That "one more time confirmation" is used to display on which > systems the remote commands will actually run. Fixed the following way: if system does not have entitlement "provisioning" and capability "script.run", then it is not in the list. If there are no systems available, you will get only text that there must be first some systems to run remote command on and no form, no list, nothing. I've also added little additional features: 1. Premature script checking helper. Just to make sure the script is not just a set of comments and has #!/... declaration. 2. Form now remembers field values, if there is some failure filling it in. -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer It's a catastrophic success. 0001-Perl-to-JSP-port-SSM-Provisioning-RemoteCommand.patch.bz2 Description: application/bzip ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] SSM: "Remote Command" Perl page port to JSP patch
On Fri, Aug 16, 2013 at 10:30:02AM +0200, Tomáš Kašpárek wrote: > >1. Removed "one more time confirmation". Page schedules script instantly. > > That "one more time confirmation" is used to display on which > systems the remote commands will actually run. Yes, affected systems. I think, I have something to improve here. :) > See my comment above. Or another option is to allow systems without > script.run capabilities to stay in SSM and list there only the with > the right capabilities. Right now all systems in SSM are showed even > the one without capabilities. > In my opinion it would be nice to show there only the ones with > right capabilities and run remote commands on them so it does not > end in state when I want to access remote command after unsuccessful > try which leads to me remove and put systems without capabilities > into SSM. Yes. And if none appeared, even not show the whole form, but tell the user than the no systems in the set can run remote command. Thanks for the point. I will look at this now. -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Should vegetarians eat animal crackers? ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] SSM: "Remote Command" Perl page port to JSP patch
On Fri, Aug 16, 2013 at 08:46:50AM +0300, Ville Salmela wrote: > could you raise the timeout to 3600? One hour that is. > > I have hit the 600 sec timeout limit too many times... too short timeout > breaks the systems when running scripts and fixing the half run scripts > afterwards is a pain... While 600 seconds might be a problem on rare systems, still it is default value in RedHat Satellite and Spacewalk for years, hence I simply moved it as is. But now changing this *default* value is a direct affection of scheduling result, and therefore is a subject to discuss with the community first. :-) -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Patrick: I'm mad. Spongebob: Why's that? Patrick: I can't see my forehead. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] SSM: "Remote Command" Perl page port to JSP patch
Hi! I am happy to introduce you another Perl page port to JSP: "Remote Command" in System Set Manager section. Differences from the Perl version: 1. Removed "one more time confirmation". Page schedules script instantly. 2. Additional optional field "Command label" to put custom name for the label. 3. List of the affected systems are listed right below. 4. Removed icon in the date picker, so now it looks much cleaner. 5. Pure Java. :-) This page will join the club to be finalized with SUSE effort bringing Twitter Bootstrap to the Spacewalk. All the confirmations will be based on this framework, therefore there is no need to add an additional confirmations with extra code/xml/config/redirects/checks etc, which anyway will be removed anytime soon. The list of the affected systems will be nicely collapsable, once Twitter Bootstrap is there, but right now there is no point to put yet another widget library to do so. Have fun! :-) -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer I find television very educating. Every time somebody turns on the set, I go into the other room and read a book... 0001-StringUtil.nullIfEmpty-now-ignoring-the-whitespace-a.patch.bz2 Description: application/bzip 0002-Perl-to-JSP-port-SSM-Provisioning-RemoteCommand.patch.bz2 Description: application/bzip ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [Spacewalk-list] SSM: Lock and Unlock Perl page port to JSP patch
On Thu, Aug 15, 2013 at 11:32:11AM +0200, Tomáš Kašpárek wrote: > I've also removed old Perl code in these two patches: > https://git.fedorahosted.org/cgit/spacewalk.git/commit/?id=89dbf1c2dd5947253bb0af3433f7154f2b5185ae > https://git.fedorahosted.org/cgit/spacewalk.git/commit/?id=174c125778fdc1ee9fec5a9dc33c89b251d2a104 > > Hopefully I have not removed something that is still in use. Well, that's exactly the reason why I did not touched it. I suggest to leave it all as is for now, then kill the entire Perl code, once it is entirely disabled from all over the place, as it is a principal change. My furher patches for Perl pages porting will be without old code removals. -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer This place is so weird that the cockroaches have moved next door. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [Spacewalk-list] SSM: Lock and Unlock Perl page port to JSP patch
On Thu, Aug 15, 2013 at 10:58:16AM +0200, Tomáš Kašpárek wrote: > I've fixed one issue when unlocked systems had the same icon, > independent on whether they're physical, virtual host or virtual > guest, also system icons had title "Security errata" so I removed > that. > Also the page had errata pages legend so I've fixed it to use system > pages legend. > My changes are available here: > https://git.fedorahosted.org/cgit/spacewalk.git/commit/?id=ade66291ed0d971ca22d0165624520487daa791f Ah, many thanks, I will note that. Thanks for collaboration! -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer A paper should be like a mini skirt: long enough to cover everything, but short enough to keep it interesting. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [Spacewalk-list] SSM: Lock and Unlock Perl page port to JSP patch
On Wed, Aug 14, 2013 at 01:16:59PM +0200, Tomáš Kašpárek wrote: > In this case I would at least except all of the checkboxes to be > checked by default with option to unselect systems you don't want to > have there. When I am working with SSM I am expecting that I am not > forced to do any more selections. OK, I removed clearing the selection. Since the page is bi-directional, the whole selection will just stay that way in the set and next time you're back, you can un-lock your systems again or change the selection. > Also it looks like you're not subscribed to spacewalk-devel mailing > list as I can't see copy of your mail there ;-) Hmm, I am. At least http://www.redhat.com/mailman/options/spacewalk-devel tells me so. -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer People are seldom too busy to stop and tell you how busy they are. 0002-Ported-from-Perl-to-JPS-locking-and-unlocking-page-c.patch.bz2 Description: application/bzip ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [Spacewalk-list] SSM: Lock and Unlock Perl page port to JSP patch
Hi, Tomáš! On Tue, Aug 13, 2013 at 11:31:34AM +0200, Tomáš Kašpárek wrote: > Selecting systems to lock or unlock as a subset of SSM looks bit > weird. The purpose of SSM is that once you've selected a set of > systems you work with them with them as with a batch. Take a look at > other pages of SSM as there are no more selections and you work with > the whole set. True. However there is still a niche for this. For example, you have a set of some specific machines that runs one type of software and you want to run some batch on them, except few. > >Here is a patch, which does the following: > >1. Now it is only one page where you can lock and unlock systems. > I've found a bug there, when you try to lock a locked system you > will actually unlock them. I would expect them to stay locked. Fixed. > Nice change, however I would like to have the reason field not mandatory. Fixed. > Also bashing enter in the reason field causes the page to reset. Fixed. For now I've just disabled the Enter key for the field, as it is very unclear what to do and how exactly. Let our users continue use mouse at this moment. :) With the Twitter Bootstrap (TB) we will surely go back to here and offer something better. I also don't want to add much other code, which might go away, after we move everything to the TB. So I hope, for now our users will perfectly live with by bashing enter key, seeing nothing happens, and thus clicking mouse where required. > >3. Brings back the sub-menu of the Misc. > I like this :-) Not included in this patch though, but I've also replaced the whole Misc indes page with something much more simpler, leaving only bottom form and not-yet-ported "Custom System Information" Perl pages (to simply kick them away from the menu on top entirely) and putting all the rest stuff to the submenu. This way it looks much better. With our effort migrating everything to Twitter Bootstrap, I will soon port "Custom System Information" as well, so they will also go away from the index page and appear in the sub menu. > Also a note the line "* Copyright (c) 2013 SUSE" breaks our > checkstyle. Now we have a rule that copyright must be "Red Hat, > Inc." || "Novell". > Also moving this conversation to spacewalk-devel which is better > place to discuss about development of Spacewalk and sending patches. Well, this is no longer true as we lately use "SUSE" in the copyrights. Therefore please apply patch #0002 for this. Take care! -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer I used to have a handle on life, but it broke. 0001-Ported-from-Perl-to-JPS-locking-and-unlocking-page-c.patch.bz2 Description: application/bzip 0002-Accept-SUSE-copyright.patch.bz2 Description: application/bzip ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason db_name value change in, /etc/rhn/rhn.conf?
On Fri, Sep 07, 2012 at 04:10:13PM +0200, Jan Pazdziora wrote: > On Fri, Sep 07, 2012 at 03:54:25PM +0200, Bo Maryniuk wrote: > > > > The /etc/rhn/rhn.conf has nothing to do with *Oracle* database > > at all. > Right, besides providing database type and connect information, which > for Oracle backend turns out to be ... Oracle connection > specification. :-P One more time: /etc/rhn/rhn.conf has nothing to do with *Oracle* vendor. It has everything to do with providing a *generic* information for database connectivity, which can be Oracle or PostgreSQL (as of today). The problem is that built tools around the Spacewalk now needs to be also changed to specifically parse the URI and also determine in "if/else" fashion is it URI or just a name, if some other fields left empty etc. Users, that are using PostgreSQL version now have to worry about Oracle-specific hardcoded ad-hocs and the documentation now needs to contain trash like "If you use Oracle, then and if PostgreSQL, then.". Instead of just work as before. So the question still remains: what was the REASON to change what is working rock-solid for years? And another sub-question: why it is not called "db_uri" (because it *is* URI)? -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer There are 10 types of people in the world: those who understand binary, and those who don't. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason db_name value change in, /etc/rhn/rhn.conf?
On Fri, Sep 07, 2012 at 02:46:34PM +0200, Jan Pazdziora wrote: > I'm not sure I correctly understand what you ask about but the > oracle_get_database_answers The /etc/rhn/rhn.conf has nothing to do with *Oracle* database at all. It is *generic* config and database back-end can be even IBM DB2 one day. The configuration keys in the rhn.conf belongs to the RHN configuration, not to the Oracle database! > just setup whatever you want in tnsnames.ora "tnsnames.ora" is a part of Oracle database. Again, /etc/rhn/rhn.conf has nothing to do with a particular database vendor. RHN configuration is a place, where *generic* information about *any* database connectivity is specified. A specific URI strings for specific drivers on specific database vendors must be handled inside the particular application. What if I am connecting my Windows Server .Net written app over ODBC to Postgres? -- I am constructing my own URI inside. And now I need specifically parse the URI? Why so?.. > Right. We just leave them empty. > [...] > We need to support them for PostgreSQL. I can spot here severe logical problem: "We just leave them empty" vs "We need them to support $FOO database". This only proves than /etc/rhn/rhn.conf file is *generic* place for *varius* and different components. That directly means that hard-coding specific URI over "db_name" variable that belongs to RHN configuration syntax is just a very bad idea. As a result, other components need to parse this URI, remove all the host:port information and extract only a database name. Why? The bottom line is that now these keys are not unified and can mean anything. I would understand if RHN config would do something like: db_host = foo.bar.com db_port = 5432 db_name = blahblah db_uri = //$db_host:$db_port/$db_name ...by acquiring the values. But even that, putting URI inside in only one particular syntax is more like hard-coded ad-hoc because somebody had a personal problem somewhere. In some cases it can be a different syntax, like: user/password@//host:port/database or: (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=host) (PORT=port)))(CONNECT_DATA=(SERVER=DEDICATED) (SERVICE_NAME=database)));User Id=user;Password=password; or: user/password@host/service:dedicated/database; or: //$host/$database?user=$user&password=$password&ssl=true etc. -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer We are experiencing system trouble -- do not adjust your terminal! ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Reason db_name value change in /etc/rhn/rhn.conf?
Hi! I am wondering what was the reason to make this very awkward change in 1.7 by using URI in "db_name" in the /etc/rhn/rhn.conf other than "because now our Java can connect different way"? My opinion on that: 1. This is called *db_name*. So let it be the *name*. 2. This is not called "db_uri" as it is right now for some reasons. 3. It duplicates values from "db_host" and "db_port", making them obsolete and/or irrelevant. 4. It adds mess and noise to the configuration: if we already have the URI, why the heck we still have host and port defined? 5. If your particular place in your particular software supposed to use URI instead of plain name, then why not construct it there, instead of parse-and-reconstruct anyway, because if other code don't need to use this notation? 6. It is still not called "db_uri". Because "host:port//name" is not a *name* but resource location! So the semantics are wrong anyway now. The bottom line is that if this particular syntax needs to be there, then better add one more parameter "db_uri". IOW: http://goo.gl/e8l8v I would vote to change it back as it was in 1.2 version. -- Bo ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Dobby replaced
Hello, astronauts! :) We kind of replaced Dobby (db-control) with something else, that also answers previously asked question: "How do we hide oracle id without sudo'ing to it?" Well, here is a new tool, called SMDBA and the source code is right here: https://github.com/SUSE/smdba It supports Oracle and PostgreSQL transparently (set of commands differs though), does not need any configuration like Dobby needs, detects what DB is around automatically and with our SUSE Manager works right after the installation. It is written in Python as a wrapper for SQL*Plus, RMAN, psql and other tools, it needs no DBI drivers and has no particular dependencies other than sudo package, since the whole access is controlled there. Some differences from Dobby: - It is intentionally *incompatible* with Dobby. - "extend" command has been dropped. - backups are now performed on hot database running. - supports Oracle and PostgreSQL. - MIT license. Near future going to bring the following new features: - Full automated control on audit trail logs and translation logs. - Fully automated disk space monitoring with output to external UI. - Complete integration through API, so the tool itself supposed to get "dissolved" and never used anymore in the console directly. So take a look and tell what you think! :) -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer I'm not anti-social. I'm just not user friendly. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] spacewalk-dobby replacement
Hi! Here at SUSE we were working at Dobby replacement and we would like to know what could be missing from the things that we already achieved. We thought to make it exact Python clone and extend with PostgreSQL support, but then we realized that we can make it even better, deprecating cold backups and related things to that. Done: = 1. Works with Oracle DB and PostgreSQL. 2. No DBI drivers at all, no dependencies like that. It is just a wrapper for SQL*Plus, RMAN and psql utilities. 3. No configuration at all, except it reads main rhn.conf what DB is configured at the very moment. The rest it detects from Oracle DB-related or PostgreSQL-related files separately. 4. Automatically changes set of commands available. For example, it allows restart only listeners in Oracle, but no such feature for PostgreSQL. 5. Hot backups for Oracle and PostgreSQL. No longer need to stop entire system just to snapshot the db. 6. Never executes external processes with '...> /dev/null &;" printing "Done" no matter what, but actually waits for the actual result and tells you everything in details. 7. Oracle is put to autoextend mode, reporting free space. The "extend tablespace" feature is just dropped. 8. No need of "su - oracle" (or "su - postgres") any longer. :-) Just make sure your user has sudo rights. 9. Renamed to "mgr-db". This will also deprecate customer scripts for previous "db-control". Commands are incompatible. To do: == 1. (Critical) Automatically dealing with archivelog for Oracle DB, so it won't blow away the entire disk space. 2. (Later) Add XML output, so the utility might be also "crontabbed" and integrated into a Spacewalk directly, with no more CLI intervention. Code & Documentation: = Soon on our GitHub. Hopefully, next week. CLIshots: = Overview: $ sudo ./mgr-db SUSE Manager Database Control. Version 1.0 Copyright (c) by SUSE Linux Products GmbH Available commands on Postgresql database: backup-hot Perform host database backup. backup-status Show backup status. db-startStart the SUSE Manager Database. db-status Show database status. db-stop Stop the SUSE Manager Database. space-overview Show database space report. space-reclaim Free disk space from unused object in tables and indexes. space-tablesShow space report for each table. system-checkCommon backend healthcheck. Config check: $ sudo ./mgr-db system-check INFO: Database needs to be restarted. INFO: Wrote new client auth configuration. Backup as /var/lib/pgsql/data/pg_hba.2012-05-02-15-13-39.conf Stopping core...done Starting core...done Database is online System check finished Space Overview: $ sudo ./mgr-db space-overview Tablespace | Size (Mb) | Avail (Mb) | Use % +---++-- template1 | 6 | 91645 | 0.006 template0 | 6 | 91645 | 0.006 postgres| 5 | 91646 | 0.005 susemanager | 37| 91613 | 0.041 Backup options: $ sudo ./mgr-db backup-hot help SUSE Manager Database Control. Version 1.0 Copyright (c) by SUSE Linux Products GmbH Command: backup-hot Description: Perform host database backup. Parameters: --enableEnable or disable hot backups. Values: on | off | purge --destination Destination directory of the backup. Adding "help" to each command will print you what it is and what are other params available. P.S. Written in Python. -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer I had a dream... and there were 1's and 0's everywhere, and I think I saw a 2! ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] spacewalk-dobby
On Wed, Mar 21, 2012 at 02:27:34PM +0100, Jan Pazdziora wrote: > Excellent questions that I feel are calling for rigorous discussion. > What course of action do you envision in this area? We want to enhance it a lot. But we are not sure if this is a good idea to invest into current implementation, which is also in Perl that we would like to get rid of entirely. We also don't like it asks for *oracle* user. :-) -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer New linux package released. Please install on /dev/null ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] spacewalk-dobby
Hi! I was looking at Spacewalk Dobby wrapper around Oracle tools and I am wondering if there is any plans to work on it? We find it lack of some features that we would like to have, so we are looking to know what are community plans on this particular software. -- Bo Maryniuk 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
Re: [Spacewalk-devel] "1", "y", "true", "yes", "on" etc
On 09/12/2011 12:17 PM, Miroslav Suchý wrote: Well it is always good to understand more languages. And I know from my experience that people do not always know whether they should use true/yes/1 as different projects use different constants. Sure, because they don't know what is supported from the pile of any possible options. If they would know that there are only 1 and 0, they would get it instantly. So when I have time I try to write code which understood all possible constants. When I'm lazy I just choose one. And it results to a problem, because the config file is not just read by a Spacewalk, but also by a peripheral software and other scripts that does some additional stuff. So instead to write simple stuff, now everyone should support an array of who-knows-what options. I think this is not right. Besides, I would also argue about /etc/rhn/default/* existence that is *meant* to be edited according to FHS[1], while Spacewalk says "Do not do this". Actually entire rhn is in the wrong place inside the /etc directory, because it should be /etc/opt/rhn/... actually. :) Since our configuration files are well documented (hmm not documented, but has all option and its default values) I will not object agains #2, but I think #1 is better. OK, since you do not object against #2, I am going to provide the patch that basically standardizes the whole thing to just 1 or 0 and also saves your free time for something else. :-) ___ 1. http://www.pathname.com/fhs/pub/fhs-2.3.pdf ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Audit Log Keeper
Hi! Previously announced attempts to do the auditing in a Spacewalk are now physically real and already working for our SUSE Manager. Currently this is an initial implementation and will do have more options, like use AMQP delivery, will run on something better than just embedded Web Server and so on. You can see the source code of our approach for auditing here: https://github.com/SUSE/auditlog-keeper And you also can get the idea how to use that stuff here: http://wiki.novell.com/index.php/AuditLogKeeper Have a nice weekend. :) -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Beware of programmers that carry screwdrivers ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] "1", "y", "true", "yes", "on" etc
Anyone?...
--
Bo Maryniuk
SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
HRB 16746 (AG Nürnberg)
On 09/05/2011 04:08 PM, Bo Maryniuk wrote:
Guys,
should we support all of the list of "valid true's" for the config,
listed in /spacewalk/java/code/src/com/redhat/rhn/common/conf/Config.java,
or "1" is just enough for the next century?
/**
* List of values that are considered true, ignoring case.
*/
private static final String[] TRUE_VALUES = {"1", "y", "true", "yes",
"on"};
This is a bit not synchronized, since *only* Java stack allows such
odd choices, while the rest of the Spacewalk seems like "understands"
only "1" or "0" (Python part, at least).
I would suggest to put it to the common schema, because this is
very confusing.
So either:
1. Teach the rest of the Spacewalk to understand all of the above,
where seems like Esperanto and Swahili are still missing :-)
2. Reduce it to just "1" or "0".
What you think? I would go #2 personally...
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] "1", "y", "true", "yes", "on" etc
Guys,
should we support all of the list of "valid true's" for the config,
listed in /spacewalk/java/code/src/com/redhat/rhn/common/conf/Config.java,
or "1" is just enough for the next century?
/**
* List of values that are considered true, ignoring case.
*/
private static final String[] TRUE_VALUES = {"1", "y", "true",
"yes", "on"};
This is a bit not synchronized, since *only* Java stack allows such
odd choices, while the rest of the Spacewalk seems like "understands"
only "1" or "0" (Python part, at least).
I would suggest to put it to the common schema, because this is
very confusing.
So either:
1. Teach the rest of the Spacewalk to understand all of the above,
where seems like Esperanto and Swahili are still missing :-)
2. Reduce it to just "1" or "0".
What you think? I would go #2 personally...
--
Bo Maryniuk
SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
HRB 16746 (AG Nürnberg)
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] - 672652 Kickstart "Kernel Options" and "Post Kernel Options" reject valid options
On 08/31/2011 09:21 PM, Tomas Lestach wrote:
Hey Marcelo,
I checked your patch and here're my comments:
* I do not really understand following change:
- if (StringUtils.isEmpty(kernelOpts)) {
+ if (kernelOpts == null || kernelOpts.equals("")) {
According to
http://commons.apache.org/lang/api-2.5/org/apache/commons/lang/StringUtils.html#isEmpty(java.lang.String)
both lines shall do exactly the same job. I'd like to use again the
StringUtils methods.
* When I started to work on Spacewalk, I was told not to use
'instanceof', there's always a better way, how to write the code :-)
+ } else if(map.get(key) instanceof List){
why do you actually use it? Do you expect anything else than a List?
* third line looks redundant here:
+ List list = (List)toRet.get(split[0]);
+ list.add(split[1]);
+ toRet.put(split[0], list);
Also my 3 cents to the conversation:
-for (Object key : map.keySet()) {
-if (StringUtils.isEmpty((String)map.get(key))) {
+for (String key : map.keySet()) {
+if (map.get(key) == null) {
string.append(key + " ");
-}
1. This won't handle an empty String as a value of the map anymore
(i.e. not null) as before. I would suggest to revert the code back
to use StringUtils instead, which checks both.
2. If you use StringBuffer, normally you want to use chains instead of
just concatenating pieces of strings, like:
string.append(key).append(" ");
...and this on the rest of the patch.
HTH.
--
Bo Maryniuk
SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
HRB 16746 (AG Nürnberg)
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Audit Logging
On 08/30/2011 06:58 PM, Duncan Mac-Vicar P. wrote: An alternative implementation we may consider for a second iteration is to have Spacewalk send the messages via AMPQ to a broker (apache QPid seems to have a reasonable footprint), and the current daemon could fetch from there to the outputs, turning itself into a simple agent. Yes, and additionally to that, while AMQP (a *protocol*) makes more sense to integrate various distributed software rather then make components talk to each other on a single local host, still AMQP itself does not abolishes the fact that the messages are still needs to be delivered from its queue to an actual audit log analyzer in a single format. -- Bo Maryniuk SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Audit Logging
On 08/29/2011 03:14 PM, Cliff Perry wrote: In short, my personal preference is not to become a toaster if audit logging has crashed (including out of space to write). Cliff, if Taskomatic has crashed, the Spacewalk will be a toaster as well. I believe the reliability is a different topic. -- Bo Maryniuk SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Audit Logging
On 08/30/2011 02:14 PM, Jan Pazdziora wrote: But Bo Maryniuk said in the initial post: Q: Does it takes care of being tamper-proof? A: No. The software component is responsible only to collect various You cannot access it as a spacewalk admin. -- Bo Maryniuk SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Audit Logging
On 08/30/2011 12:46 PM, Jan Pazdziora wrote: I'd much rather see a patch which would [...] finish the Perl-to-Java migration of the outstanding .pxt Web pages. The topic is about Audit logging right now and you have your own personal opinion on this. There will be always various ideas, of course... > What if the daemon is down? That was answered multiple times already in detail. > So why not start with using AMQP as the daemon, and making your > daemon optional? It is optional. > If the patch should have any chance of being included in Spacewalk > upstream, it has to be under GPLv2 as well, since according to > >http://www.apache.org/licenses/GPL-compatibility.html Of course. Spacewalk patch will be GPL as it is directly linked to. -- Bo Maryniuk SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Audit Logging
On 08/25/2011 05:43 PM, Miroslav Suchý wrote: AuditLog.java has 4 (!) functions log() and all of them has different semantics - if I ommit that they are utilized to logging. Please consider different names. Four? Functions?.. I see three and they are methods, where only one is public. This is called overloading and was around for a few decades... Why you dislike that part? > In your design it will be hard to say which actions are audited. > Especially in 2 years from now, when other will add/remove/change your > initial audit calls. I thought the patches reviews you, guys, doing are more than just works/not-works? :) Generic approach is exactly what we already tried to do at the very beginning. -- Bo Maryniuk SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Audit Logging
On 08/25/2011 04:18 PM, Miroslav Suchý wrote: You want to audit just frontend? No, everything. I.e. if I do some changes through backend it will not be logged? No, they will. -- Bo Maryniuk SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Audit Logging
On 08/24/2011 01:41 PM, Miroslav Suchý wrote: Q: Why not just another log appender? A: We believe it should be generic, agnostic and reliable. Hence the embedded database and thread black magic are involved among other things. :) This is where I disagree. But I would like to see your code and maybe I will change my mind. Probably I had not the best explanation here. Actually, there *are* log appenders at the Spacewalk part, so we just continue to use the same log4j the same fashion in the Java part, Python logger etc. But the appenders are actually an XML-RPC clients to the daemon. Then since you have various destinations, like a slow and remote RDBMS, like other solutions, the daemon is *separately* delivers them, after an event already been accepted. Q: How fast the thing is? A: 1000 messages linearly per 0.42 sec per instance should be enough. That is quite slow IMO for logger. Well, if your admin can do more than 2000 changes-per-second, then just let me know... :) -- Bo Maryniuk SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Audit Logging
On 08/24/2011 01:20 PM, Tomas Lestach wrote: what was the original use/business case for the audit logging add-on? To know who did what, when and from where. How do you plan to present the audit information? I plan to send it where it is needed in the way the destination is asking. So it depends. -- Bo ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Audit Logging
Hi, all! Here at SUSE we are working on an audit logging. As we all perfectly know, the Audit Logging is not just a logging in the sense as a syslog for like debugging or alerting etc. We developing an add-on for the Spacewalk. It should collect events from various components and then bring them all to a single point, thus send later to a various destinations (XDAS, databases, indexers etc). Hence I would like shortly introduce what this is all about. Architecture The main core of the logger is a separate daemon that serves XML-RPC listener to a localhost only. Then each software component in the Spacewalk is going to send an logging event message through it. Daemon is designed in a queue fashion, where request gets immediate response, message is accepted inside an embedded database and then processed accordingly. This way it won't impact software components performance. The API for XML-RPC are intentionally generic: they accept a login ID, a string message and a key/value map. While first two parameters are pretty obvious how to use, the key/value map is specific to the scope of audited software. The keys are validated according to a defined structure format, which can be totally different for another components or software group. The validator is a plug-in, which implements specific structure validation. In this way we have a generic auditing collector that can be reused elsewhere or integrated with just anything. There are plugins for: 1. Delivering messages. 2. Validating key/value mapping to prevent posting inconsistent nonsense. Delivering message plugins are: 1. RDBMS (PostgreSQL and Oracle). Stores data in two tables. 2. XML file. Appends data to an XML file. 3. Syslog (TCP, UDP and local). Has advantage to allow reconcile multi-line posts, once messages are too big to fit in one line. 4. STDERR and STDOUT :-) Validator plugins: 1. Spacewalk schema validator. Plugins can be reused in an unlimited combinations and instances: you can feed several databases, syslogs, XML files etc, if needed. Impact on a Spacewalk Entire Spacewalk components are going to be altered, where each audit-able action will perform a call. We already developed an log4j appender and now processing all Java part and XML-RPC backend and a frontend. This will help community to reconnect audit to something totally else, if they would really like to do so. Perl/Python-based and other components will always "talk" to the audit logger over XML-RPC, thus never link directly. The feature will be turned off by a default and will be able to turn it on in a Spacewalk conf, like: "audit = on". You might ask... Q: Why not AMQP or other messaging? A: We considered that. But concluded that we rather want it small, straightforward and simple, available everywhere: http://goo.gl/usti8 :) Q: Why not just another log appender? A: We believe it should be generic, agnostic and reliable. Hence the embedded database and thread black magic are involved among other things. :) Q: A daemon? A: Yes. A daemon. Because if this would be a servlet on a Tomcat, so once Tomcat "feels sour" during various reasons, like a star wars satellite accidentally blew up WAN or endothermal recalibration caused failure converting big to little endian, for example :-), then the rest of the stack won't properly functioning. That should not happen. Q: How fast the thing is? A: 1000 messages linearly per 0.42 sec per instance should be enough. Q: Does it takes care of being tamper-proof? A: No. The software component is responsible only to collect various "wild" components and comb the output to a single standard that will be delivered to the enterprise archive, like EMC Centera, for example. Contribution plans We are going to open it under Apache Licence 2.0 and contribute back to the community along with a mega-patch for Spacewalk 1.2 base. If you have any feedback to this and ideas what else could be good, we welcome you to share your thoughts. Have a lot of fun! -- Bo Maryniuk SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] dojo - javascript framework
On 06/21/2011 03:54 PM, Miroslav Suchý wrote: Can you share with us the pro and cons? It all sounds interesting to me. Miroslav, this is a lengthy research with lots of manhours and money invested, evolved across many stages, experiences, projects and so on. Hence I can not just summarize it all in one single e-mail. Come to Nurnberg one day to our Workshop conference and let us have a talk. :) We believe that current way in a Spacewalk is not so efficient to maintain, build and develop. The whole Java part is mainly just a GUI. And it is already bigger than entire backend. Is this is what we want? We also strongly believe that we can do much better and inspire community to make the difference. We respect the old code and it was done in its time, but we find that it is a time to move better. So to make it happen, instead of blowing everything and rewriting from scratch in the next 10 years, we doing step-by-step replacements of small pieces, keeping them separated and reusable later. Now, technically GWT/Vaadin brings you a full-blown Java, where you focus on your UI and on your back-end so the whole coding paradigm is identical like one would code a plain Swing GUI. We find it dramatically improves development, if you are on Java. GWT also allows to use static HTML to design some web-style page, getting away from desktop-style app and bind the widgets to the HTML elements, allowing a typical web-designer play with skins, custom CSS and so on. So the framework is actually very flexible. We don't go with a plain GWT, because of the following reasons: - it requires explicit Google RPC implementation and limited Java object serialization. Things, like SmartGWT or ExtGWT are only set of widgets, so they still requires Google RPC around. - it supports only a subset of Java. Even String.format is not allowed... - it sucks to wait 3-6 minutes each time GWT compiles. :) Vaadin brings you already precompiled widgets[1], so to rebuild, deploy, run and see the changes right in the Spacewalk with Vaadin app, in a NetBeans IDE would take just literally one mouseclick and just in a few seconds. - Vaadin supports "Back" button, remembers the form values and settings transparently, has very sophisticated validation, lazy loading and other sweet features that others does not have. Don't get us wrong, we also aware of tradeoffs of the Vaadin: it is a server-side framework, hence slower than a plain GWT, which is mainly client-side. Vaadin keeps MVC on a server side and also sometimes gives you a relative pain to workaround its automatic nature, when you need some JavaScript short-cut, e.g. webcam image slideshow or MJPEG streaming from your surveillance cameras etc, hence you need properly develop your new widget, package and then use (this is a painful part, if you compare with like a "throw-a-simple-script-and-use"). Yet Vaadin scales very well and it is possible to handle a very big amount of concurrent connections pretty easily. And we believe that this toolkit perfectly fits to administration types of applications and it is a part of a Liferay, if you know what I mean. We also don't want to look like promoters of only one framework, so the whole message is that we just share with you, guys, what did we researched, concluded and where we decided to go and how it will be in a future at least for SUSE. Of course, we are open to collaborate, help and join efforts to make it happen faster and even more efficient! Hope it helps. __ 1. In case you use Add-ons, you still need to recompile the add-on once. But only once and never more. -- Bo Maryniuk SUSE LINUX Products GmbH ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] dojo - javascript framework
Hi! Guys, since there are started talks about "ajaxificationized beautification" :) then I would like to say that actually at SUSE we are now doing completely other way and I would like to explain what, how and why. Because of the nature of the SUSE, we have a lot of our own specific parts that needs to be integrated with a Spacewalk. This leads to a need of more modular architecture that needs to be even more flexible. Hence of the above, we decided to develop in the way Portlets are done, where the applications are residing in a parallel to the main app (Spacewalk in this case) and are just embedded into the main UI. This will allow us go away from Struts in general and also avoid a lot of unnecessary code. That said, every add-on we do, will be served as a separated application, the very similar way how Portlets are working. Now, to do this, we've decided to use Google Web Toolkit with a conjunction of Vaadin (server-side) framework. This gives us: - Homogeneous environment. All code is written in Java (no more JavaScript and XML). - Much simpler architecture. - Up to 70% coding reduction. - "Full-blown" Java. And it is not just a subset of Java, as in case of a pure GWT. - Ability to use jQuery or Dojo or other stuff, if we ever would need them at all. There are many various discussions about how good/bad GWT is, but we weighted all the tradeoffs, pros and cons, we were looking at other stuff, like Wicket or ZK and even OpenLaszlo, as well as ExtGWT or SmartGWT but we are convinced that GWT with Vaadin is the very way we will go with. Hence we are going to package GWT with Vaadin and ship it with our SUSE Manager. We understand that this is a very radical change and very different from where Spacewalk is right now. We also understand that lots of people might not like this and prefer to stay with old traditional way. But at the same time we strive to achieve best user experience as well as simpler maintainability along with many other goals. If somebody in a Spacewalk community is interested to try it out, the best place to "attack" is to port all the Perl-based user interface and get rid of that PXT session thing as a whole (and probably from the whole Perl itself as well). Vaadin: https://vaadin.com/ Demo: http://demo.vaadin.com/sampler Add-ons (if you think the standard lib is not enough for you): https://vaadin.com/directory Quick start: https://vaadin.com/learn 10 minutes tutorial: https://vaadin.com/tutorial Documentation: https://vaadin.com/book * * * Now, as of Dojo discussion, at SUSE we would vote for jQuery instead. Taking "$FOO is in $DISTRO" is, of course, a plus, but this is "plus" for a Fedora Linux distribution, but is not a value of a specific library itself. Take care. :) -- Bo SUSE LINUX Products GmbH On 06/20/2011 05:33 PM, Miroslav Suchý wrote: I know that we thought about using javascripts tabs in webui... Well if somebody want to work on that, I announce you that dojo [1] framework is now part of Fedora and EPEL (I done the review). I encourage you to use it. It has two plus: a) it is the only one js toolkit in Fedora b) it is the fastest one from all existing toolkits [2] (ehm, sometimes second fastest). [1] http://dojotoolkit.org/ [2] http://dante.dojotoolkit.org/taskspeed/# ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] At v1.5+ org.apache.juli.logging.LogFactory missing in the classpath
On 05/09/2011 11:03 AM, Jan Pazdziora wrote: this thing is a bug in Fedora's tomcat6 OK, now clear. Many thanks. :) -- Bo ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] At v1.5+ org.apache.juli.logging.LogFactory missing in the classpath
On 05/06/2011 09:06 PM, Jan Pazdziora wrote: OKay but what do you propose we do? Add this thing to the common classpath, perhaps? I just tagged and built the latest spacewalk-java package, Well, that's what I just did the same: git pull to the latest version. What OS are you building this on? Fedora 14. Aren't you using some sort of developer's setup instead of properly building via rpm? Yes, developer setup, of course. It is built from the latest sources. -- Bo ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] At v1.5+ org.apache.juli.logging.LogFactory missing in the classpath
Hi! I've just updated source to the last version (last commit was by Marcelo, bbc13b8e49e78dbe463b4aaa495a5b9ecef9bc81). At this point I am unable build Java part, unless I add manually /usr/share/tomcat6/bin/tomcat-juli-6.0.26.jar The error is: BUILD FAILED /java/buildconf/build-taskdefs.xml:25: taskdef A class needed by class com.redhat.rhn.internal.jasper2.JspfC cannot be found: org/apache/juli/logging/LogFactory However, quickly adding the jar above to the current $CLASSPATH, it compiles. -- Bo ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] What to do with an Oracle-only set-difference operator "MINUS"?
Hi! There is an Oracle-only operator for a set differences, called "MINUS" and seems like it is already known problem when it comes to PostgreSQL. It is seen in a several places, like hard-coded directly in Java code com.redhat.rhn.manager.system.SystemManager as well as in web/modules/rhn/RHN/DB/DataSource/xml/Package_queries.xml as "snapshot_unservable_package_list" query. Seems like there is no way to use PostgreSQL's "EXCEPT" along with current query, so should we rewrite query in different way, like "NOT IN" or and outer join? -- Bo ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
