date:20190222

Re: [Spacewalk-list] xmlrpclib.ProtocolError issue with spacewalk-manage-channel-lifecycle

2019-02-22 Thread p.cook...@bham.ac.uk

Hi Jérôme

If you've never modified the default Java memory settings, for Taskomatic, or 
Tomcat memory settings it's possibly running out of memory and task is 
crashing. This is a known issue, particularly when you sync large repos etc. 
See following link for more info:

https://docs.oracle.com/cd/E92593_01/E90695/html/swk24-issues-memory.html


You can see what Taskomatic is currently using by checking status:

# systemctl status taskomatic.service

● taskomatic.service - Taskomatic
   Loaded: loaded (/usr/lib/systemd/system/taskomatic.service; enabled; vendor 
preset: disabled)
   Active: active (running) since Wed 2019-02-20 14:18:56 GMT; 1 day 23h ago
  Process: 46068 ExecStop=/usr/sbin/taskomatic stop (code=exited, 
status=0/SUCCESS)
  Process: 49351 ExecStart=/usr/sbin/taskomatic start (code=exited, 
status=0/SUCCESS)
 Main PID: 49377 (taskomaticd)
   CGroup: /system.slice/taskomatic.service
   ├─49377 /usr/bin/taskomaticd 
/usr/share/rhn/config-defaults/rhn_taskomatic_daemon.conf 
wrapper.pidfile=/var/run//taskomatic.pid wrapper.daemonize=TRUE
   └─49383 /usr/bin/java -Dibm.dst.compatibility=true 
-Dfile.encoding=UTF-8 -Xms256m -Xmx1024m 
-Djava.library.path=/usr/lib:/usr/lib64:/usr/lib/oracle/11.2/client64/lib:/usr/lib/oracle/11.2/client/lib
 -classpath /usr/share/jav...

Feb 20 14:18:56  systemd[1]: Starting Taskomatic...
Feb 20 14:18:56  taskomatic[49351]: Starting RHN Taskomatic...
Feb 20 14:18:56  wrapper[49377]: --> Wrapper Started as Daemon
Feb 20 14:18:56  wrapper[49377]: Launching a JVM...
Feb 20 14:18:56  systemd[1]: Started Taskomatic.
#

After changing the memory size you'll need to re-start Taskomatic.

Regards
Phil

-Original Message-
From: spacewalk-list-boun...@redhat.com  On 
Behalf Of jerome.me...@lcsystems.ch
Sent: 20 February 2019 10:20
To: 'Robert Paschedag' ; spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] xmlrpclib.ProtocolError issue with 
spacewalk-manage-channel-lifecycle

Hi Robert,

Thanks for your quick reply.
It is good to know that isn't a application's issue ;) Do you know if there's a 
possibility to tune the DB to avoid this problem? Actually I've the SW 2.8

Best regards,
Jérôme




-Original Message-
From: Robert Paschedag [mailto:robert.pasche...@web.de]
Sent: Dienstag, 19. Februar 2019 18:31
To: spacewalk-list@redhat.com; Jérôme Meyer; 'spacewalk-list@redhat.com'
Subject: Re: [Spacewalk-list] xmlrpclib.ProtocolError issue with 
spacewalk-manage-channel-lifecycle

Am 19. Februar 2019 16:44:24 MEZ schrieb "Jérôme Meyer" 
:
>Hi Everyone,
>
>I'm using the spacewalk-manage-channel-lifecycle to manage my 
>spacewalk's channel.
>
>Sometimes when I run this command, I've received this following error 
>on epel channel but not on any other channel.
>At the end I've runned with channel exclusion (-x
>dev-epel7-centos7-x86_64) and all was fine but it isn't the solution...
>
>
>1)  In this case I just started the command a second time. This is the 
>reason why there is no package.
>
>2)  The only difference I see between the epel channel and the others 
>is that there are a lot of packets to transfert.
>
>
># spacewalk-manage-channel-lifecycle -c dev-centos7-x86_64 --promote
>INFO: Merging packages from dev-centos7-x86_64 into test-centos7-x86_64
>INFO: Added 0 packages
>INFO: Merging errata into test-centos7-x86_64
>INFO: Added 0 errata
>
>INFO: Merging packages from dev-centos7-x86_64-centosplus into 
>test-centos7-x86_64-centosplus
>INFO: Added 0 packages
>INFO: Merging errata into test-centos7-x86_64-centosplus
>INFO: Added 0 errata
>
>INFO: Merging packages from dev-centos7-x86_64-extras into 
>test-centos7-x86_64-extras
>INFO: Added 0 packages
>INFO: Merging errata into test-centos7-x86_64-extras
>INFO: Added 0 errata
>
>[...]
>
>INFO: Merging packages from dev-epel7-centos7-x86_64 into
>test-epel7-centos7-x86_64
>Traceback (most recent call last):
>  File "/bin/spacewalk-manage-channel-lifecycle", line 575, in 
>merge_channels(child_source, child_dest) File 
>"/bin/spacewalk-manage-channel-lifecycle", line 213, in merge_channels
>dest_label)
>  File "/usr/lib64/python2.7/xmlrpclib.py", line 1233, in __call__
>return self.__send(self.__name, args)
>  File "/usr/lib64/python2.7/xmlrpclib.py", line 1591, in __request
>verbose=self.__verbose
>  File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request
>return self.single_request(host, handler, request_body, verbose) 
>File "/usr/lib64/python2.7/xmlrpclib.py", line 1321, in single_request
>response.msg,
>xmlrpclib.ProtocolError: chlxintmgmtp01.weforum.local/rpc/api: 500 Internal Server Error>

What I could think of, is that there are too many transaction going onto the 
database and it just takes too long so you get that 500 error.

Had this when I was to clean (and archive) finished actions. Had to do this in 
steps Otherwise I got an 500 error. But that was somewhere in SW 2.7 I think.

Robert

>
>
>Has anyone ever had this problem before?
>A

Re: [Spacewalk-list] Sequences going wrong

2019-02-22 Thread Thomas Schweikle

