Re: Joint Fermilab/CERN statement on recent CentOS Changes

2020-12-17 Thread d tbsky
> On 2020/12/18 0:17, James F Amundson wrote:
> > CERN and Fermilab acknowledge the recent decision to shift focus from 
> > CentOS Linux to CentOS Stream, and the sudden change of the end of life of 
> > the CentOS 8 release. This may entail significant consequences for the 
> > worldwide particle physics community. We are currently investigating 
> > together the best path forward. We will keep you informed about any 
> > developments in this area during Q1 2021.
> >
> > James Amundson, Fermilab Scientific Computing Division Head
> >
> > Elizabeth Sexton-Kennedy, Fermilab Chief Information Officer

Great. I hope it means there is a change to upgrade Scientific Linux 7 to 8.


Re: CentOS 8 EOL; CentOS Stream?

2020-12-08 Thread d tbsky
is there any possibility for scientific linux 8?
we are testing centos 8 for several monthes, but scientific linux is
much better.


Re: Centos 8 last straw

2019-11-03 Thread d tbsky
Larry Linder 
>1 more week and we have to reload SL 7.6 and give it up.  Maybe we will
> try RH 9 in a few years.
>

  you should wait for at least RHEL 8.1, or 8.2 to try/use it.
current RHEL 8 is just to give you a feeling for next OS.


SL 7.5 boot hang

2018-05-15 Thread d tbsky
Hi:
   I tried to upgrade our servers to SL 7.5. but one vpn box (intel
j1900 cpu with 4 e1000 port) failed to boot. downgrade to 7.4 kernel
3.10.0-693.21.1 works fine. but with SL 7.5 kernel 3.10.0-862.2.3 or
3.10.0-862 the system will hang randomly during boot process. I have
tried boot parameter "acpi_rev_override=1" and "maxcpus=1" but
useless.  are there other boot parameter worth to try?

   one of the boot messages like below. sometimes I can see " NMI
watchdog: BUG: soft lockup - CPU#0 stuck", sometimes there are no
messages at all, just hang somewhere.

