Re: [CentOS-docs] Documentation SIG: Participation wanted

2020-07-02 Thread Pany
I'd love to volunteer too.

On Wed, Jul 1, 2020 at 2:21 AM Rich Bowen  wrote:
>
> Hi, folks,
>
> I've been working through the CentOS wiki for more than a year now,
> trying to identify and fix outdated/wrong/obsolete content. It's a
> daunting task, and I'm losing.
>
> I would very much like to gather a group of people who are:
>
> * Knowledgeable about CentOS
> * Good with words
> * Have a little time
>
> who would be willing and able to review the content of the wiki, and fix
> the bits that are incorrect.
>
> The CentOS Documentation SIG (which doesn't actually exist in any
> meaningful way) is, according to the wiki:
>
> responsible for the content of the Wiki, and other public sources of
> documentation. This includes, but is not limited to:
>
> * Determining, and imposing, a hierarchy/architecture of content in the wiki
> * Editing/pruning existing content when it is incorrect/outdated/obsolete
> * Recruiting subject matter experts to do some of that editing
> * Recruiting translators to keep our various translations in sync
>
> [Ref: https://wiki.centos.org/SpecialInterestGroup/Documentation ]
>
> If any of the above appeals to you, I would ask you to let me know. I
> would like to create a SIG around the wiki. Please let me know if you're
> interested. I know that there are a number of you who are consistently
> active on this list. I would like to find a way to give us a little more
> power/authority over the wiki to make higher-level editorial decisions
> about information architecture. Also, having a formal SIG might be a way
> to engage more people to join the effort and dedicate some time to it.
>
> ___
> CentOS-docs mailing list
> CentOS-docs@centos.org
> https://lists.centos.org/mailman/listinfo/centos-docs
___
CentOS-docs mailing list
CentOS-docs@centos.org
https://lists.centos.org/mailman/listinfo/centos-docs


Re: [CentOS] CentOS7 and NFS

2020-07-02 Thread Orion Poplawski

On 6/1/20 3:08 AM, Patrick Bégou wrote:

Le 13/05/2020 à 02:13, Orion Poplawski a écrit :

On 5/12/20 2:46 AM, Patrick Bégou wrote:

Hi,

I need some help with NFSv4 setup/tuning. I have a dedicated nfs server
(2 x E5-2620  8cores/16 threads each, 64GB RAM, 1x10Gb ethernet and 16x
8TB HDD) used by two servers and a small cluster (400 cores). All the
servers are running CentOS 7, the cluster is running CentOS6.

Time to time on the server I get:

   kernel: NFSD: client xxx.xxx.xxx.xxx testing state ID with
  incorrect client ID

And the client xxx.xxx.xxx.xxx freeze whith:

   kernel: nfs: server x.legi.grenoble-inp.fr not responding,
  still trying
   kernel: nfs: server x.legi.grenoble-inp.fr OK
   kernel: nfs: server x.legi.grenoble-inp.fr not responding,
  still trying
   kernel: nfs: server x.legi.grenoble-inp.fr OK

There is a discussion on RedHat7 support about this but only open to
subscribers. Other searches with google do not provide  useful
information.


FYI - you can get access to such info with a free RHEL developers
account.



Thanks for your suggestion. As the problem is back I've subscribed to
reach the full content of this discussion.

The answer was "do not use antivirus" :-(. I do not use antivirus as I
am CentOS only.

Patrick



Just curious to see if you have had any luck resolving these issues? 
I'm afraid that NFS on EL 7 has become much less stable for us recently 
as well with lots more client access hangs.


Orion

--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS-docs] Documentation SIG: Participation wanted

2020-07-02 Thread Earl Ramirez
On Tue, 2020-06-30 at 14:20 -0400, Rich Bowen wrote:
> If any of the above appeals to you, I would ask you to let me know.
> I 
> 
> would like to create a SIG around the wiki. Please let me know if
> you're 
> 
> interested. I know that there are a number of you who are
> consistently 
> 
> active on this list. I would like to find a way to give us a little
> more 
> 
> power/authority over the wiki to make higher-level editorial
> decisions 
> 
> about information architecture. Also, having a formal SIG might be a
> way 
> 
> to engage more people to join the effort and dedicate some time to
> it.

I will like to volunteer for this endeavour. 


signature.asc
Description: This is a digitally signed message part
___
CentOS-docs mailing list
CentOS-docs@centos.org
https://lists.centos.org/mailman/listinfo/centos-docs


Re: [CentOS] setting kernel IP boot values

2020-07-02 Thread Jerry Geis
I also just tried systemd.hostname=jerry.domain and that did not work
either.

Jerry
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] setting kernel IP boot values