On 15.02.2019 18:19, Robert Paschedag wrote:
> Am 15. Februar 2019 09:28:26 MEZ schrieb Thomas Schweikle 
> :
>> On 14.02.2019 12:09, 
>> p.cookson-mhdz94l+r7k1qrn1bg8bzw-xmd5yjdbdmrexy1tmh2...@public.gmane.org
>> wrote:
>>> Hi Thomas
>>>
>>> The "Internal Server Error" appears to be a really generic and
>> un-helpful message that comes out of Spacewalk in all sorts of
>> scenario's! I haven't experienced your particular problem but, in the
>> past, I've been advised to look at " /var/log/tomcat/catalina.out" to
>> try and get a better idea of what the issue is. Don't know if this will
>> help on this occasion?
>>
>> No, this was not helpful in this occasion. I'd need some way to make
>> spacewalk deliver what error was created, by taking logs from
>> /var/log/tomcat/catalina.out,
>> /var/lib/pgsql/11/data/log/postgres-*.log.
>>
>> It would be really helpful spacewalk pushing the error logs to the web
>> interface for debugging such cases!
>>
>>>
>>> Regards
>>> Phil
>>>
>>> -Original Message-
>>> From: 
>>> spacewalk-list-bounces-h+wxahxf7alqt0dzr+alfa-xmd5yjdbdmrexy1tmh2...@public.gmane.org
>> 
>>  On
>> Behalf Of 
>> tschweikle-re5jqeeqqe8avxtiumwx3w-xmd5yjdbdmrexy1tmh2...@public.gmane.org
>>> Sent: 14 February 2019 10:31
>>> To: spacewalk
>> 
>>> Subject: [Spacewalk-list] Sequences going wrong
>>>
>>> Hi!
>>>
>>> We're having a lot of troubble with spacewalk loosing sequences, or
>>> better: loosing sync within sequences. As spacewalk runs all looks ok
>> for some time. then you may get "Internal server error" at a variety of
>> places. Mostly it starts showing up in "Schedule -> Actions" click on
>> one of the numbers behind in columns Finished, Failed, Pending.
>>> Instead of showing me details on where the action hav finished,
>> failed or is pending I am prompted with "Internal server error".
>>>
>>> Looking into the sql-logs I can find sequences out of sync. Fixing
>> these manually makes it work again -- for some time. I do not have any
>> idea why these sequences starting to get out of sync. Any idea? Bug?
>>>
>>> Spacewalk 2.9
>>> OS: CentOS 7
>>>
>>> --
>>> Thomas
>>>
>>> ___
>>> Spacewalk-list mailing list
>>> spacewalk-list-h+wxahxf7alqt0dzr+alfa-xmd5yjdbdmrexy1tmh2...@public.gmane.org
>>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>>
> 
> Well... You can look into the stack traces at which file (and line) the error 
> occurred. Clone the spacewalk git repo, checkout your version "branch" and 
> look at the code.

That is what I am trying at the moment. BUT and its a really BIG BUT:
there some stack traces. And I need to have it related to what is going
on after I click some link. The way Spacewalk does it now I cant. I cant
relate a click to an error. Impossible. Absolutely impossible. Just
because the error does not show up with a fresh installation and three
clients. It shows up with 200 clients and a running, productive system.

I need Spacewalk to handle the traces thru to WebUI. How can I advice
tomcat to do this: write an error message, then write the full trace
right beyond.

This is the third time the database being corrupted this way. I DO NOT
want to start all over, taking about 400 clients, 800 configs copied by
cut and past to a new spacewalk to have the database corrupted 4th time
then WITHOUT ever finding what was the core cause!

-- 
Thomas

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

2019-02-22 Thread p.cook...@bham.ac.uk

Hi Harald

I have Spacewalk 2.8 installed on a RHEL 7 server. I only need to register RHEL 
6/7 and Oracle Linux 6/7 systems, rather than Centos, so this may possibly be 
why I’m not seeing your issue?

However, if rhnsd has been installed, correctly, it should start automatically 
and /etc/sysconfig/rhn/rhnsd should be present too - /etc/sysconfig/rhn/rhnsd 
comes from the rhnsd package:

# rpm -qf /etc/sysconfig/rhn/rhnsd
rhnsd-5.0.37-1.el7.centos.x86_64
#

Therefore, it may be wise to check the steps you took to register the client 
systems and/or verify the package:

[root@its-n-swcli-01 ~]# rpm -V rhnsd
[root@its-n-swcli-01 ~]#

Regards
Phil



From: spacewalk-list-boun...@redhat.com  On 
Behalf Of harald.wacha...@akm.at
Sent: 19 February 2019 08:32
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

Phil,

Still a problem with the offline clients.
It looks like that the rhn daemon stops working after some time.

Redirecting to /bin/systemctl status  rhnsd.service
● rhnsd.service - Spacewalk Server daemon
   Loaded: loaded (/usr/lib/systemd/system/rhnsd.service; static; vendor 
preset: disabled)
   Active: inactive (dead)



And some more:

I have no /etc/sysconfig/rhn/rhnsd

[root@vie-srv-XXX log]# cd /etc/sysconfig/rhn/
[root@vie-srv-XXX rhn]# ls -la
total 24
drwxr-xr-x. 4 root root 4096 Feb 19 09:18 .
drwxr-xr-x. 7 root root 4096 Jan 23 16:48 ..
drwxr-xr-x. 4 root root   37 Jan 23 16:48 allowed-actions
drwxr-xr-x. 2 root root   37 Feb 14 12:19 clientCaps.d
-rw---. 1 root root  129 Jan 29 16:48 osad-auth.conf.rpmsave
-rw-r--r--. 1 root root 1446 Nov 26 21:50 rhncfg-client.conf
-rw---. 1 root root 1321 Jan 23 16:51 systemid
-rw-r--r--. 1 root root 1948 Jan 23 16:51 up2date

In the rhncfg-client.conf I can find a log directory: script_log_file = 
/var/log/rhn/rhncfg-action-output.log

But even this log file does not exist……


Warm regards,

Harald


Von: 
spacewalk-list-boun...@redhat.com 
mailto:spacewalk-list-boun...@redhat.com>> 
Im Auftrag von p.cook...@bham.ac.uk
Gesendet: Donnerstag, 14. Februar 2019 14:46
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

No problem Harald. If you want to continue using rhnsd you can still reduce the 
check-in time in /etc/sysconfig/rhn/rhnsd if you want though (default is 240 
mins):

# cat /etc/sysconfig/rhn/rhnsd
INTERVAL=240
#

Regards
Phil

From: 
spacewalk-list-boun...@redhat.com 
mailto:spacewalk-list-boun...@redhat.com>> 
On Behalf Of harald.wacha...@akm.at
Sent: 14 February 2019 11:18
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

Hi Phil,

Thanks for your reply.
It looks like it was a rookie mistake.
I am new at Spacewalk and I followed the instructions here to register a client.

https://github.com/spacewalkproject/spacewalk/wiki/RegisteringClients

Unfortunately there was no hint that you have to start the rhnsd service.
So I have started the service now and configured it to start automatically.
And I need no osad at the moment. Every 4 hours check in is fine for me.

Thanks again,

Warm regards,

Harald






Von: 
spacewalk-list-boun...@redhat.com 
mailto:spacewalk-list-boun...@redhat.com>> 
Im Auftrag von p.cook...@bham.ac.uk
Gesendet: Donnerstag, 14. Februar 2019 10:01
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

Hi Harald

Were they ok originally, and stopped working properly, or are you just trying 
to setup OSAD for the first time? Either way if you work through my personal 
notes (for OSAD), below, it may help to identify your problem. If everything 
has been done correctly it may be an infrastructure problem though ie 
un-reliable network connection or NTP?