[0.00] Linux version 3.10.0-862.el7.x86_64
(mockbu...@sl7-uefisign.fnal.gov) (gcc version 4.8.5 20150623 (Red Hat
4.8.5-28) (GCC) ) #1 SMP Thu Apr 12 09:09:37 CDT 2018
[0.00] Command line: BOOT_IMAGE=/vmlinuz-3.10.0-862.el7.x86_64
root=/dev/mapper/rootvg-root ro rd.lvm.lv=rootvg/swap
video=1024x768@60 rd.lvm.lv=rootvg/root selinux=0 nodmraid c8
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x00089bff] usable
[0.00] BIOS-e820: [mem 0x00089c00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1eff] usable
[0.00] BIOS-e820: [mem 0x1f00-0x1f0f] reserved
[0.00] BIOS-e820: [mem 0x1f10-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x200f] reserved
[0.00] BIOS-e820: [mem 0x2010-0x79874fff] usable
[0.00] BIOS-e820: [mem 0x79875000-0x798a4fff] reserved
[0.00] BIOS-e820: [mem 0x798a5000-0x798b4fff] ACPI data
[0.00] BIOS-e820: [mem 0x798b5000-0x79a29fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x79a2a000-0x79b88fff] reserved
[0.00] BIOS-e820: [mem 0x79b89000-0x79b89fff] usable
[0.00] BIOS-e820: [mem 0x79b8a000-0x79bcbfff] reserved
[0.00] BIOS-e820: [mem 0x79bcc000-0x79d3afff] usable
[0.00] BIOS-e820: [mem 0x79d3b000-0x79ff9fff] reserved
[0.00] BIOS-e820: [mem 0x79ffa000-0x79ff] usable
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed01000-0xfed01fff] reserved
[0.00] BIOS-e820: [mem 0xfed03000-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff] reserved
[0.00] BIOS-e820: [mem 0xfed0c000-0xfed0] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1cfff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xfef0-0xfeff] reserved
[0.00] BIOS-e820: [mem 0xffb0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00017fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.8 present.
[0.00] e820: last_pfn = 0x18 max_arch_pfn = 0x4
[0.00] PAT configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- UC
[0.00] total RAM covered: 4008M
[0.00] Found optimal setting for mtrr clean up
[0.00]  gran_size: 64K  chunk_size: 128Mnum_reg: 5
 lose cover RAM: 0G
[0.00] e820: last_pfn = 0x7a000 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000fd700-0x000fd70f]
mapped at [ff200700]
[0.00] RAMDISK: [mem 0x361bd000-0x370d6fff]
[0.00] Early table checksum verification disabled
[0.00] ACPI: RSDP 000f04a0 00024 (v02 ALASKA)
[0.00] ACPI: XSDT 798a8078 00074 (v01 ALASKA   A M I
01072009 AMI  00010013)
[0.00] ACPI: FACP 798b3708 0010C (v05 ALASKA   A M I
01072009 AMI  00010013)
[0.00] ACPI: DSDT 798a8180 0B586 (v02 ALASKA   A M I
01072009 INTL 20120913)
[0.00] ACPI: FACS 79a29f80 00040
[0.00] ACPI: APIC 798b3818 00084 (v03 ALASKA   A M I
01072009 AMI  00010013)
[0.00] ACPI: FPDT 798b38a0 00044 (v01 ALASKA   A M I
01072009 AMI  00010013)
[0.00] ACPI: LPIT 798b38e8 00104 (v01 ALASKA   A M I
0003 VLV2 010D)
[0.00] ACPI: MCFG 798b39f0 0003C (v01 ALASKA   A M I
01072009 MSFT 0097)
[0.00] ACPI: HPET 798b3a30 00038 (v01 ALASKA   A M I
01072009 AMI. 0005)
[0.00] ACPI: SSDT 798b3a68 00763 (v01  PmRefCpuPm
3000 INTL 20061109)
[0.00] ACPI: SSDT 798b41d0 00290 (v01  PmRef  Cpu0Tst
3000 INTL 20061109)
[0.00] ACPI: SSDT 798b4460 0017A (v01  PmRefApTst
3000 INTL 

unfortunate bind dns attack

2015-08-03 Thread d tbsky
hi:
   one of our dns server was attack and shutdown, it seems cause by
CVE-2015-5477. we are a small company, so we don't expect 0day attack
happened to us. anyone suffers from the bug also?

scientific linux has fixed it in SL5, but SL6  SL7 don't  have
the fix now..

Regards,
tbskyd


Re: many ip addresses seems banned by scientific linux servers

2015-08-02 Thread d tbsky
2015-08-03 2:39 GMT+08:00 Stephen John Smoogen smo...@gmail.com:
 On 2 August 2015 at 09:32, d tbsky tbs...@gmail.com wrote:
 hi:
we notice some ip address can not access scientific linux servers
 (web or ftp). I don't know why. for example default sl7.repo list
 content below:

 baseurl=http://ftp.scientificlinux.org/linux/scientific/$slreleasever/$basearch/os/

 http://ftp1.scientificlinux.org/linux/scientific/$slreleasever/$basearch/os/

 http://ftp2.scientificlinux.org/linux/scientific/$slreleasever/$basearch/os/

 ftp://ftp.scientificlinux.org/linux/scientific/$slreleasever/$basearch/os/


 but they resolve to only 1 ip address: 131.225.105.11
 so some of our servers can not get yum update working with the default
 configuration.
 this happen about a year ago. and it seems more and more ip are banned..

 You need to provide what ip address you are trying to reach the server
 from for anyone to help on this.

 There could be two reasons for this:

 The Scientific Linux distribution is sponsored by a United States
 Department of Energy National Lab, Fermi Laboratory. That does mean
 that it has to abide by certain restrictions on what countries are
 allowed to connect to the server (countries like North Korea and some
 others).

 Various foreign governments block access to United States government
 servers for various reasons at various times. This can cause problems
 for other people if your access 'transits' that countries routers.

 Not much can be done about this other than trying to find a mirror
 that is allowed access in the country and then pointing your
 yum.repos.d/*.repo files to that mirror.

 --
 Stephen J Smoogen.

   thanks for the information. may I ask whom to contact so I can give
him/her the ip addresses?
   but since these ip may be blocked again in the future, I don't know
if the default sl7.repo can list more repository other than
131.225.105.11?
   thanks again for kindly help!!

Regards,
tbskyd