2020-07-02 Thread Jerry Geis
>I desire to set IP boot values with DHCP and name of machine say jerry.

>so I would use ip=jerry.domain:eth0:dhcp
I tried that on a VM - it still has localhost as the name it did not use
jerry.domain in my example.

I just need DHCP boot and to be able to set the machine name on boot. How
is that done on the kernel boot?

Jerry
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] setting kernel IP boot values

2020-07-02 Thread Jerry Geis
Hi I found this information:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-configuring_ip_networking_from_the_kernel_command_line

Specifically:
Set the configuration using the ip option on the kernel command line:
ip:[]:{dhcp|dhcp6|auto6|on|any|none|off}
dhcp - DHCP configuration
dhpc6 - DHCP IPv6 configuration
auto6 - automatic IPv6 configuration
on, any - any protocol available in the kernel (default)
none, off - no autoconfiguration, static network configuration
For example:
ip=192.168.180.120:192.168.180.100:192.168.180.1:255.255.255.0::enp1s0:off

but I am confused.

I desire to set IP boot values with DHCP and name of machine say jerry.

so I would use ip=jerry.domain:eth0:dhcp


Is this correct ?

Jerry
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] [OT] Bacula offsite replication

2020-07-02 Thread Valeri Galtsev




On 2020-07-02 09:50, Bez Thomas wrote:

Hi Valeri,

To go off on a tangent, do you use the Bareos community edition, or the paid 
version?



I use open source - community edition. I work for the department of the 
university, they do not have much money, thus pretty much everything I 
set up for them is free as in free bear. I have to invest my time and 
knowledge - and help of others - instead of paid support, and this way I 
earn my salary ;-) Suits both myself and my employers.


Valeri


Thanks,
Bez Thomas (he/him)
Tech Services, Astronomy/CCAPS
222 Space Sciences Bldg, Cornell University
607-255-3434







On Jul 2, 2020, at 10:39 AM, Valeri Galtsev  wrote:



On 2020-07-02 08:28, Alessandro Baggi wrote:

Il 02/07/20 15:02, Valeri Galtsev ha scritto:



On 7/2/20 3:22 AM, Alessandro Baggi wrote:

Il 01/07/20 17:13, Leroy Tennison ha scritto:

I realize this shouldn't happen, the file is a tgz and isn't being modified 
while being transmitted.  This has happened maybe three times this year and 
unfortunately I've just had to deal with it rather than invest the time to do 
the research.


Harriscomputer

Leroy Tennison
Network Information/Cyber Security Sp


Hi Leroy,

I think that in my case I could not use a tgz archive. I'm speaking about full 
backups that reach 600/700GiB, compressing them and then rsync them could take 
so much time that it will be useless.



unless you use tape (of that high capacity), it is advantageous to restrict 
volume size to, say, 50GB. Then when you restore, search for specific files 
will be faster. And it will help your backup volumes transfers as well.

Valeri

Hi Valeri,
thank you for your suggestion.
Is bacula the right backup system when I need to replicate data offsite? There 
are other backup solution that simplify this process?


Bacula is great enterprise level open source backup system. I switched to its 
fork bareos at some point; I use bacula/bareos for at least a decade. And with 
this your extra requirement I still would stay with bareos (or bacula).

If I were to have two sets of backup: on site and off site, I would just set up 
separate bacula/bareos director and storage daemon(s) off site. Add to FDs 
(file daemons) extra instances of director - offsite one with different 
passwords for the sake of security. Then there will be a set of everything off 
site, not only a set of volumes. Of course, if you only have a set of volumes, 
but everything else has evaporated, you still will be able to restore 
everything, including database records by scanning set of volumes. Which will 
take forever. I would alternate dates of backups in offsite/onsite schedules, 
or define times of backups so that they do not overlap.