By default, the rhnsd daemon on a client system connects to the Spacewalk 
server every four hours (see /etc/sysconfig/rhn/rhnsd) and performs any updates 
or actions that have been scheduled. If you install the OSA daemon, you can 
apply updates and actions to client systems immediately from the Spacewalk 
server.

osa-dispatcher
Server-side service that determines when an osad client instance needs to be 
pinged or run rhn_check and sends a message telling them to do so. This is 
installed when Spacewalk is installed.

Open Source Architecture Daemon (OSAD)
Client-side service that responds to pings and runs rhn_check when told to by 
osa-dispatcher.

See official documentation, at the following link, for more details:

https://github.com/spacewalkproject/spacewalk/wiki/OSADSetup

Install OSAD and related RHN/Spacewalk packages
# yum -y install osad rhncfg rhncfg-actions rhncfg-client

[Spacewalk-list] Any tool available to check spacewalk-database for consistency?

2019-02-22 Thread Thomas Schweikle

Hi!

Is there any tool available to check spacewalk database for
consistency and for being complete (all tables having all columns
spacewalk awaits)?

-- 
Thomas

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] xmlrpclib.ProtocolError issue with spacewalk-manage-channel-lifecycle

2019-02-22 Thread Jérôme Meyer

Hi Robert,

Thanks for your quick reply.
It is good to know that isn't a application's issue ;)
Do you know if there's a possibility to tune the DB to avoid this problem? 
Actually I've the SW 2.8

Best regards,
Jérôme




-Original Message-
From: Robert Paschedag [mailto:robert.pasche...@web.de] 
Sent: Dienstag, 19. Februar 2019 18:31
To: spacewalk-list@redhat.com; Jérôme Meyer; 'spacewalk-list@redhat.com'
Subject: Re: [Spacewalk-list] xmlrpclib.ProtocolError issue with 
spacewalk-manage-channel-lifecycle

Am 19. Februar 2019 16:44:24 MEZ schrieb "Jérôme Meyer" 
:
>Hi Everyone,
>
>I'm using the spacewalk-manage-channel-lifecycle to manage my 
>spacewalk's channel.
>
>Sometimes when I run this command, I've received this following error 
>on epel channel but not on any other channel.
>At the end I've runned with channel exclusion (-x
>dev-epel7-centos7-x86_64) and all was fine but it isn't the solution...
>
>
>1)  In this case I just started the command a second time. This is the 
>reason why there is no package.
>
>2)  The only difference I see between the epel channel and the others 
>is that there are a lot of packets to transfert.
>
>
># spacewalk-manage-channel-lifecycle -c dev-centos7-x86_64 --promote
>INFO: Merging packages from dev-centos7-x86_64 into test-centos7-x86_64
>INFO: Added 0 packages
>INFO: Merging errata into test-centos7-x86_64
>INFO: Added 0 errata
>
>INFO: Merging packages from dev-centos7-x86_64-centosplus into 
>test-centos7-x86_64-centosplus
>INFO: Added 0 packages
>INFO: Merging errata into test-centos7-x86_64-centosplus
>INFO: Added 0 errata
>
>INFO: Merging packages from dev-centos7-x86_64-extras into 
>test-centos7-x86_64-extras
>INFO: Added 0 packages
>INFO: Merging errata into test-centos7-x86_64-extras
>INFO: Added 0 errata
>
>[...]
>
>INFO: Merging packages from dev-epel7-centos7-x86_64 into
>test-epel7-centos7-x86_64
>Traceback (most recent call last):
>  File "/bin/spacewalk-manage-channel-lifecycle", line 575, in 
>merge_channels(child_source, child_dest) File 
>"/bin/spacewalk-manage-channel-lifecycle", line 213, in merge_channels
>dest_label)
>  File "/usr/lib64/python2.7/xmlrpclib.py", line 1233, in __call__
>return self.__send(self.__name, args)
>  File "/usr/lib64/python2.7/xmlrpclib.py", line 1591, in __request
>verbose=self.__verbose
>  File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request
>return self.single_request(host, handler, request_body, verbose)  
>File "/usr/lib64/python2.7/xmlrpclib.py", line 1321, in single_request
>response.msg,
>xmlrpclib.ProtocolError: chlxintmgmtp01.weforum.local/rpc/api: 500 Internal Server Error>

What I could think of, is that there are too many transaction going onto the 
database and it just takes too long so you get that 500 error.

Had this when I was to clean (and archive) finished actions. Had to do this in 
steps Otherwise I got an 500 error. But that was somewhere in SW 2.7 I think.

Robert

>
>
>Has anyone ever had this problem before?
>A suggestion or an idea that could help me?
>
>Thanks and best regards,
>Jérôme


--
sent from my mobile device


smime.p7s
Description: S/MIME cryptographic signature
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] spacewalk 2.9 && never ending issue with ubuntu/debian clients

2019-02-22 Thread Florin Portase

On 2019-02-13 10:56, Florin Portase wrote:

> Hello, 
> 
> I just have upgraded the spacewalk server from 2.7 => 2.9. 
> 
> I have applied also the sql patch from 
> https://bugzilla.redhat.com/show_bug.cgi?id=1661347 
> 
> + upgraded the clients from : 
> 
> http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/
>  
> 
> Just to mention spacewalk 2.7 +  patches was working just fine for both 
> debian & ubuntu. 
> 
> Now, for ubuntu 16.05 I have over 100 packages marked as up-gradable( over 
> and over) 
> 
> ___
> 
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list

So, after digging through  SPW archive Dec '18 til Feb '19 finally I
come to something more acceptable: 

1. sync script for Ubuntu channels 

2. "spacewalk-add-debian-multiarch-header.py.NEW " took it from
"https://www.redhat.com/archives/spacewalk-list/2018-December/msg00017.html;


wget  -q
http://de.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/Packages.gz
 \
-O /tmp/Packages-xenial-main.gz && gunzip -f
/tmp/Packages-xenial-main.gz
wget  -q
http://cz.archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-amd64/Packages.gz
 \
-O /tmp/Packages-xenial-updates.gz  && gunzip -f
/tmp/Packages-xenial-updates.gz
wget  -q
http://cz.archive.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages.gz
\
-O /tmp/Packages-xenial-security.gz && gunzip -f
/tmp/Packages-xenial-security.gz

s=180
trap 'echo "Ctrl-C detected."' 2
for (( i=$s ; i>0; i--));
do
#printf '\rFinishing sync in: %2d seconds' $i; sleep 1
echo -ne  "\rFinishing sync in: $i seconds\033[0K";
sleep 1
done
echo -e "\nSync completed!"
trap 2
$_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
$_PKG_MAIN/Packages/tmp/Packages-xenial-main
$_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
$_PKG_UPD/Packages  /tmp/Packages-xenial-updates
$_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
$_PKG_SEC/Packages  /tmp/Packages-xenial-security
$_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
$_PKG_UNIV/Packages/tmp/Packages-xenial-universe

