Hi Damien,
I think the first key is a generated key special for this kickstarted system.
Just as if you would like to "reactivate" a client. But I did not yet use koan
so I actually don't really know.
Regards
Robert
Am 25.02.2016 23:32 schrieb Damien Daco :
>
> Hi list :)
>
> I've got a small p
Hi list :)
I've got a small problem with my activation key when kickstarting virtual
machines.
My key, and only key, is called "1-centos6-x64". I only have that key, and
it's universal.
However, when I provision VMs with koan, the clients automatically register
to spacewalk, but they aren't prop
Robert,
I did not think starting time of the daemon can count as start point
and wonder if its actually a true . In our case rhnsd daemon starts when
VM starts so they start randomly . But if 100 VMs was going to start around
the same time then that might count as those rhnsd daemons will co
You assume, that every server started rhnsd at the same time... Or on the same
minute within an hour. As long as you don't start or restart rhnsd via cron,
this shouldn't happen.
If you're using osad, and schedule a task for all servers to start "as soon as
possible", you'll might get in troubl
Hello,
I am trying to understand better how rhnsd works and since I have plans
to connect about thousand clients. With current 200 clients all have
interval set to 60 minutes which is recommended minimal pooling time.
So when I schedule a task not all clients contact spacewalk server at the
Hi,
nobody for helping me?
Please ;).
--
Lionel
- Mail original -
De: "Lionel Caignec"
À: "spacewalk-list"
Envoyé: Mercredi 24 Février 2016 10:14:34
Objet: [Spacewalk-list] Fresh install Taskomatic does not start automatically
Hello,
i'm new with spacewalk and i have a little proble
Seems like we hit the same problem too. I've created a PR with a
backport:
https://github.com/spacewalkproject/spacewalk/pull/353
Regards,
F.
On Thu, 25 Feb 2016 15:41:27 +0100
Frantisek Kobzik wrote:
> Hello,
>
> the problem is most likely caused by long changelog in those rpms.
> IIUC spacew
Hello,
the problem is most likely caused by long changelog in those rpms.
IIUC spacewalk stores the changelogs in the DB, but there's limit.
Longer changelogs get truncated and if the truncation happens in the
middle of a UTF character, we get to this fishy situation.
I'll try to find out more.
Do not forget to recreate the sqlite sm db by doing :
sudo -u jabber sqlite3 /var/lib/jabberd/db/sqlite.db <
/usr/share/jabberd/db-setup.sqlite
This is forgotten in many documentations but mandatory (unless using another
storage)
De : spacewalk-list-boun...@redhat.com
[mailto:spacewa
Hi,
i tried this workaround and it seems to work.
https://bugzilla.redhat.com/show_bug.cgi?id=1222868
in etc/crontab I call once a day this command to reset the jabbed db, now with
a short sleep before starting osa-dispatcher.
service jabberd stop
service osa-dispatcher stop
rm -Rf /var/lib/jab
On 19.2.2016 07:31 Haupt, Torsten wrote:
Hello,
I added the repositories of openSUSE Leap 42.1 into my spacewalk 2.4
installation. The synchronization worked at the beginning, but now I get errors
and the repository is not synchronized.
spacewalk-repo-sync -c opensuse-leap-42.1-x86_64
===
11 matches
Mail list logo