Another good news of this vs just rsyncing volumes is: bacula/bareos verifies 
checksum of every backed up file after receiving it. This will ensure 
consistency of files in remote volumes, for rsync you will have to at least 
verify checksum of each volume transferred to destination (unless I miss my 
wits and rsync does verify checksums of files transferred, I just re-read rsync 
man and don't see verification - hopefully rsync expert will chime in and 
correct me if I'm wrong about rsync).

Anyway, that is what I would do.

Valeri


Thank you in advance
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


--

Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos




--

Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] [OT] Bacula offsite replication

2020-07-02 Thread Valeri Galtsev



On 2020-07-02 08:28, Alessandro Baggi wrote:


Il 02/07/20 15:02, Valeri Galtsev ha scritto:



On 7/2/20 3:22 AM, Alessandro Baggi wrote:

Il 01/07/20 17:13, Leroy Tennison ha scritto:
I realize this shouldn't happen, the file is a tgz and isn't being 
modified while being transmitted.  This has happened maybe three 
times this year and unfortunately I've just had to deal with it 
rather than invest the time to do the research.



Harriscomputer

Leroy Tennison
Network Information/Cyber Security Sp


Hi Leroy,

I think that in my case I could not use a tgz archive. I'm speaking 
about full backups that reach 600/700GiB, compressing them and then 
rsync them could take so much time that it will be useless.




unless you use tape (of that high capacity), it is advantageous to 
restrict volume size to, say, 50GB. Then when you restore, search for 
specific files will be faster. And it will help your backup volumes 
transfers as well.


Valeri


Hi Valeri,

thank you for your suggestion.

Is bacula the right backup system when I need to replicate data offsite? 
There are other backup solution that simplify this process?




Bacula is great enterprise level open source backup system. I switched 
to its fork bareos at some point; I use bacula/bareos for at least a 
decade. And with this your extra requirement I still would stay with 
bareos (or bacula).


If I were to have two sets of backup: on site and off site, I would just 
set up separate bacula/bareos director and storage daemon(s) off site. 
Add to FDs (file daemons) extra instances of director - offsite one with 
different passwords for the sake of security. Then there will be a set 
of everything off site, not only a set of volumes. Of course, if you 
only have a set of volumes, but everything else has evaporated, you 
still will be able to restore everything, including database records by 
scanning set of volumes. Which will take forever. I would alternate 
dates of backups in offsite/onsite schedules, or define times of backups 
so that they do not overlap.


Another good news of this vs just rsyncing volumes is: bacula/bareos 
verifies checksum of every backed up file after receiving it. This will 
ensure consistency of files in remote volumes, for rsync you will have 
to at least verify checksum of each volume transferred to destination 
(unless I miss my wits and rsync does verify checksums of files 
transferred, I just re-read rsync man and don't see verification - 
hopefully rsync expert will chime in and correct me if I'm wrong about 
rsync).


Anyway, that is what I would do.

Valeri


Thank you in advance

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


--

Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] How to Mirror CentOS8 repository in CentOS7 Server via reposync

2020-07-02 Thread psuresh via CentOS
Hi



I'm running CentOS7 server as ImageServer and local repository server.  And i 
need to mirror CentOS8 repository 
(http://mirror.centos.org/centos-8/8.1.1911/AppStream/x86_64/os/ ) in my 
CentOS7 Server. 

 

 If i mirror CentOS8 repository using repo sync command in CentOS7 it did
 not properly mirror centos8 repository, due to that when i install 
package from CentOS8 client machine getting following error. 

 

 No available modular metadata for modular package 
'python3-lldb-8.0.1-1.module_el8.1.0+215+a01033fb.x86_64', it cannot be 
installed on the system

 The downloaded packages were saved in cache until the next successful 
transaction.

 You can remove cached packages by executing 'dnf clean packages'.

 Error: No available modular metadata for modular package

 

 Can you please suggest proper way to mirror CentOS8 repository in CentOS7 
Server? 



Regards,

Suresh PanneerSelvam
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] [OT] Bacula offsite replication

2020-07-02 Thread Leroy Tennison
Depending on the definition of offsite, you have a fundamental problem: either 
invest the time/effort compressing or take extra bandwidth, which is less 
costly?  Hopefully a delta transfer makes sense in your situation and should 
save far more than compression would once the original copy is offsite.


From: CentOS  on behalf of Valeri Galtsev 

Sent: Thursday, July 2, 2020 8:02 AM
To: centos@centos.org 
Subject: [EXTERNAL] Re: [CentOS] [OT] Bacula offsite replication

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.



