Cobbler web upgrades! Now fields have expandable/collapsable sections, feedback?
by Michael DeHaan
I've just added "sections" (sort of like tabs) to the web interface.
This is nice.
For instance, in the systems view, you have fields grouped by "General",
"Advanced", "Networking (Global)", "Networking", "Management", and so
on. "General" expands by default, and the others you can click on to
expand ... and you can collapse any ones you don't want to look at.
This is all controlled by the backend code, so someone doesn't need to
be a web developer to add a field -- it just works.
Visually, tThis is a /lot/ cleaner than the previous color coding and
should help to minimize scrolling. It's less overwhelming because you
know this setting isn't important to you if it's in Advanced, or that if
you are looking for this setting it's going to be in this section.
In addition, you can expand or collapse the sections on the left hand
menu and these follow a similar color scheme.
This is where I could really use a bit of help though -- my CSS isn't
looking all that bad, but it could be a lot better.
Anyone want to make Cobbler web look a bit more professional?
By reusing the orange we have in the logo, it sort of looks like a giant
pumpkin or perhaps a web page about Creamsicles. Surely you don't want
that, right? <LOL>. Yeah, I don't even like orange myself. It must
go :) If you leave it to me it will all end up red and white with
wolves on it, so I'm not sure you want that either :)
Anyway, take a look at let me know what you think. I'm sure there are
folks that can drop some more CSS love onto it, and probably also some
other neat jQuery tips and tricks.
(The existing "sections" are jQuery powered, and we're already using
jsgrowl for notifications... so no reason we can't do even more with
jQuery, whatever anyone would like to do/try, basically, is fair game).
Feedback welcome!
--Michael
14 years, 8 months
How long to keep task logs around by default (logrotate)?
by Michael DeHaan
I've set the cobblerd_rotate script to whack files from
/var/log/cobbler/tasks after 10 days.
I'm not sure this is ideal, but seems ok.
I'm also really not sure there would be a problem with making it 30 or
more, but I'm also not sure anyone
wants to see any of those logs after 5 days either.
So 10 is the number right now, unless folks think we need something
different. User editable later, of course.
--Michael
14 years, 9 months
Cobbler web login page ... what to do with it / other webapp thoughts?
by Michael DeHaan
The blank page you get when first visiting Cobbler Web isn't very
functional. It just shows the Cobbler version.
Thoughts of what to do with it?
We could just display the events list there, though I'm not sure how
useful that would be because the events
list only shows events since cobblerd started....
(Thinking about this we should also be making events show up for
user-initiated edits to objects, either through the CLI or the web
app. This could easily just track save_object type calls.)
What else would be good to use there?
Is there anything major/missing from the web app for general day to day
cobbler usage now that we've added import, sync, reposync, hardlink,
replicate (to some extent), check, and buildiso?
Perhaps we could do more of a wizard view for replicate and buildiso, to
ask the right questions, though I'm not sure that's right or not... or
if that even belongs in the web app since, I think, replicate is going
to be something we /really/ want done on periodic cron.
Thoughts on what to do with this page and future webapp features welcome.
(I know we never did the integration with other sys mgmt webapps thing
yet -- possibly saving that for a later release, mostly talking about
how to best surface and make use of cobbler's present core now)
--Michael
14 years, 9 months
[PATCH] re-add system power commands to cli
by Vreman, Peter
Attached patchs add system power to the CLI and fixes power from Web.
Peter
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
14 years, 9 months
The TODO file
by Michael DeHaan
The TODO file in git contains the things we need to do before releasing
2.0... I will update it as we think of things or finish them.
Currently these items are:
- HIGH PRIORITY:
- Test interfaces in CLI and webapp thoroughly
- make authz_ownership work for all of the new commands (require admin
group?)
- MODERATE PRIORITY:
- Look over old webapp and ensure tooltips in new version are good
enough or better
- Look for missing fields in CLI/webapp
- Replicate improvements
- yum SHA knowledge for F12 from older OS (reposync/import)
- dhcp.conf config path default change for F11 (F12?)
- reinstate reports with formatted output options
14 years, 9 months
Re: [PATCH] Cobbler buildiso ksdevice support
by Simon Woolsgrove
--- mdehaan(a)redhat.com wrote:
From: Michael DeHaan <mdehaan(a)redhat.com>
To: simon(a)woolsgrove.com, cobbler development list <cobbler-devel(a)lists.fedorahosted.org>
Subject: Re: [PATCH] Cobbler buildiso ksdevice support
Date: Mon, 27 Jul 2009 14:25:31 -0400
On 07/27/2009 01:01 PM, Simon Woolsgrove wrote:
> Apologies if I have coded this real bad, still getting head around the cobbler, so let me know if there is a better way to do this.
>
> This patch is to support adding the correct static ip entries when cobbler buildiso is used for systems, currently it just looks at eth0 even if ksdevice=vmnic?, eth? or mac address other than eth0. I have just done this against the 1.6 base, but can also do master if this is any good.
>
> Cheers,
> Simon
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> cobbler-devel mailing list
> cobbler-devel(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/cobbler-devel
>
> Patch needs to be applied against master.
> Also, implementation wise, it would be better to do something like
> (caution: pseudocode-ish typing my thoughts, may not 100% compile
>directly):
>blended = utils.blender(api_handle, object_root, False) # don't
>collapse to strings
>ksdevice = blended.get("ksdevice")
>if obj.interfaces.has_key(ksdevice):
> primary_interface = ksdevice
>Right? That seems to pick primary_interface a bit faster.
Thanks for the pointer here is patch against master using the un-collapsed data.
Cheers,
Simon
14 years, 9 months
task log filename not unique
by Vreman, Peter
The log file of the tasks is not unique. After a restart of cobblerd the log file starts always with 0.log.
A timestamp in the name (just like on the webui screen) or persistent number shall be used for the filename.
Peter
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
14 years, 9 months
Removing rhpl dependencies
by Michael DeHaan
This email to Fedora devel indicates some changes we're going to need to
make to registration/discovery features (i..e cobbler-register):
== snip ==
We're hoping to be able to not ship rhpl for Fedora 12 -- this isn't
something which is really a "feature", but it might be something that a
heads up is useful for. Anyone who has a package with a dependency on
rhpl should have a bug filed, 98% of them with patches, to switch to
using something else.
If you are using rhpl and*don't* have a Requires: rhpl in your spec
file (or are using it for something not in Fedora), here's the
replacements for the things which were commonly used
* rhpl.translate -> Use python's gettext module. It's a lot more
functional these days. rhpl.translate was a good idea 7 years ago,
but not anymore:)
* rhpl.ethtool -> python-ethtool provides a module with similar/the same
API
* rhpl.exception -> Chris Lumens has split out a new package python-meh
which includes the exception handling capabilities from rhpl with the
added support for filing to bugzilla like anaconda does
* rhpl.keyboard* -> these now live in system-config-keyboard
Jeremy
== snip ==
So moving to python-ethtool, basically, is where we will need to go. This should probably be done for the 2.0 release since we are also fixing old-OS imports of Fedora 12 at the same time.
14 years, 9 months
Background subprocess creation creates duplicate tcp listeners
by Vreman, Peter
There is an error with calling sub processes in the background threads. For example doing a background sync (with DHCP/DNS restart) results in the TCP port being listened on by multiple processes. The end result is that the cobblerd service can't be restarted:
bcsia79# lsof -i | grep 25151
cobblerd 12925 root 27u IPv4 9697514 TCP localhost.intinfra.com:25151 (LISTEN)
dhcpd 12963 root 27u IPv4 9697514 TCP localhost.intinfra.com:25151 (LISTEN)
named 12998 named 27u IPv4 9697514 TCP localhost.intinfra.com:25151 (LISTEN)
Stopping cobbler daemon: [ OK ]
Starting cobbler daemon: Traceback (most recent call last):
File "/usr/bin/cobblerd", line 91, in main
app.core(api)
File "/usr/lib/python2.4/site-packages/cobbler/cobblerd.py", line 51, in core
do_xmlrpc_tasks(bootapi, settings, xmlrpc_port)
File "/usr/lib/python2.4/site-packages/cobbler/cobblerd.py", line 69, in do_xmlrpc_tasks
do_xmlrpc_rw(bootapi, settings, xmlrpc_port)
File "/usr/lib/python2.4/site-packages/cobbler/cobblerd.py", line 108, in do_xmlrpc_rw
server = remote.CobblerXMLRPCServer(('127.0.0.1', port))
File "/usr/lib/python2.4/site-packages/cobbler/remote.py", line 1664, in __init__
SimpleXMLRPCServer.SimpleXMLRPCServer.__init__(self,args)
File "/usr/lib64/python2.4/SimpleXMLRPCServer.py", line 473, in __init__
SocketServer.TCPServer.__init__(self, addr, requestHandler)
File "/usr/lib64/python2.4/SocketServer.py", line 330, in __init__
self.server_bind()
File "/usr/lib64/python2.4/SocketServer.py", line 341, in server_bind
self.socket.bind(self.server_address)
File "<string>", line 1, in bind
error: (98, 'Address already in use')
[ OK ]
bcsia79#
Regards,
Peter
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
14 years, 9 months
Master branch CLI ready for testing, fire in the hole?
by Michael DeHaan
All operations that I can think of currently remoted, and it should
mostly be working as normal except for a few minor options.
Things like "--in-place" doesn't work currently. I intend to fix this.
"--clobber" doesn't work. I intend to fix this too :)
Things like "--no-triggers" on object additions don't work and there was
another similar option like this... I'm not sure they serve a purpose,
and am not thinking of adding those back. I think I want to force the
trigger execution.
A minor quirk, on import "--mirror" is no longer an alias for
"--path". Just some internals streamlining, we will edit the docs to
reflect this (and any other changes, that might have happened)
Should be good to go.
Please try out the codebase and let me know what works and does not.
I'm going to give a little bit of final polish on the CLI, see what I
forgot to do, and then start devoting some more attention to webapp cleanup.
(What's final polish on the CLI? Making things like normal exceptions
not give stack traces, etc ... I also have some internal refinements to
make on how tasks are logged and when logfiles are cleaned up for
tasks... which is currently not handled ... and I want to support being
able to load username/password from a file and being able to specify a
differnet XMLRPC endpoint so it works with remote servers... and that
requires, I think writing a function to check remote task log status
since we can't automagically tail those logs... should be easy enough!)
(I really want to, for instance, get some better tab layout going for
keeping fields in different categories together. I think that would
make it a lot more usable
and limit scrolling)
Through all of this, XMLRPC API remains compatible. The Cobbler python
API does *not* neccessarily remain compatible, so external apps, as I
said before, need to use the XMLRPC API. If you want to use it, you
can, but some changes were neccessary. On the XMLRPC side, lots of
new functions for launching background tasks for all long-running ops,
so that's great.
Comments welcome.
--Michael
14 years, 9 months