/bin/mv $_PKG_MAIN/Packages.new $_PKG_MAIN/Packages
/bin/mv $_PKG_SEC/Packages.new $_PKG_SEC/Packages
/bin/mv $_PKG_UPD/Packages.new $_PKG_UPD/Packages
/bin/mv $_PKG_UNIV/Packages.new $_PKG_UNIV/Packages

gzip < $_PKG_MAIN/Packages > $_PKG_MAIN/Packages.gz
gzip < $_PKG_UPD/Packages  > $_PKG_UPD/Packages.gz
gzip < $_PKG_SEC/Packages  > $_PKG_SEC/Packages.gz
gzip < $_PKG_UNIV/Packages > $_PKG_UNIV/Packages.gz

cd $_PKG_MAIN
$_BIN_PATH/secureApt.sh  xenial xenial-main
touch -r Packages.gz  Packages
cd $_PKG_UPD
$_BIN_PATH/secureApt.sh  xenial xenial-updates
touch -r Packages.gz  Packages
cd $_PKG_SEC
$_BIN_PATH/secureApt.sh  xenial xenial-security
touch -r Packages.gz  Packages 

So just to resume, SYNC =>OK, applying ALL missing headers =>OK, now the
packages that are showed as up-gradable dropped from ~120 to only 6 (  
base-files libbind9-140 libisc160 libisccc140 libisccfg140 liblwres141 )


~~BUT~~ 

Here I run into another problem, it seems taskomatic is generating
Package files over and over ( touch -r Packages.gz  Packages seems to
have no effect)

signature.asc
Description: OpenPGP digital signature
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

[Spacewalk-list] Disable downloading stock repos in CentOS

2019-02-22 Thread Paul Deveau

Hello,