Harriscomputer

Leroy Tennison
Network Information/Cyber Security Specialist
E: le...@datavoiceint.com


[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]


2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.com


This message has been sent on behalf of a company that is part of the Harris 
Operating Group of Constellation Software Inc.

If you prefer not to be contacted by Harris Operating Group please notify 
us.



This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or confidential or otherwise legally exempt from disclosure. If you 
are not the named addressee, you are not authorized to read, print, retain, 
copy or disseminate this message or any part of it. If you have received this 
message in error, please notify the sender immediately by e-mail and delete all 
copies of the message.





On 7/2/20 3:22 AM, Alessandro Baggi wrote:
> Il 01/07/20 17:13, Leroy Tennison ha scritto:
>> I realize this shouldn't happen, the file is a tgz and isn't being
>> modified while being transmitted.  This has happened maybe three times
>> this year and unfortunately I've just had to deal with it rather than
>> invest the time to do the research.
>>
>>
>> Harriscomputer
>>
>> Leroy Tennison
>> Network Information/Cyber Security Sp
>
> Hi Leroy,
>
> I think that in my case I could not use a tgz archive. I'm speaking
> about full backups that reach 600/700GiB, compressing them and then
> rsync them could take so much time that it will be useless.
>

unless you use tape (of that high capacity), it is advantageous to
restrict volume size to, say, 50GB. Then when you restore, search for
specific files will be faster. And it will help your backup volumes
transfers as well.

Valeri

> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos

--

Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] [OT] Bacula offsite replication

2020-07-02 Thread Alessandro Baggi


Il 02/07/20 15:02, Valeri Galtsev ha scritto:



On 7/2/20 3:22 AM, Alessandro Baggi wrote:

Il 01/07/20 17:13, Leroy Tennison ha scritto:
I realize this shouldn't happen, the file is a tgz and isn't being 
modified while being transmitted.  This has happened maybe three 
times this year and unfortunately I've just had to deal with it 
rather than invest the time to do the research.



Harriscomputer

Leroy Tennison
Network Information/Cyber Security Sp


Hi Leroy,

I think that in my case I could not use a tgz archive. I'm speaking 
about full backups that reach 600/700GiB, compressing them and then 
rsync them could take so much time that it will be useless.




unless you use tape (of that high capacity), it is advantageous to 
restrict volume size to, say, 50GB. Then when you restore, search for 
specific files will be faster. And it will help your backup volumes 
transfers as well.


Valeri


Hi Valeri,

thank you for your suggestion.

Is bacula the right backup system when I need to replicate data offsite? 
There are other backup solution that simplify this process?


Thank you in advance

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] [OT] Bacula offsite replication

2020-07-02 Thread Valeri Galtsev



On 7/2/20 3:22 AM, Alessandro Baggi wrote:

Il 01/07/20 17:13, Leroy Tennison ha scritto:
I realize this shouldn't happen, the file is a tgz and isn't being 
modified while being transmitted.  This has happened maybe three times 
this year and unfortunately I've just had to deal with it rather than 
invest the time to do the research.



Harriscomputer

Leroy Tennison
Network Information/Cyber Security Sp


Hi Leroy,

I think that in my case I could not use a tgz archive. I'm speaking 
about full backups that reach 600/700GiB, compressing them and then 
rsync them could take so much time that it will be useless.




unless you use tape (of that high capacity), it is advantageous to 
restrict volume size to, say, 50GB. Then when you restore, search for 
specific files will be faster. And it will help your backup volumes 
transfers as well.


Valeri


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


--

Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] CentOS-announce Digest, Vol 185, Issue 1

2020-07-02 Thread centos-announce-request
Send CentOS-announce mailing list submissions to
centos-annou...@centos.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org

You can reach the person managing the list at
centos-announce-ow...@centos.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."


Today's Topics:

   1. CEBA-2020:2662 CentOS 7 selinux-policy BugFix Update
  (Johnny Hughes)
   2. CEBA-2020:2659  CentOS 7 systemd BugFix Update (Johnny Hughes)


--

Message: 1
Date: Tue, 30 Jun 2020 20:57:31 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CEBA-2020:2662 CentOS 7 selinux-policy
BugFix  Update
Message-ID: <20200630205731.ga9...@bstore1.rdu2.centos.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Bugfix Advisory 2020:2662 

