Re: [Spacewalk-devel] Cobbler breaking re-provisioning?
I'm not making any accusations here - I'm only asking if this was decided to be the new behaviour for Spacewalk/Satellite/Cobbler. Should there be an inconsistency between fresh kickstart installs and re-provisions? It is intended that, if you have the network configuration snippets referenced in your kickstart templates, that you will be using the network configuration scripts that Cobbler generates rather than pushing out your own. If you don't have those snippets there, things just work. If existing Spacewalk generated (templated, not raw uploaded) scripts insert these snippets blindly into existing kickstarts, that might be a bug in Satellite, as they should generate the same kickstart output (essentially) both before and after the upgrade -- I agree with that. I don't agree that Cobbler broke it... Spacewalk's particular usage of Cobbler, yes. If you are using self-uploaded-into-Spacewalk kickstart templates based on /var/lib/cobbler/kickstarts/sample*.ks, then you would need to remove the network configuration portions if you wanted to write your own things in %post. I can mostly speak for Cobbler and not Spacewalk, so perhaps Spacewalk folks can weigh in with what you'd need to do. Thanks Duncan Innes ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Cobbler breaking re-provisioning?
On 10/07/2009 11:51 AM, Duncan Innes wrote: Hi, I'm testing this on Satellite 5.3 at the moment, but the inclusion of Cobbler appears to break re-provisioning. My kickstarts use a postinstall script to configure the network scripts according to which configuration files are installed by the relevant activation keys. Unfortunatley, cobbler seems to write it's own network config files and then deletes everything that may have existed proir to that. So I can't even push anything to /etc/sysconfig/network-scripts. The erroneous part of cobbler.ks is as follows: %post ( /opt/edft/bin/postinstall )>> /root/ks-post.log 2>&1 # Start post_install_network_config generated code mkdir /etc/sysconfig/network-scripts/cobbler cp /etc/sysconfig/network-scripts/ifcfg-lo /etc/sysconfig/network-scripts/cobbler/ # Start configuration for eth0 IFNAME=$(ifconfig -a | grep -i '00:24:81:E3:F9:78' | cut -d ' ' -f 1) if [ -f "/etc/modprobe.conf" ]&& [ $IFNAME ]; then grep $IFNAME /etc/modprobe.conf | sed "s/$IFNAME/eth0/" /etc/modprobe.conf.cobbler grep -v $IFNAME /etc/modprobe.conf>> /etc/modprobe.conf.new rm -f /etc/modprobe.conf mv /etc/modprobe.conf.new /etc/modprobe.conf fi echo "DEVICE=eth0"> /etc/sysconfig/network-scripts/cobbler/ifcfg-eth0 echo "HWADDR=00:24:81:E3:F9:78" /etc/sysconfig/network-scripts/cobbler/ifcfg-eth0 echo "ONBOOT=yes">> /etc/sysconfig/network-scripts/cobbler/ifcfg-eth0 echo "BOOTPROTO=dhcp" /etc/sysconfig/network-scripts/cobbler/ifcfg-eth0 # End configuration for eth0 rm -f /etc/sysconfig/network-scripts/ifcfg-* mv /etc/sysconfig/network-scripts/cobbler/* /etc/sysconfig/network-scripts/ rm -r /etc/sysconfig/network-scripts/cobbler if [ -f "/etc/modprobe.conf" ]; then cat /etc/modprobe.conf.cobbler>> /etc/modprobe.conf rm -f /etc/modprobe.conf.cobbler fi # End post_install_network_config generated code # Start koan environment setup echo "export COBBLER_SERVER=vstlbsatx01.edftrading.com" /etc/profile.d/cobbler.sh echo "setenv COBBLER_SERVER vstlbsatx01.edftrading.com" /etc/profile.d/cobbler.csh # End koan environment setup wget "http://vstlbsatx01.edftrading.com/cblr/svc/op/ks/system/tcplrdacs01.edftrading.com:1"; -O /root/cobbler.ks wget "http://vstlbsatx01.edftrading.com/cblr/svc/op/trig/mode/post/system/tcplrdacs01.edftrading.com:1"; -O /dev/null Is this happening from Spacewalk too? Duncan ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel Rather than point blame about what you /think/ is wrong, I'd recommend just stating the problem you are seeing and let us go from there. In this case, Cobbler is not broken. Your usage of your kickstart template, however, is incompatible with them. Cobbler network objects eliminate the need to have seperate needs to configuring networking. If you are doing your own thing, remove the network snippets from the Cobbler template. --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] FYI -- Cobbler 2.0
Cobbler 2.0 is now available, and should be in Fedora/EPEL testing very soon. https://fedorahosted.org/pipermail/cobbler/2009-September/004983.html Testing w/ Spacewalk welcome. --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Dojo?
Cliff wrote: So, anyone looked at dojo in the pass? If so, thoughts on it? Could/would it replace our list tag? Make it better? Compatible licenses? The old age problem of how to represent lots of data in a timely manner to Spacewalk folks and allow them to sort/select/filter/paginate that data. Not saying 'we need to be using this!' - but more interested in what others think about it :) http://en.wikipedia.org/wiki/Dojo_Toolkit Thanks, Cliff ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel Sidenote, no Fedora packaging guidelines for javascript libraries yet -- though one problem we face is that all the compressors are non-free, thus we can't include the compressed versions in any RPMs. Personally I think this is a huge roadblock Fedora needs to solve somehow. Until then, apps could include such libraries but cannot package the compressed versions IIRC. IMHO, javascript is a requirement for any modern web application, and those that use things like NoScript would need to grant exemptions. --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Warning: planning for Cobbler 1.6 release around 3/15
This release contains numerous XMLRPC performance enhancements that will be very beneficial to spacewalk.XMLRPC now suffers no penalty for large configurations other than at cobblerd startup, in particular, and cobblerd is now one process instead of four. Anyway, I think I've mentioned this before, but Spacewalk /must/ be coded to know that the following XMLRPC endpoint is going away: http://cobbler.example.org/cobbler_xmlrpc_rw The correct process to connect to any version of cobbler is connect first to http://cobbler.example.org/cobbler_xmlrpc If the version call yields >=1.5, go ahead and login against the above URL If that version is <1.5, log in to cobbler_xmlrpc_rw (Please do not modify the Apache configuration to keep cobbler_xmlrpc_rw pointing to the old URL, and also do not connect to an XMLRPC port number directly as the users can change these ports) Changing spacewalk code now to anticipate this release is recommended. (There are no API changes, this only effects the endpoint) Future versions of Spacewalk can just require Cobbler >= 1.6 and not have the code to look for the correct endpoint. --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Cobbler architecture diagram
Michael DeHaan wrote: I'm putting together some more visual information on Cobbler, though I thought spacewalk folks would find this useful. https://fedorahosted.org/cobbler/attachment/wiki/ChartsAndGraphs/code.png More pictures to come. --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel Added a bit more, https://fedorahosted.org/cobbler/wiki/ChartsAndGraphs There's a object graph picture and also a diagram that shows what cobbler replication can do. --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Cobbler architecture diagram
I'm putting together some more visual information on Cobbler, though I thought spacewalk folks would find this useful. https://fedorahosted.org/cobbler/attachment/wiki/ChartsAndGraphs/code.png More pictures to come. --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PATCH: Add web UI for managing Cobbler Snippets
Coe, Colin C. (Unix Engineer) wrote: Hi All Attached is a patch that adds web UI for managing Cobbler Snippets. The only problem with this that I am aware of is the inability to delete snippets that have been created, however I believe that this is due to the tomcat5 policy. Also, many thanks to those on the mailing list and on #spacewalk-devel that helped with this work. Comments/criticism welcome. Thanks CC This is a good idea for Satellite, though ideally I'd like to see Cobbler Web have the same feature -- it's just as useful there. Adding/deleting, and enumerating of cobbler snippets should /ideally/ happen over the Cobbler API to also make this more scriptable. In this case I'd like to see associated changes made in Cobbler's remote.py and it done that way, rather than assuming too much about cobbler's filesystem layout and storage, which may be subject to change. --Michael NOTICE: This email and any attachments are confidential. They may contain legally privileged information or copyright material. You must not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages and all attachments. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] What does "cobbler-clear" do?
I'm looking at https://hosted.fedoraproject.org/spacewalk/browser/scripts/cobbler-clear If this is for development purposes only and is not something you install, "rm -rf /var/lib/cobbler/config/distros.d" (repeated for profiles.d, systems.d, images.d, and repos.d) is ok.I'm hoping we don't have the need for a "cobbler-clear" script to be installed in a user config, as we should be respecting the user's cobbler configuration. If you are doing this from software, the most efficient way to do it is via a Cobbler python API script. For 1 systems, doing the above with xargs could take /hours/ since cobbler is reanalyzing the configuration every time you invoke /usr/bin/cobbler. --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] bugzilla
Mike McCune wrote: Jesus M. Rodriguez wrote: On Sat, Jan 24, 2009 at 4:00 PM, Travis Camechis wrote: Is there a way for me to get emails when bugs are entered/updated? I haven't used bugzilla before and Im not sure if that is even possible without being a core developer. You can add yourself to the CC list of the bugzilla. jesus Just create yourself an account first in bugzilla: https://bugzilla.redhat.com/createaccount.cgi Every release uses a 'tracker' bug called space** where 0.5 will be space05 (you can alias any given bug to a string for convenience) where we collate all the bugs for the release to 'block' that bug. This creates a tree of bugs for any given release: https://bugzilla.redhat.com/showdependencytree.cgi?id=space05 That is the best way to track our releases and for any given bug that you are interested in, like others said, just add yourself to the CC field and you will get email for every change to the bug. Mike In the interest of "there's more than one way to do it", bugzilla queries also have RSS feeds. Click "Feed" at the bottom of the page and add it to your RSS reader. For instance, you could get a feed of all Spacewalk bugs. Bugzilla also has a creepy "watch this user" feature that is a bit more broad. https://bugzilla.redhat.com/userprefs.cgi?tab=email --Michael --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Informal Devel Environment Survey
Jesus M. Rodriguez wrote: On Fri, Jan 23, 2009 at 12:27 PM, Michael DeHaan wrote: Jesus M. Rodriguez wrote: On Thu, Jan 22, 2009 at 3:03 PM, Coe, Colin C. (Unix Engineer) wrote: I've found that doing the steps under 'Deploying Development Schema' doesn't work (for me anyway) and ends up needing to redo the dev environment. Also, I'd like to see https://fedorahosted.org/spacewalk/wiki/JavaDesign fleshed out a lot more. Anything in particular? I'd be happy to update it. jesus ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel Could the dev-environment be more appliancey? How about a shell-script/recipe to automate environment setup, or publishing a kickstart for installation of a dev-environment in a virtual machine (with just the virt-install command and kickstart, you should be good to go)? One problem is grabbing the Oracle bits, for now, so that may have to be a one-off, but everything else, perhaps... The appliance idea is a decent one, and worth adding to the list of dev setups. I personally use a virt guest to do my development in. I wouldn't want the appliance to be the only way of dev setup. A great idea though. jesus ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel By appliance I mean a virt guest with a kickstart and and embedded/recipe script that gets everything working. It should not be an image. --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Informal Devel Environment Survey
Jesus M. Rodriguez wrote: On Thu, Jan 22, 2009 at 3:03 PM, Coe, Colin C. (Unix Engineer) wrote: I've found that doing the steps under 'Deploying Development Schema' doesn't work (for me anyway) and ends up needing to redo the dev environment. Also, I'd like to see https://fedorahosted.org/spacewalk/wiki/JavaDesign fleshed out a lot more. Anything in particular? I'd be happy to update it. jesus ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel Could the dev-environment be more appliancey? How about a shell-script/recipe to automate environment setup, or publishing a kickstart for installation of a dev-environment in a virtual machine (with just the virt-install command and kickstart, you should be good to go)? One problem is grabbing the Oracle bits, for now, so that may have to be a one-off, but everything else, perhaps... --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] #!/usr/bin/env python to #!/usr/bin/python
Clifford Perry wrote: Jan Pazdziora wrote: On Wed, Jan 14, 2009 at 08:57:38AM -0400, Devan Goodwin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Actually, this AVC denial is about different problem. So it was not a good example. But nevertheless: shouldn't we decide for env or direct path in the shebang line and be consistent about it? +1. I'd go the other direction though and stick with "/usr/bin/env python", iirc that's considered best practice to accommodate people with Python installed in a weird location or using multiple versions. If you have Python in a weird location, you probably won't have osa-dispatcher .py files installed in its PYTHONHOME, will you? So, the first import which assumes that the python you run actually has all the prerequisites installed, will fail. Alternatively, mixing different pythons and libraries from different pythons might produce weird results because symbols referenced in one library might not be present in the library from that second python. We actually have (non-public) bugzilla about this very problem. I'd argue that we should stop pretending that /usr/bin/env python will work in the general case, any just put /usr/bin/python there. If someone needs to run it with different interpreter, they can always do python /the/path/to/the/script I would prefer the hard code path to the python binary for reasons stated by Jan above. Folks - other than preference normally - please give feedback based on this above information. Cliff I'd suggest /usr/bin/python without the env. If the RPM doesn't work with the distribution-specific Python, things are quite busted, and folks shouldn't expect them to work. We do not package two python versions, and the modules won't be properly installed as required by the RPM. --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Cobbler and SELinux?
Jan Pazdziora wrote: Hello cobbler guys, I've noticed that cobbler tends to run as root, and as initrc_t: root:system_r:initrc_t root 13836 0.0 0.6 13748 6340 ? S11:43 0:00 /usr/bin/python /usr/bin/cobblerd --daemonize root:system_r:initrc_t root 13843 0.0 0.6 13748 6260 ? S11:43 0:00 /usr/bin/python /usr/bin/cobblerd --daemonize root:system_r:initrc_t root 13847 0.0 0.6 13748 6164 ? S11:43 0:00 /usr/bin/python /usr/bin/cobblerd --daemonize I did not find any cobbler-selinux package in EPEL (testing). What is the correct way of getting cobbler confined? There's already a discussion on this on Cobbler list about this (replies to cobbler-list, please): https://fedorahosted.org/pipermail/cobbler/attachments/20090109/2726cafe/attachment.eml Dominick Grift has a rough starter policy that needs some testing and refinement, and then we can ship that with Cobbler 1.6 when it comes out. --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] RE: Couple of questions
Coe, Colin C. (Unix Engineer) wrote:
Ahh, just found and ran /usr/bin/cobbler-setup. Now in
/var/log/tomcat5/catalina.out I get:
2009-01-05 11:56:32,672 [TP-Processor6] ERROR
com.redhat.rhn.domain.kickstart.KickstartFactory - Error trying to write KS
file to disk: [/var/lib/rhn/kickstarts/ks-test-3--1--Spacewalk_Public_Cert.cfg]
ks-test-3 is the name of a test kickstart profile I was trying to create and
/var/lib/rhn doesn't exist on my system.
Thanks
CC
For what it's worth -- cobbler-setup is not in Cobbler 1.4.X, and as I
recall, the spacewalk installer doesn't package it anymore.
I think you just want spacewalk-setup?
-Original Message-
From: spacewalk-devel-boun...@redhat.com
[mailto:spacewalk-devel-boun...@redhat.com] On Behalf Of Coe,
Colin C. (Unix Engineer)
Sent: Monday, 5 January 2009 11:01 AM
To: spacewalk-devel@redhat.com
Subject: [Spacewalk-devel] Couple of questions
Hi all
First up, I'm working on a patch to add a 'nicer' editor to
replace textareas in specific places (Kickstart pre/post
scripts and config file creatation and editing). The problem
I'm having is when I change
to
id="contents">${revision.configContent}
in
java/code/webapp/WEB-INF/pages/common/fragments/configuration/
channel/create.jspf, I get the following displayed in the
textarea and the newly created file is empty.
com.redhat.rhn.domain.config.configcont...@21f3ee79[id=6,fileS
ize=0,md5sum=d41d8cd98f00b204e9800998ecf8427e,isBinary=false,c
ontentsBlob=,created=2009-01-05
08:31:30.0,modified=2009-01-05 08:31:30.0]
I realise that ${revision.configContent} is giving me the
complete object, how do I just what is contained in
'contentsBlob'? i.e. the file data rather than the meta
data. I've tried ${revision.configContent.contentsBlob} and
${revision.contentsBlob}, both give me tomcat errors.
Lastly, I'm pretty much fully sync'd with the git repo and
what I find is I get errors in /var/log/tomcat5/catalina.out:
---
2009-01-05 11:36:02,618 [TP-Processor6] ERROR
com.redhat.rhn.manager.kickstart.cobbler.CobblerLoginCommand
- XmlRpcFault while logging in. most likely user doesn't
have permissions.
redstone.xmlrpc.XmlRpcFault: cobbler.cexceptions.CX:'login
failed: spacewalk'
---
I've installed cobbler but not configured it. Is there a
howto for this as yet?
Thanks
CC
NOTICE: This email and any attachments are confidential.
They may contain legally privileged information or
copyright material. You must not read, copy, use or
disclose them without authorisation. If you are not an
intended recipient, please contact us at once by return
email and then delete both messages and all attachments.
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
NOTICE: This email and any attachments are confidential.
They may contain legally privileged information or
copyright material. You must not read, copy, use or
disclose them without authorisation. If you are not an
intended recipient, please contact us at once by return
email and then delete both messages and all attachments.
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk and SELinux: progress status
Dennis Gilmore wrote: On Wednesday 17 December 2008 02:43:49 pm Michael DeHaan wrote: Well, we could check sestatus for disabled. FWIW, a bit easier: /usr/sbin/selinuxenabled returns 0 if enabled. Just found out about that recently :) or /usr/sbin/getenforce will tell you if its in enforcing, permissive or disabled Dennis ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel Yeah what I meant was the software needs to know when to apply context based on whether it's enabled/disabled, not whether it's enforcing, to cover use cases of "trying out in permissive, now switch it". ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk and SELinux: progress status
Well, we could check sestatus for disabled. FWIW, a bit easier: /usr/sbin/selinuxenabled returns 0 if enabled. Just found out about that recently :) ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk and SELinux: progress status
I don't have selinux on. Is this expected? it took almost 10 minutes and I eventually just CTRL+C-ed it. Well yes, we run restorecon on /var/satellite to set correct context, even if you are not in Enforcing. It is not expected to fail thou. Also calling restorecon with selinux disabled probably won't work. Cobbler makes sure it doesn't bother with restorecon in those instances. Enable in /etc/selinux, touch /.autorelabel, and reboot? You'd want to strive for 100% clean runs in setroubleshoot. FYI -- Recently Dan Walsh recommended I /not/ support SELinux on EL 4, and only do EL 5 since it was more manageable (supports public_content_t).Seeing this impacts spacewalk, I would suggest spacewalk take the same position. --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] httpd.conf?
Mike McCune wrote: Jan Pazdziora wrote: On Wed, Dec 10, 2008 at 11:02:06PM -0500, Jesus M. Rodriguez wrote: Mike, I thought we were getting rid of satellite-httpd in favor of /etc/httpd/conf.d? http://git.fedorahosted.org/git/?p=spacewalk.git;a=commitdiff;h=056892dfcd5dcabc49bb7b487033227ed5268f13 Well, some people pointed out how good it would be to do that but noone has shown how exactly to handle the SSL VirtualHost problem. Yes, we are getting rid of it but I'm hedging a bet that we won't have time to get to it during 0.4 Mike ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel The problem with apps that clobber http.conf is they'll break any other web app on the system. Since the release is going to contain Cobbler I would /much/ rather that Cobbler own and deploy it's own configuration file rather than having Spacewalk set up a configuration that ignores it. This makes upgrades much much easier as well, and ensures that user customizations to httpd.conf are preserved. --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] changing of progress indicator?
Jan Pazdziora wrote: On Thu, Nov 13, 2008 at 09:06:06PM -0500, Jesus M. Rodriguez wrote: Jan, Um really? :) Were the lines boring you? We needed something to visually distinguish the new version from old versions right at the beginning, in the installer. print "I'm the new version!" ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] root as contributor
Michael DeHaan wrote: Mike McCune wrote: Miroslav Suchý wrote: Welcome root :) http://miroslav.suchy.cz/spacewalk/gitstat/commit-detail.php?commit=6cdf4423e04ffd66fda796e4946a662a9a03e497 and 3 others commits Can you please use your real identity for commits? Thx. Anyone have any good tips on how we can change the author on those commits? I asked this question previously, with a different reason in mind -- attributing patches that didn't get committed with "-m" (which I normally don't do). Short answer: git-commit with --ammend can be used to fix the /last/ commit Want to do more? Generally it's considered dangerous to muck with the history. (That's why it's called history) Did find some things on Google but I wouldn't recommend it: http://blog.jacius.info/articles/2008/6/22/git-tip-fix-a-mistake-in-a-previous-commit Basically if you can avoid editing code as root, it becomes easier :) --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel Additionally, you may want to do this: git config --global user.name Your Name git config --global user.email [EMAIL PROTECTED] ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] root as contributor
Mike McCune wrote: Miroslav Suchý wrote: Welcome root :) http://miroslav.suchy.cz/spacewalk/gitstat/commit-detail.php?commit=6cdf4423e04ffd66fda796e4946a662a9a03e497 and 3 others commits Can you please use your real identity for commits? Thx. Anyone have any good tips on how we can change the author on those commits? I asked this question previously, with a different reason in mind -- attributing patches that didn't get committed with "-m" (which I normally don't do). Short answer: git-commit with --ammend can be used to fix the /last/ commit Want to do more? Generally it's considered dangerous to muck with the history. (That's why it's called history) Did find some things on Google but I wouldn't recommend it: http://blog.jacius.info/articles/2008/6/22/git-tip-fix-a-mistake-in-a-previous-commit Basically if you can avoid editing code as root, it becomes easier :) --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: Supporting other repositories.
Stephen John Smoogen wrote: On Fri, Nov 7, 2008 at 12:55 PM, Dennis Gilmore <[EMAIL PROTECTED]> wrote: On Friday 07 November 2008 12:10:08 pm Stephen John Smoogen wrote: Ok loaded term but I was wondering if we could work with spacewalk, ipa, ds, etc to support their work by including at least a spacewalk-release or similar item. This would allow us to 'test' the waters of working closer with the other layered upstreams. Basically instead of having to hunt around for every different repository, we work with the upstream project ot have a signed release that works with the EPEL releases. Anyway.. back to dealing with local stuff.. I figured I should fire it off before I forget. Other than completely violating fedora's guidelines that EPEL is subject to. I don't think its a good idea. It makes it too easy to not do the work needed to get things into fedora/EPEL The issue I am trying to deal with is several issues 1) we have RH-upstream-product-0.X needing something that RHEL-4/5 do not ship in apache etc Its going to happen because thats just how software projects go. I think we need to take a big heavy stick to those projects. As much as I'd love Python 2.5 on RHEL 4 :) 2) we have stuff in EPEL that would replace a layered product. I mean if we put spacewalk in and it replaces something from RHN-supported-product. I really am not worried about sales.. someone's going to make rebuilds available somewhere but I am trying to work out a way that someone is not going to clobber themselves by having a RH product and enabling EPEL on the box. Mutual conflicts: tags should be sufficient. 3) product timeline does not match up with EPEL timeline. This happens a lot with the cobbler/koan/func stuff where they are implementing fixes but I could see it happening in say IPA etc. where they have a midmonth release or 'just-a-bugfix' upgrade. This is a consequence where it's important for products to target a "version or later" API and be tolerant about what to do when applications are missing features. Applications must also maintain stable APIs that continue to work. I encounter some of this with libvirt being more capable on newer platforms but in all actuality it's not a big problem. Generally our strategy to do this is web services, and applications should support a method that returns the versions of their API. For applications that are more tightly integrated they'll have to make appropriate workarounds. It is true that EPEL moves too slowly to get bugfixes out, though this can be countered by pointing folks at EPEL testing until some day where that could hopefully be run more frequently and under Bohdi. Needless to say, apps like Cobbler and Func are closely related to the Spacewalk team here, so I don't really see it being a problem with having different priorities. Making Spacewalk successful is definitely a major priority. fedora-ds is in fedora I suggest that you ask richm to build fedora-ds into EPEL. freeipa is in fedora also. we should talk with rcrit to get freeipa branched and built for EPEL it will require fedora-ds to be there first. ++ ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Announcing Spacewalk 0.3
Brandon Perkins wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael DeHaan wrote: Stephen John Smoogen wrote: On Mon, Nov 10, 2008 at 1:53 PM, Michael DeHaan <[EMAIL PROTECTED]> wrote: Vladimir Zlatkin wrote: Clifford Perry wrote: Vladimir Zlatkin wrote: Jesus M. Rodriguez wrote: * rhn-satellite is no longer in /etc/init.d, use /sbin/rhn-satellite to start/stop the entire satellite. I am curious, what is the motivation for this change? Various levels of breakage in having on chkconfig style script owning multiple daemons. Move to a more per daemon init script and have /sbin/ command to stop/start them all at once if needed once booted up. Allow for the daemons to start cleanly also when switching run levels. Michael Mraka had 3 bugs and so tackled the issue by re-factoring this structure. A suggestion (which I hope made it into bugzilla) was made last week to put a simple echo "please use the /sbin/ .. " command now when attempting to run /etc/init.d/rhn-satellite. Do you see something 'bad' in this? Or just wondering about why? I don't see it as a bad change, if bugs were fixed then this is a good thing. Monitoring scripts and clustering applications will have to change. Also, /sbin is not a typical location for init scripts. That is why I was curious. Why can't this can't be dealt with by multiple-init scripts with dependencies? I don't like the idea of init.d scripts that don't have a function being installed by an RPM either. --Michael Actually for some reason this seems to scream out LSB violation, but its probably on the lines of "Well it it ain't, it darn well should be." Most of the bigger software I see has something like: /etc/init.d/XYZ-overlord /etc/init.d/XYZ-squid /etc/init.d/XYZ-sendmail /etc/init.d/XYZ-virusscanner etc.. You run overlord to recycle the whole thing (it runs the smaller ones..) but it runs the single ones by themselves. good point: LSB headers don't exist for EL 4/5, though we should have them in there so they are also available in Fedora. Either way, if tools that manipulate services continue to work, that's desirable :) (Aside -- this list isn't set up to Reply-To-List. It should be. Can this please be fixed to be consistent with other lists? You're probably getting some off-list traffic as a result) It probably could be, and luckily, you can do it yourself as the admin: Spacewalk-devel list run by mdehaan at redhat.com, jesusr at redhat.com, mmccune at redhat.com same is true of Spacewalk-list. Forgot I set this up. doh! I'll do this :) --Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFJGKORhwQhj8l1t/cRAkNIAKCFq+qT4xf9GgePBsJXqT4vN97J0ACeM3el pixObMYHyFwz/WVP/z/oj+o= =Hkpy -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Announcing Spacewalk 0.3
Stephen John Smoogen wrote: On Mon, Nov 10, 2008 at 1:53 PM, Michael DeHaan <[EMAIL PROTECTED]> wrote: Vladimir Zlatkin wrote: Clifford Perry wrote: Vladimir Zlatkin wrote: Jesus M. Rodriguez wrote: * rhn-satellite is no longer in /etc/init.d, use /sbin/rhn-satellite to start/stop the entire satellite. I am curious, what is the motivation for this change? Various levels of breakage in having on chkconfig style script owning multiple daemons. Move to a more per daemon init script and have /sbin/ command to stop/start them all at once if needed once booted up. Allow for the daemons to start cleanly also when switching run levels. Michael Mraka had 3 bugs and so tackled the issue by re-factoring this structure. A suggestion (which I hope made it into bugzilla) was made last week to put a simple echo "please use the /sbin/ .. " command now when attempting to run /etc/init.d/rhn-satellite. Do you see something 'bad' in this? Or just wondering about why? I don't see it as a bad change, if bugs were fixed then this is a good thing. Monitoring scripts and clustering applications will have to change. Also, /sbin is not a typical location for init scripts. That is why I was curious. Why can't this can't be dealt with by multiple-init scripts with dependencies? I don't like the idea of init.d scripts that don't have a function being installed by an RPM either. --Michael Actually for some reason this seems to scream out LSB violation, but its probably on the lines of "Well it it ain't, it darn well should be." Most of the bigger software I see has something like: /etc/init.d/XYZ-overlord /etc/init.d/XYZ-squid /etc/init.d/XYZ-sendmail /etc/init.d/XYZ-virusscanner etc.. You run overlord to recycle the whole thing (it runs the smaller ones..) but it runs the single ones by themselves. good point: LSB headers don't exist for EL 4/5, though we should have them in there so they are also available in Fedora. Either way, if tools that manipulate services continue to work, that's desirable :) (Aside -- this list isn't set up to Reply-To-List. It should be. Can this please be fixed to be consistent with other lists? You're probably getting some off-list traffic as a result) --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Announcing Spacewalk 0.3
Vladimir Zlatkin wrote: Clifford Perry wrote: Vladimir Zlatkin wrote: Jesus M. Rodriguez wrote: * rhn-satellite is no longer in /etc/init.d, use /sbin/rhn-satellite to start/stop the entire satellite. I am curious, what is the motivation for this change? Various levels of breakage in having on chkconfig style script owning multiple daemons. Move to a more per daemon init script and have /sbin/ command to stop/start them all at once if needed once booted up. Allow for the daemons to start cleanly also when switching run levels. Michael Mraka had 3 bugs and so tackled the issue by re-factoring this structure. A suggestion (which I hope made it into bugzilla) was made last week to put a simple echo "please use the /sbin/ .. " command now when attempting to run /etc/init.d/rhn-satellite. Do you see something 'bad' in this? Or just wondering about why? I don't see it as a bad change, if bugs were fixed then this is a good thing. Monitoring scripts and clustering applications will have to change. Also, /sbin is not a typical location for init scripts. That is why I was curious. Why can't this can't be dealt with by multiple-init scripts with dependencies? I don't like the idea of init.d scripts that don't have a function being installed by an RPM either. --Michael ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