I would like to disable the downloading of the stock repos like 
Centos-Base.repo and the rest They get in the way when I perform upgrades 
(unless I'm doing something wrong?) I usually move the repos to a different 
directory so that yum does not see them.

Thank you,

--
Paul Deveau
Analyste de systèmes principal|Senior Systems Analyst
Technologies de l’information|Information Technology
Université d’Ottawa|University of Ottawa
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

[Spacewalk-list] Spacewalk Mail Configuration

2019-02-22 Thread Elsever Sadigov


Hello,

I wonder if somebody know how to configure spacewalk email notifications 
work thru local mail server and not thru internet. Btw server is behind 
http-proxy


There is not to much information or manual about it

--
Best Regards,

Elsever Sadigov


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Disable downloading stock repos in CentOS

2019-02-22 Thread p.cook...@bham.ac.uk

Hi Paul

There are a few options to disable existing repo's really:


1.   Move existing related repo files to a different location (like you've 
described).

mkdir /root/Original_Repos
mv /etc/yum.repos.d/* /root/Original_Repos/
yum clean all and/or rm -rf /var/cache/yum


2.   Temporarily disable during update.

yum --disablerepo= update


3.   Permanently disable.

Change the value of "enabled=" from 1 to 0 in /etc/yum.repos.d/

Regards
Phil



From: spacewalk-list-boun...@redhat.com  On 
Behalf Of pdev...@uottawa.ca
Sent: 22 February 2019 12:52
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] Disable downloading stock repos in CentOS

Hello,

I would like to disable the downloading of the stock repos like 
Centos-Base.repo and the rest They get in the way when I perform upgrades 
(unless I'm doing something wrong?) I usually move the repos to a different 
directory so that yum does not see them.

Thank you,

--
Paul Deveau
Analyste de systèmes principal|Senior Systems Analyst
Technologies de l'information|Information Technology
Université d'Ottawa|University of Ottawa
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Getting an error when trying to delete a machine or doing a cobbler-sync

2019-02-22 Thread David Pendell

Anyone?

P.S. I've already checked this:
https://www.redhat.com/archives/spacewalk-list/2012-August/msg00271.html

On Thu, Feb 14, 2019 at 2:55 PM David Pendell  wrote:

> Hello.
>
> When trying to delete a system from the GUI, I get an error message to my
> email address. It's long so I'll post it in a pastebin.
>
> https://pastebin.com/ftkWw4mw
>
> This is rhn_taskomatic_daemon.log from my last restart.
>
> https://pastebin.com/sHG7Csp6
>
> I've looked at cobbler settings, cobbler check output, cobbler modules,
> etc.
> I've checked the rhn_taskomatic_daemon.log and apache, tomcat and cobbler
> logs.
> I changed the default cobbler password.
> I have enabled all ports, even the ones that I am not using and then
> disabled my firewall.
> I have searched the great oracle called Google for a couple of days and I
> haven't found a solution yet.
>
> I can't believe that I am the only person to have this problem and I
> really don't want to start from scratch.
>
> Suggestions?
>
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

2019-02-22 Thread p.cook...@bham.ac.uk

If /etc/sysconfig/rhn/rhnsd isn’t there then either rhnsd hasn’t installed 
correctly or, like you say, someone or something has removed it afterwards. If 
that’s the case may be other related files could be missing too? Either way if 
you verify the package (rpm -V rhnsd) it should give you some indication of 
this. If it does find errors then yes, initially, just try re-installing it.

Might be wise to check the other packages, that were installed for client 
registration, too:

rhn-client-tools
rhn-check
rhn-setup
m2crypto
yum-rhn-plugin

Regards
Phil


From: spacewalk-list-boun...@redhat.com  On 
Behalf Of whten...@up.com
Sent: 21 February 2019 00:22
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

If /etc/sysconfig/rhn/rhnsd is not there, then need to investigate the package 
rhnsd. I would try and reinstall the rpm, and check to see if the file is there.

If the file is not there:
What version of rhnsd is installed on the clients?
What files are being provided by the rpm?  rpm -ql rhnsd

If the file is there:
Wait. If it is no longer there after some time.
A mis-configured chef/puppet/automated action could be deleting the 
file vs creating or updating the file.


If it is still there, some other items to look at:
Someone could have accidentally deleted the file (oops).
There could a custom RPM that is being installed on the impacted 
systems that has a script which is deleting the file.

Thanks




From:Wachauer Harald 
mailto:harald.wacha...@akm.at>>
To:"spacewalk-list@redhat.com" 
mailto:spacewalk-list@redhat.com>>
Date:02/19/2019 02:33 AM
Subject:Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients
Sent by:
spacewalk-list-boun...@redhat.com




This email originated from outside of the company. Please use discretion if 
opening attachments or clicking on links.


Phil,

Still a problem with the offline clients.
It looks like that the rhn daemon stops working after some time.

Redirecting to /bin/systemctl status  rhnsd.service
● rhnsd.service - Spacewalk Server daemon
   Loaded: loaded (/usr/lib/systemd/system/rhnsd.service; static; vendor 
preset: disabled)
   Active: inactive (dead)



And some more:

I have no /etc/sysconfig/rhn/rhnsd

[root@vie-srv-XXX log]# cd /etc/sysconfig/rhn/
[root@vie-srv-XXX rhn]# ls -la
total 24
drwxr-xr-x. 4 root root 4096 Feb 19 09:18 .
drwxr-xr-x. 7 root root 4096 Jan 23 16:48 ..
drwxr-xr-x. 4 root root   37 Jan 23 16:48 allowed-actions
drwxr-xr-x. 2 root root   37 Feb 14 12:19 clientCaps.d
-rw---. 1 root root  129 Jan 29 16:48 osad-auth.conf.rpmsave
-rw-r--r--. 1 root root 1446 Nov 26 21:50 rhncfg-client.conf
-rw---. 1 root root 1321 Jan 23 16:51 systemid
-rw-r--r--. 1 root root 1948 Jan 23 16:51 up2date

In the rhncfg-client.conf I can find a log directory: script_log_file = 
/var/log/rhn/rhncfg-action-output.log

But even this log file does not exist……


Warm regards,

Harald


Von: 
spacewalk-list-boun...@redhat.com 
mailto:spacewalk-list-boun...@redhat.com>> 
Im Auftrag von p.cook...@bham.ac.uk
Gesendet: Donnerstag, 14. Februar 2019 14:46
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

No problem Harald. If you want to continue using rhnsd you can still reduce the 
check-in time in /etc/sysconfig/rhn/rhnsd if you want though (default is 240 
mins):

# cat /etc/sysconfig/rhn/rhnsd
INTERVAL=240
#

Regards
Phil

From: 
spacewalk-list-boun...@redhat.commailto:spacewalk-list-boun...@redhat.com>>
 On Behalf Of harald.wacha...@akm.at
Sent: 14 February 2019 11:18
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

Hi Phil,

Thanks for your reply.
It looks like it was a rookie mistake.
I am new at Spacewalk and I followed the instructions here to register a client.

https://github.com/spacewalkproject/spacewalk/wiki/RegisteringClients

Unfortunately there was no hint that you have to start the rhnsd service.
So I have started the service now and configured it to start automatically.
And I need no osad at the moment. Every 4 hours check in is fine for me.

Thanks again,

Warm regards,

Harald






Von: 
spacewalk-list-boun...@redhat.commailto:spacewalk-list-boun...@redhat.com>>
 Im Auftrag von p.cook...@bham.ac.uk
Gesendet: Donnerstag, 14. Februar 2019 10:01
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

Hi Harald

Were they ok originally, and stopped working properly, or are you

Re: [Spacewalk-list] centos mirror and setup in spacewalk

2019-02-22 Thread p.cook...@bham.ac.uk

Hi Vyas

Not sure which versions you're using but you could try the following:

CentOS7-base:  http://mirror.centos.org/centos/7/os/x86_64/
CentOS7-updates:   http://mirror.centos.org/centos/7/updates/x86_64/
CentOS7-extras:   http://mirror.centos.org/centos/7/extras/x86_64/

CentOS6-base:  http://mirror.centos.org/centos/6/os/x86_64/
CentOS6-updates:   http://mirror.centos.org/centos/6/updates/x86_64/
CentOS6-extras:   http://mirror.centos.org/centos/6/extras/x86_64/

Regards
Phil

From: spacewalk-list-boun...@redhat.com  On 
Behalf Of vyas.devagu...@inova.org
Sent: 21 February 2019 19:44
To: spacewalk-list@redhat.com
Cc: spacewalk-list-boun...@redhat.com
Subject: [Spacewalk-list] centos mirror and setup in spacewalk

HI ,

Do any one have the centos mirror list to setup In spacewalk server .



___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] spacewalk 2.9 && never ending issue with ubuntu/debian clients

2019-02-22 Thread Robert Paschedag

Am 22. Februar 2019 13:11:00 MEZ schrieb Florin Portase 
:
>On 2019-02-13 10:56, Florin Portase wrote:
>
>> Hello, 
>> 
>> I just have upgraded the spacewalk server from 2.7 => 2.9. 
>> 
>> I have applied also the sql patch from
>https://bugzilla.redhat.com/show_bug.cgi?id=1661347 
>> 
>> + upgraded the clients from : 
>> 
>>
>http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/
>
>> 
>> Just to mention spacewalk 2.7 +  patches was working just fine for
>both debian & ubuntu. 
>> 
>> Now, for ubuntu 16.05 I have over 100 packages marked as up-gradable(
>over and over) 
>> 
>> ___
>> 
>> Spacewalk-list mailing list
>> Spacewalk-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>So, after digging through  SPW archive Dec '18 til Feb '19 finally I
>come to something more acceptable: 
>
>1. sync script for Ubuntu channels 
>
>2. "spacewalk-add-debian-multiarch-header.py.NEW " took it from
>"https://www.redhat.com/archives/spacewalk-list/2018-December/msg00017.html;
>
>
>wget  -q
>http://de.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/Packages.gz
> \
>-O /tmp/Packages-xenial-main.gz && gunzip -f
>/tmp/Packages-xenial-main.gz
>wget  -q
>http://cz.archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-amd64/Packages.gz
> \
>-O /tmp/Packages-xenial-updates.gz  && gunzip -f
>/tmp/Packages-xenial-updates.gz
>wget  -q
>http://cz.archive.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages.gz
>\
>-O /tmp/Packages-xenial-security.gz && gunzip -f
>/tmp/Packages-xenial-security.gz
>
>s=180
>trap 'echo "Ctrl-C detected."' 2
>for (( i=$s ; i>0; i--));
>do
>#printf '\rFinishing sync in: %2d seconds' $i; sleep 1
>echo -ne  "\rFinishing sync in: $i seconds\033[0K";
>sleep 1
>done
>echo -e "\nSync completed!"
>trap 2
>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
>$_PKG_MAIN/Packages/tmp/Packages-xenial-main
>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
>$_PKG_UPD/Packages  /tmp/Packages-xenial-updates
>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
>$_PKG_SEC/Packages  /tmp/Packages-xenial-security
>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
>$_PKG_UNIV/Packages/tmp/Packages-xenial-universe
>
>/bin/mv $_PKG_MAIN/Packages.new $_PKG_MAIN/Packages
>/bin/mv $_PKG_SEC/Packages.new $_PKG_SEC/Packages
>/bin/mv $_PKG_UPD/Packages.new $_PKG_UPD/Packages
>/bin/mv $_PKG_UNIV/Packages.new $_PKG_UNIV/Packages
>
>gzip < $_PKG_MAIN/Packages > $_PKG_MAIN/Packages.gz
>gzip < $_PKG_UPD/Packages  > $_PKG_UPD/Packages.gz
>gzip < $_PKG_SEC/Packages  > $_PKG_SEC/Packages.gz
>gzip < $_PKG_UNIV/Packages > $_PKG_UNIV/Packages.gz
>
>cd $_PKG_MAIN
>$_BIN_PATH/secureApt.sh  xenial xenial-main
>touch -r Packages.gz  Packages
>cd $_PKG_UPD
>$_BIN_PATH/secureApt.sh  xenial xenial-updates
>touch -r Packages.gz  Packages
>cd $_PKG_SEC
>$_BIN_PATH/secureApt.sh  xenial xenial-security
>touch -r Packages.gz  Packages 
>
>So just to resume, SYNC =>OK, applying ALL missing headers =>OK, now
>the
>packages that are showed as up-gradable dropped from ~120 to only 6 (  
>base-files libbind9-140 libisc160 libisccc140 libisccfg140 liblwres141
>)
>
>
>~~BUT~~ 
>
>Here I run into another problem, it seems taskomatic is generating
>Package files over and over ( touch -r Packages.gz  Packages seems to
>have no effect)

This seems to be new. You might have to check within code, at which conditions 
a rebuild of the Packages file gets triggered 

I'm still on SW2.7 so I cannot test on my environment.

Robert



-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

[Spacewalk-list] Re; Any tool available to check spacewalk-database for consistency?

2019-02-22 Thread Paul-Andre Panon

Any tool available to check
On Mon, 18 Feb 2019 18:17:45,  Thomas Schweikle
 wrote:

>Hi!

>Is there any tool available to check spacewalk database for consistency
and for being complete (all >tables having all columns spacewalk awaits)?

>--
>Thomas

Well, if you're wondering about schema completeness, as long as you're
using Postgres, there's a number of free DB design tools that do round
trip engineering that you could try.
https://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools
Just build and initialize a fresh database for your version, then reverse
engineer it into a model, and compare that with your existing database.

--

Message: 2
Date: Tue, 19 Feb 2019 08:31:46 +
From: Wachauer Harald 
To: "spacewalk-list@redhat.com" 
Subject: Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients
Message-ID: <81cf184257e34220860596b44ad4f...@akm.at>
Content-Type: text/plain; charset="iso-2022-jp"

Phil,

Still a problem with the offline clients.
It looks like that the rhn daemon stops working after some time.

Redirecting to /bin/systemctl status  rhnsd.service
? rhnsd.service - Spacewalk Server daemon
   Loaded: loaded (/usr/lib/systemd/system/rhnsd.service; static; vendor
preset: disabled)
   Active: inactive (dead)

And some more:

I have no /etc/sysconfig/rhn/rhnsd

[root@vie-srv-XXX log]# cd /etc/sysconfig/rhn/
[root@vie-srv-XXX rhn]# ls -la
total 24
drwxr-xr-x. 4 root root 4096 Feb 19 09:18 .
drwxr-xr-x. 7 root root 4096 Jan 23 16:48 ..
drwxr-xr-x. 4 root root   37 Jan 23 16:48 allowed-actions
drwxr-xr-x. 2 root root   37 Feb 14 12:19 clientCaps.d
-rw---. 1 root root  129 Jan 29 16:48 osad-auth.conf.rpmsave
-rw-r--r--. 1 root root 1446 Nov 26 21:50 rhncfg-client.conf
-rw---. 1 root root 1321 Jan 23 16:51 systemid
-rw-r--r--. 1 root root 1948 Jan 23 16:51 up2date

In the rhncfg-client.conf I can find a log directory: script_log_file =
/var/log/rhn/rhncfg-action-output.log

But even this log file does not exist??

Warm regards,

Harald

Von: spacewalk-list-boun...@redhat.com 
Im Auftrag von p.cook...@bham.ac.uk
Gesendet: Donnerstag, 14. Februar 2019 14:46
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

No problem Harald. If you want to continue using rhnsd you can still
reduce the check-in time in /etc/sysconfig/rhn/rhnsd if you want though
(default is 240 mins):

# cat /etc/sysconfig/rhn/rhnsd
INTERVAL=240
#

Regards
Phil

From:
spacewalk-list-boun...@redhat.com
mailto:spacewalk-list-boun...@redhat.co
m>> On Behalf Of harald.wacha...@akm.at
Sent: 14 February 2019 11:18
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

Hi Phil,

Thanks for your reply.
It looks like it was a rookie mistake.
I am new at Spacewalk and I followed the instructions here to register a
client.

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_spacewalkp
roject_spacewalk_wiki_RegisteringClients=DwICAg=q3cDpHe1hF8lXU5EFjNM_A
=2sQoWEMcncSKL5kWoc_nrZbhUyhuj8tJfA91_lDSglQ=rQzksXP1uce_DHHtSiT7UWAMa
P4RBIR2nS2d3LXG-gs=ku28VreapnsJLj6Wwf44fezyLXxKiX67dzJdUcWKiCM=

Unfortunately there was no hint that you have to start the rhnsd service.
So I have started the service now and configured it to start
automatically.
And I need no osad at the moment. Every 4 hours check in is fine for me.

Thanks again,

Warm regards,

Harald

Von:
spacewalk-list-boun...@redhat.com
mailto:spacewalk-list-boun...@redhat.co
m>> Im Auftrag von p.cook...@bham.ac.uk
Gesendet: Donnerstag, 14. Februar 2019 10:01
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

Hi Harald

Were they ok originally, and stopped working properly, or are you just
trying to setup OSAD for the first time? Either way if you work through my
personal notes (for OSAD), below, it may help to identify your problem. If
everything has been done correctly it may be an infrastructure problem
though ie un-reliable network connection or NTP?

By default, the rhnsd daemon on a client system connects to the Spacewalk
server every four hours (see /etc/sysconfig/rhn/rhnsd) and performs any
updates or actions that have been scheduled. If you install the OSA
daemon, you can apply updates and actions to client systems immediately
from the Spacewalk server.

osa-dispatcher
Server-side service that determines when an osad client instance needs to
be pinged or run rhn_check and sends a message telling them to do so. This
is installed when Spacewalk is installed.

Open Source Architecture Daemon (OSAD)
Client-side service that responds to pings and runs rhn_check when told to
by osa-dispatcher.

See official documentation, at the following link, for more details:

Re: [Spacewalk-list] spacewalk 2.9 && never ending issue with ubuntu/debian clients

2019-02-22 Thread Robert Paschedag

On 2/22/19 7:53 PM, Robert Paschedag wrote:
> Am 22. Februar 2019 13:11:00 MEZ schrieb Florin Portase 
> :
>> On 2019-02-13 10:56, Florin Portase wrote:
>>
>>> Hello,
>>>
>>> I just have upgraded the spacewalk server from 2.7 => 2.9.
>>>
>>> I have applied also the sql patch from
>> https://bugzilla.redhat.com/show_bug.cgi?id=1661347
>>>
>>> + upgraded the clients from :
>>>
>>>
>> http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/
>>
>>>
>>> Just to mention spacewalk 2.7 +  patches was working just fine for
>> both debian & ubuntu.
>>>
>>> Now, for ubuntu 16.05 I have over 100 packages marked as up-gradable(
>> over and over)
>>>
>>> ___
>>>
>>> Spacewalk-list mailing list
>>> Spacewalk-list@redhat.com
>>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>
>> So, after digging through  SPW archive Dec '18 til Feb '19 finally I
>> come to something more acceptable:
>>
>> 1. sync script for Ubuntu channels
>>
>> 2. "spacewalk-add-debian-multiarch-header.py.NEW " took it from
>> "https://www.redhat.com/archives/spacewalk-list/2018-December/msg00017.html;
>>
>>
>> wget  -q
>> http://de.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/Packages.gz
>> \
>>-O /tmp/Packages-xenial-main.gz && gunzip -f
>> /tmp/Packages-xenial-main.gz
>> wget  -q
>> http://cz.archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-amd64/Packages.gz
>> \
>>-O /tmp/Packages-xenial-updates.gz  && gunzip -f
>> /tmp/Packages-xenial-updates.gz
>> wget  -q
>> http://cz.archive.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages.gz
>> \
>>-O /tmp/Packages-xenial-security.gz && gunzip -f
>> /tmp/Packages-xenial-security.gz
>>
>> s=180
>> trap 'echo "Ctrl-C detected."' 2
>> for (( i=$s ; i>0; i--));
>>do
>>#printf '\rFinishing sync in: %2d seconds' $i; sleep 1
>>echo -ne  "\rFinishing sync in: $i seconds\033[0K";
>> sleep 1
>>done
>> echo -e "\nSync completed!"
>> trap 2
>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>> $_PKG_MAIN/Packages/tmp/Packages-xenial-main
>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>> $_PKG_UPD/Packages  /tmp/Packages-xenial-updates
>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>> $_PKG_SEC/Packages  /tmp/Packages-xenial-security
>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>> $_PKG_UNIV/Packages/tmp/Packages-xenial-universe
>>

Below is your error

Packages.new is the "modified" Packages which you rename and
*afterwards* use its "modified" timestamp. This is wrong.

You have to use the "modified" timestamp of the "original" (the one
generated by Spacewalk) packages file

So when you have the original "Packages" file (by spacewalk), do

- run the  script (which generates "Packages.new")
- gzip -c Packages.new > Packages.gz
- touch -r Packages Packages.new Packages.gz && mv Packages.new Packages

So you have transferred the original timestamp to the new files and all
set to "secure" your repo then.

Robert

>>/bin/mv $_PKG_MAIN/Packages.new $_PKG_MAIN/Packages
>>/bin/mv $_PKG_SEC/Packages.new $_PKG_SEC/Packages
>>/bin/mv $_PKG_UPD/Packages.new $_PKG_UPD/Packages
>>/bin/mv $_PKG_UNIV/Packages.new $_PKG_UNIV/Packages
>>
>>gzip < $_PKG_MAIN/Packages > $_PKG_MAIN/Packages.gz
>>gzip < $_PKG_UPD/Packages  > $_PKG_UPD/Packages.gz
>>gzip < $_PKG_SEC/Packages  > $_PKG_SEC/Packages.gz
>>gzip < $_PKG_UNIV/Packages > $_PKG_UNIV/Packages.gz
>>
>> cd $_PKG_MAIN
>>$_BIN_PATH/secureApt.sh  xenial xenial-main
>>touch -r Packages.gz  Packages
>> cd $_PKG_UPD
>>$_BIN_PATH/secureApt.sh  xenial xenial-updates
>>touch -r Packages.gz  Packages
>> cd $_PKG_SEC
>>$_BIN_PATH/secureApt.sh  xenial xenial-security
>>touch -r Packages.gz  Packages
>>
>> So just to resume, SYNC =>OK, applying ALL missing headers =>OK, now
>> the
>> packages that are showed as up-gradable dropped from ~120 to only 6 (
>> base-files libbind9-140 libisc160 libisccc140 libisccfg140 liblwres141
>> )
>>
>>
>> ~~BUT~~
>>
>> Here I run into another problem, it seems taskomatic is generating
>> Package files over and over ( touch -r Packages.gz  Packages seems to
>> have no effect)
>
> This seems to be new. You might have to check within code, at which 
> conditions a rebuild of the Packages file gets triggered
>
> I'm still on SW2.7 so I cannot test on my environment.
>
> Robert
>
>
>




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Disable downloading stock repos in CentOS

2019-02-22 Thread William H. ten Bensel

There is another option mentioned in the archive, about updating 
/etc/yum.conf with a new reposdir=.  This avoids updating/creating the 
repositories when the CentOS release rpm is updated with the next kernel 
release.   Oracle and Redhat do not include the repository information in 
the primary release rpm, but provide optional rpms or methods to install 
the repositories.  By separating the functionality of the rpm, this avoids 
these issues.  I wish CentOS would follow the same process as well.

https://www.redhat.com/archives/spacewalk-list/2018-February/msg00033.html

# rpm -ql centos-release-7-5.1804.5.el7.centos.x86_64 |grep repo

/etc/yum.repos.d/CentOS-Base.repo
/etc/yum.repos.d/CentOS-CR.repo
/etc/yum.repos.d/CentOS-Debuginfo.repo
/etc/yum.repos.d/CentOS-Media.repo
/etc/yum.repos.d/CentOS-Sources.repo
/etc/yum.repos.d/CentOS-Vault.repo
/etc/yum.repos.d/CentOS-fasttrack.repo

# rpm -ql oraclelinux-release-7.5-1.0.5.el7.x86_64 |grep repo
#

- Thanks and good luck



From:   "p.cook...@bham.ac.uk" 
To: "spacewalk-list@redhat.com" 
Date:   02/22/2019 07:39 AM
Subject:Re: [Spacewalk-list] Disable downloading stock repos in 
CentOS
Sent by:spacewalk-list-boun...@redhat.com



This email originated from outside of the company. Please use discretion 
if opening attachments or clicking on links.

 
Hi Paul
 
There are a few options to disable existing repo’s really:
 
1.   Move existing related repo files to a different location (like 
you’ve described).
 
mkdir /root/Original_Repos
mv /etc/yum.repos.d/* /root/Original_Repos/
yum clean all and/or rm -rf /var/cache/yum
 
2.   Temporarily disable during update.
 
yum --disablerepo= update
 
3.   Permanently disable.
 
Change the value of “enabled=” from 1 to 0 in /etc/yum.repos.d/
 
Regards
Phil
 
 
 
From: spacewalk-list-boun...@redhat.com 
 On Behalf Of pdev...@uottawa.ca
Sent: 22 February 2019 12:52
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] Disable downloading stock repos in CentOS
 
Hello,
 
I would like to disable the downloading of the stock repos like 
Centos-Base.repo and the rest They get in the way when I perform upgrades 
(unless I'm doing something wrong?) I usually move the repos to a 
different directory so that yum does not see them.
 
Thank you,

-- 
Paul Deveau
Analyste de systèmes principal|Senior Systems Analyst
Technologies de l’information|Information Technology
Université d’Ottawa|University of Ottawa
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list



**

This email and any attachments may contain information that is confidential 
and/or privileged for the sole use of the intended recipient.  Any use, review, 
disclosure, copying, distribution or reliance by others, and any forwarding of 
this email or its contents, without the express permission of the sender is 
strictly prohibited by law.  If you are not the intended recipient, please 
contact the sender immediately, delete the e-mail and destroy all copies.
**
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] spacewalk 2.9 && never ending issue with ubuntu/debian clients

2019-02-22 Thread Robert Paschedag

On 2/22/19 10:30 PM, Robert Paschedag wrote:
> On 2/22/19 7:53 PM, Robert Paschedag wrote:
>> Am 22. Februar 2019 13:11:00 MEZ schrieb Florin Portase 
>> :
>>> On 2019-02-13 10:56, Florin Portase wrote:
>>>
 Hello,

 I just have upgraded the spacewalk server from 2.7 => 2.9.

 I have applied also the sql patch from
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1661347

 + upgraded the clients from :


>>> http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/
>>>

 Just to mention spacewalk 2.7 +  patches was working just fine for
>>> both debian & ubuntu.

 Now, for ubuntu 16.05 I have over 100 packages marked as up-gradable(
>>> over and over)

 ___

 Spacewalk-list mailing list
 Spacewalk-list@redhat.com
 https://www.redhat.com/mailman/listinfo/spacewalk-list
>>>
>>> So, after digging through  SPW archive Dec '18 til Feb '19 finally I
>>> come to something more acceptable:
>>>
>>> 1. sync script for Ubuntu channels
>>>
>>> 2. "spacewalk-add-debian-multiarch-header.py.NEW " took it from
>>> "https://www.redhat.com/archives/spacewalk-list/2018-December/msg00017.html;
>>>
>>>
>>> wget  -q
>>> http://de.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/Packages.gz
>>> \
>>>-O /tmp/Packages-xenial-main.gz && gunzip -f
>>> /tmp/Packages-xenial-main.gz
>>> wget  -q
>>> http://cz.archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-amd64/Packages.gz
>>> \
>>>-O /tmp/Packages-xenial-updates.gz  && gunzip -f
>>> /tmp/Packages-xenial-updates.gz
>>> wget  -q
>>> http://cz.archive.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages.gz
>>> \
>>>-O /tmp/Packages-xenial-security.gz && gunzip -f
>>> /tmp/Packages-xenial-security.gz
>>>
>>> s=180
>>> trap 'echo "Ctrl-C detected."' 2
>>> for (( i=$s ; i>0; i--));
>>>do
>>>#printf '\rFinishing sync in: %2d seconds' $i; sleep 1
>>>echo -ne  "\rFinishing sync in: $i seconds\033[0K";
>>> sleep 1
>>>done
>>> echo -e "\nSync completed!"
>>> trap 2
>>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>>> $_PKG_MAIN/Packages/tmp/Packages-xenial-main
>>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>>> $_PKG_UPD/Packages  /tmp/Packages-xenial-updates
>>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>>> $_PKG_SEC/Packages  /tmp/Packages-xenial-security
>>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>>> $_PKG_UNIV/Packages/tmp/Packages-xenial-universe
>>>
>
> Below is your error
>
> Packages.new is the "modified" Packages which you rename and
> *afterwards* use its "modified" timestamp. This is wrong.
>
> You have to use the "modified" timestamp of the "original" (the one
> generated by Spacewalk) packages file
>
> So when you have the original "Packages" file (by spacewalk), do
>
> - run the  script (which generates "Packages.new")
> - gzip -c Packages.new > Packages.gz
> - touch -r Packages Packages.new Packages.gz && mv Packages.new Packages
>
> So you have transferred the original timestamp to the new files and all
> set to "secure" your repo then.
>
> Robert
>

OopsI was wrong. The modified time of "Packages.gz" is the one you
need to preserve

See this function, which checks, if the files has to be regenerated.

...
public boolean isChannelRepodataStale(Channel channel) {
File theFile = new File(mountPoint + File.separator + pathPrefix +
File.separator + channel.getLabel() + File.separator +
"Packages.gz");
// Init Date objects without milliseconds
Calendar cal = Calendar.getInstance();
cal.setTime(new Date(theFile.lastModified()));
cal.set(Calendar.MILLISECOND, 0);
Date fileModifiedDate = cal.getTime();
cal.setTime(channel.getLastModified());
cal.set(Calendar.MILLISECOND, 0);
Date channelModifiedDate = cal.getTime();

// the file Modified date should be getting set when the file
// is moved into the correct location.
log.info("File Modified Date:" + LocalizationService.getInstance().
formatCustomDate(fileModifiedDate));
log.info("Channel Modified Date:" +
LocalizationService.getInstance().
formatCustomDate(channelModifiedDate));
return !fileModifiedDate.equals(channelModifiedDate);
}

...

Robert

>>>/bin/mv $_PKG_MAIN/Packages.new $_PKG_MAIN/Packages
>>>/bin/mv $_PKG_SEC/Packages.new $_PKG_SEC/Packages
>>>/bin/mv $_PKG_UPD/Packages.new $_PKG_UPD/Packages
>>>/bin/mv $_PKG_UNIV/Packages.new $_PKG_UNIV/Packages
>>>
>>>gzip < $_PKG_MAIN/Packages > $_PKG_MAIN/Packages.gz
>>>gzip < $_PKG_UPD/Packages  > $_PKG_UPD/Packages.gz
>>>

Re: [Spacewalk-list] xmlrpclib.ProtocolError issue with spacewalk-manage-channel-lifecycle

Re: [Spacewalk-list] Sequences going wrong

Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

[Spacewalk-list] Any tool available to check spacewalk-database for consistency?

Re: [Spacewalk-list] xmlrpclib.ProtocolError issue with spacewalk-manage-channel-lifecycle

Re: [Spacewalk-list] spacewalk 2.9 && never ending issue with ubuntu/debian clients

[Spacewalk-list] Disable downloading stock repos in CentOS

[Spacewalk-list] Spacewalk Mail Configuration

Re: [Spacewalk-list] Disable downloading stock repos in CentOS

Re: [Spacewalk-list] Getting an error when trying to delete a machine or doing a cobbler-sync

Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

Re: [Spacewalk-list] centos mirror and setup in spacewalk

Re: [Spacewalk-list] spacewalk 2.9 && never ending issue with ubuntu/debian clients

[Spacewalk-list] Re; Any tool available to check spacewalk-database for consistency?

Re: [Spacewalk-list] spacewalk 2.9 && never ending issue with ubuntu/debian clients

Re: [Spacewalk-list] Disable downloading stock repos in CentOS

Re: [Spacewalk-list] spacewalk 2.9 && never ending issue with ubuntu/debian clients

17 matches

Site Navigation

Mail list logo

Footer information