Upstream details at : https://access.redhat.com/errata/RHBA-2020:2662

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

x86_64:
7565ffd1f3418c04442b5eb731eeccc4cc52f2089938035d4dc04e777568b2b0  
selinux-policy-3.13.1-266.el7_8.1.noarch.rpm
f2dacc5e31de8fa35d3ceb452c4d5203a9cbb96e0aa8f56b599c63f1019cd8b5  
selinux-policy-devel-3.13.1-266.el7_8.1.noarch.rpm
2fb36e1a13c028ecc1c286681c25e1b1c425c4496493d62e3b764a873120e8ab  
selinux-policy-doc-3.13.1-266.el7_8.1.noarch.rpm
afaa647d4aec875a206806a35bc776f8861fa3430e194adddaa342b70883afa2  
selinux-policy-minimum-3.13.1-266.el7_8.1.noarch.rpm
bd3c1accb03bd25d3af8839896c75d2a892ce485713437fda2f249fa00c9f04b  
selinux-policy-mls-3.13.1-266.el7_8.1.noarch.rpm
26d654fb629b24814ed5776e478cc6e9c0b7edb24b3bde1adc0995421da07293  
selinux-policy-sandbox-3.13.1-266.el7_8.1.noarch.rpm
75493cf7ada339fe000804c858943eed597295053e9164726dc0424986931344  
selinux-policy-targeted-3.13.1-266.el7_8.1.noarch.rpm

Source:
7012c0fedb27556b513cb7d18d1ed0f7c3480febd4f4d016176f16331e1bc01e  
selinux-policy-3.13.1-266.el7_8.1.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS



--

Message: 2
Date: Tue, 30 Jun 2020 20:58:38 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CEBA-2020:2659  CentOS 7 systemd BugFix
Update
Message-ID: <20200630205838.ga10...@bstore1.rdu2.centos.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Bugfix Advisory 2020:2659 

Upstream details at : https://access.redhat.com/errata/RHBA-2020:2659

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

x86_64:
308539b57a0114a416b08951260b3004a47eea3f0428a9f7e7facf056b58fd53  
libgudev1-219-73.el7_8.8.i686.rpm
32ddfd836f86b19e1d7aaa1d4c3a9ce5febefde1fc3d97d333290de0da348c36  
libgudev1-219-73.el7_8.8.x86_64.rpm
963ef1a3d5e79721a0e098a83becbe088b1fc3a651b677ba3132cef1fe0d94f9  
libgudev1-devel-219-73.el7_8.8.i686.rpm
10206d79be9585d77ec804594b0b9b7ee1a98c88e6ccc9cdbb97f77b3e28b12a  
libgudev1-devel-219-73.el7_8.8.x86_64.rpm
86125d34008aa7e84ef19e51da544bbad7a1b76660fe24e5563fe5dc3069dff1  
systemd-219-73.el7_8.8.x86_64.rpm
a371370c6fdaee61698cf6414e70496ff41cca58847d27a25de9864859ae9685  
systemd-devel-219-73.el7_8.8.i686.rpm
7034ef244407efdc1c17a14363e50eaa9c589c84bbf886139b9fad7e7a6922d0  
systemd-devel-219-73.el7_8.8.x86_64.rpm
4b420cdb7274ca935f3d283d5808d55c20396930a0765f6d938cf811dc2ba909  
systemd-journal-gateway-219-73.el7_8.8.x86_64.rpm
f7940bca479a5a6710d95dcd9e2f5d688caabc3046f9db25dbd56b16fda54d46  
systemd-libs-219-73.el7_8.8.i686.rpm
ac9cbb53bbc1915e7c6b2d8a08db6e87e2104bb4f2b708d9590ea6430872b9b6  
systemd-libs-219-73.el7_8.8.x86_64.rpm
95feec5d6656b6eaf7802c9ee7be76e019588e7e453b88925738fa2339f5a892  
systemd-networkd-219-73.el7_8.8.x86_64.rpm
5119f092a7841e1ffdffdaffcdc8c33c888df2cef7dab0ef3dc9da9c13b9dd34  
systemd-python-219-73.el7_8.8.x86_64.rpm
9f5887416fd66523d3961064be9b692b5084d028f1bfde7d28ff55dc9a0bad53  
systemd-resolved-219-73.el7_8.8.i686.rpm
f66fbfc873e73ba8a9679658bff997c549b9bdb807d798f57856a45eee7199cf  
systemd-resolved-219-73.el7_8.8.x86_64.rpm
08ae1f4a8af88f1d744999d2c11c6aebff0125abbaf899e7e1067241c3756373  
systemd-sysv-219-73.el7_8.8.x86_64.rpm

Source:
5f51c2e9b139106137743c153bc1820ec88963eb5f638e4424c109da6465f320  
systemd-219-73.el7_8.8.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS



--

Subject: Digest Footer

___
CentOS-announce mailing list
centos-annou...@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce



Re: [CentOS] [OT] Bacula offsite replication

2020-07-02 Thread John Pierce
On Thu, Jul 2, 2020, 1:51 AM Alessandro Baggi 
wrote:

> Hi John,
>
> thank you for your answer, I already take in consideration DRBD but I
> need some test before start.
>
> Reading you seems that this solution is not anymore available. What do
> you use for this?
>

That system was surplused 2 years ago when my group was shut down and I
retired.

>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] [OT] Bacula offsite replication

2020-07-02 Thread Alessandro Baggi

Hi John,

thank you for your answer, I already take in consideration DRBD but I 
need some test before start.


Reading you seems that this solution is not anymore available. What do 
you use for this?


Thank you in advance.

Il 02/07/20 10:43, John Pierce ha scritto:

I setup drbd to replicate a ~50TB backuppc hive to the DR copy, an
identical box in a different DC on the same campus, with approximately gigE
speeds, and ran this for a year or two.   It worked well enough but
required babysitting from time to time.   Both nodes were mdraid lvm
logical volumes formatted as a single huge xfs on centos.  I never
automated the failover as it never failed, and as a dev/test backup, 8 hour
response seemed adequate

On Thu, Jul 2, 2020, 1:22 AM Alessandro Baggi 
wrote:


Il 01/07/20 17:13, Leroy Tennison ha scritto:

I realize this shouldn't happen, the file is a tgz and isn't being

modified while being transmitted.  This has happened maybe three times this
year and unfortunately I've just had to deal with it rather than invest the
time to do the research.


Harriscomputer

Leroy Tennison
Network Information/Cyber Security Sp

Hi Leroy,

I think that in my case I could not use a tgz archive. I'm speaking
about full backups that reach 600/700GiB, compressing them and then
rsync them could take so much time that it will be useless.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] [OT] Bacula offsite replication

2020-07-02 Thread John Pierce
I setup drbd to replicate a ~50TB backuppc hive to the DR copy, an
identical box in a different DC on the same campus, with approximately gigE
speeds, and ran this for a year or two.   It worked well enough but
required babysitting from time to time.   Both nodes were mdraid lvm
logical volumes formatted as a single huge xfs on centos.  I never
automated the failover as it never failed, and as a dev/test backup, 8 hour
response seemed adequate

On Thu, Jul 2, 2020, 1:22 AM Alessandro Baggi 
wrote:

> Il 01/07/20 17:13, Leroy Tennison ha scritto:
> > I realize this shouldn't happen, the file is a tgz and isn't being
> modified while being transmitted.  This has happened maybe three times this
> year and unfortunately I've just had to deal with it rather than invest the
> time to do the research.
> >
> >
> > Harriscomputer
> >
> > Leroy Tennison
> > Network Information/Cyber Security Sp
>
> Hi Leroy,
>
> I think that in my case I could not use a tgz archive. I'm speaking
> about full backups that reach 600/700GiB, compressing them and then
> rsync them could take so much time that it will be useless.
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] [OT] Bacula offsite replication

2020-07-02 Thread Alessandro Baggi

Il 01/07/20 17:13, Leroy Tennison ha scritto:

I realize this shouldn't happen, the file is a tgz and isn't being modified 
while being transmitted.  This has happened maybe three times this year and 
unfortunately I've just had to deal with it rather than invest the time to do 
the research.


Harriscomputer

Leroy Tennison
Network Information/Cyber Security Sp


Hi Leroy,

I think that in my case I could not use a tgz archive. I'm speaking 
about full backups that reach 600/700GiB, compressing them and then 
rsync them could take so much time that it will be useless.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos