Re: [CentOS] UEFI and PXE

2019-04-25 Thread Steven Tardy
On Thu, Apr 25, 2019 at 8:46 PM Chris Adams  wrote:

> Once upon a time, Steven Tardy  said:
> > The “ICMP unreachable” should be a dead giveaway. . .
>
> You cut out the part of the email where the OP said that the UEFI system
> was ignoring the next-server part of the DHCP reply and trying to TFTP
> to the DHCP server instead of the TFTP server.  Of course that got ICMP
> unreachable, but it isn't a firewall problem.
>
> To the OP: can you post a full tcpdump decode of the DHCP offer?  I
> seem to remember having some issue with ISC DHCP in the past not getting
> the next server set correctly - maybe a packet will jog some memory (and
> I'll go try to grab the same from my dnsmasq DHCP for comparison).
>

Just set up ISC DHCP on fresh CentOS 7 install and followed the redhat
guide linked in this thread.
Did what I thought was correct and duplicated the OPs problem.
/me scratches head. . . off to `tcpdump -vv -nn -i ens192`. . . packets
never lie. . .
Vendor-Class Option 60, length 32:
"PXEClient:Arch:7:UNDI:003000"

d'oh; I did _lower case_ a string in dhcpd.conf line on accident while
transcribing:
match if substring (option vendor-class-identifier, 0, 9) =
"pxeclient";

Changed it to follow redhat guide CAMELCase and poof,
match if substring (option vendor-class-identifier, 0, 9) =
"PXEClient";

PXEClient tried to reach out "next-server".
00:42:24.606544 IP 1.2.3.10.1165 > 1.2.3.2.69:  50 RRQ
"pxelinux/bootx64.efi" octet tsize 0 blksize 1468

If the OP still can't get this working, packet captures really do help. (;


[root@DHCPServer ~]# cat /etc/dhcp/dhcpd.conf
option arch code 93 = unsigned integer 16; #RFC 4578
subnet 1.2.3.0 netmask 255.255.255.0 {
option routers 1.2.3.254;
range 1.2.3.10 1.2.3.20;
class "pxeclients" {
match if substring (option vendor-class-identifier, 0, 9) =
"PXEClient";
next-server 1.2.3.2;
if option arch = 00:06 {
filename = "pxelinux/bootia32.efi";
} else if option arch = 00:07 {
filename = "pxelinux/bootx64.efi";
} else {
filename = "pxelinux/pxelinux.0";
}
}
}
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] : Iptables blocks out going connetion some times

2019-04-25 Thread likun
Yes, I have double checked and am sure there is no IP address conflicts.

Likun

On 4/24/19 23:28, centos wrote:
>On 4/24/19 10:31, likun wrote:
>> Hello, Stephen, thank you for input.
>> 
>> Yes, these servers have the same firewall rules, and both of them have
the same problem from time to time, most of time they are good.
>> 
>> Actually, these servers are newly installed to be used as the Glusterfs
storage server, so not much data flowing at this time.
>
>As a WAG - have you double checked to make sure there aren't any IP
addressing conflicts in play?
___
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] UEFI and PXE

2019-04-25 Thread Chris Adams
Once upon a time, Steven Tardy  said:
> The “ICMP unreachable” should be a dead giveaway. . .

You cut out the part of the email where the OP said that the UEFI system
was ignoring the next-server part of the DHCP reply and trying to TFTP
to the DHCP server instead of the TFTP server.  Of course that got ICMP
unreachable, but it isn't a firewall problem.

To the OP: can you post a full tcpdump decode of the DHCP offer?  I
seem to remember having some issue with ISC DHCP in the past not getting
the next server set correctly - maybe a packet will jog some memory (and
I'll go try to grab the same from my dnsmasq DHCP for comparison).

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


Re: [CentOS] UEFI and PXE

2019-04-25 Thread Steven Tardy
On Thu, Apr 25, 2019 at 5:25 AM isdtor  wrote:

> 09:02:02.911381 IP client.cisco-ipsla > dhcp-server.tftp:  56 RRQ
> "linux-install/bootx64.efi" octet tsize 0 blksize 32768
> 09:02:02.911403 IP dhcp-server > client: ICMP dhcp-server udp port tftp
> unreachable, length 92
>

The “ICMP unreachable” should be a dead giveaway. . .

You are missing the `firewall-cmd` configuration. See this guide:

https://www.bo-yang.net/2015/08/31/centos7-install-tftp-server
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Recommended PHP 7 source for Centos 7

2019-04-25 Thread Benjamin Smith
Second vote for remi. Running 7.2, no issues on EL7. The only config issue 
I've had is getting it to work with php-fpm and apache, but that was almost 
all apache config files. 



On Thursday, April 18, 2019 10:16:01 AM PDT Jose Maria Terry Jimenez wrote:
> El 16/4/19 a las 0:39, MRob escribió:
> > I know there's a couple third party repos offering PHP 7 for Centos. I
> > prefer not to add too much third party that I don't have to and PHP 7
> > has been mainstream for some time now, I thought maybe it would be in
> > EPEL by now.
> > 
> > What is the most recommended and stable way to get an up to date PHP
> > on Centos 7?
> 
> Remi Repo works well for me https://rpms.remirepo.net
> ___
> 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] Was: Re: Are linux distros redundant?, is zfs

2019-04-25 Thread Benjamin Smith
On Wednesday, April 24, 2019 1:18:46 PM PDT mark wrote:
> Benjamin Smith wrote:
> > On Wednesday, April 24, 2019 11:25:00 AM PDT Andrew Holway wrote:
> >>> Btw, right now, we've just built a new server as Ubuntu, because my
> >>> manager wants to use it to test zfs, including its ability to a) act
> >>> as a RAID, directly, without an underlying RAID, and b) encrypt the
> >>> whole thing natively.
> >> 
> >> ZFS on linux was originally an EL project. Ubuntu support came later.
> > 
> > I've been running ZoL on CentOS for years. Wonderful stuff. SysAdmin's
> > dream, although we keep all ZoL boxes off any public access and update on
> > a carefully tested schedule to ensure that no RPM version weirdness
> > happens.
> 
> Ok, how's it scale on large filesystems? My manager was running some tests
> this morning, 37TB f/s, and he said it seemed slow to respond. Also, dedup
> seemed to take actual time - minutes. I saw him as he copied a 1G test
> file to two or three other names, and it took time to go up, then level
> off in size, with "size" being what we saw with df.

We don't use dedup so I can't comment there. Memory requirements jump 
*sharply* with dedup and our use case doesn't call for it anyway. 

We store in the range of 500M files in 48TB total pool size, 3x 6 RAIDZ2 
vdevs, 4 TB per HGST 3.5" drive, random read/write load. System memory is 32 
GB ECC on (now) older Xeon processors. Nothing too fancy. We don't use any 
particular caching schemes like ARC. We use compression and get about 1.5 
compressratio. 

For simple file read/writes, It's somewhat slower than ext* (perhaps 1/2 the 
IOPS) but that's more than made up by the fact that backups take minutes 
rather than rsync's days and are always consistent a la snapshots. (You do 
back up, right?) The lack of having a 24x7 rsync process saves far more IOPS 
than the 1/2 cost, so in practice we come out way ahead with a sharp 
performance increase. We considered lsyncd but having a 3 day window of 
replication every time we update our master file servers really seemed like a 
non-starter. 

We have 3 systems of identical configuration, and our application layer reads/
writes to all 3 concurrently at the application level using a custom-written 
daemon that operates over unencrypted TCP sockets on a private LAN. For 
safety, one of the systems is still running ext* just in case we get bit by a 
ZFS bug. (knock on wood, hasn't happened yet in 7 years) 

Performance is more than adequate and has never been a bottleneck, even with 
up to 15,000 concurrent users. If we needed performance increases, we'd 
probably switch to using mirror vdevs instead of RAIDZ2, and then perhaps 
L2ARC. Finally, we can shard the file store if needed at the application 
layer, but we've long ago passed our biggest estimations of when we'd need to 
do this and so far, no significant issues. 


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


Re: [CentOS] Are linux distros redundant?

2019-04-25 Thread Simon Matter via CentOS
> James B. Byrne via CentOS wrote:
>> On Wed, April 24, 2019 11:14, Simon Matter wrote:
>>>
>>> I'm afraid too many clouds make the wider horizon invisible :-)
>>
>> At that point it is called fog.
>
> But, don'tcha know, the only way to clear the fog is to send lots of money
> to them

Well, of course, because they still run it on hardware servers with CPUs,
storage devices, networking, cooling, whatever. That's so yesterday, the
future is Serverless Computing... a bit like brainless thinking :-)

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


Re: [CentOS] Are linux distros redundant?

2019-04-25 Thread mark
James B. Byrne via CentOS wrote:
> On Wed, April 24, 2019 11:14, Simon Matter wrote:
>>
>> I'm afraid too many clouds make the wider horizon invisible :-)
>
> At that point it is called fog.

But, don'tcha know, the only way to clear the fog is to send lots of money
to them

  mark


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


Re: [CentOS] Are linux distros redundant?

2019-04-25 Thread James B. Byrne via CentOS



On Wed, April 24, 2019 11:14, Simon Matter wrote:
>
> I'm afraid too many clouds make the wider horizon invisible :-)
>

At that point it is called fog.


-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

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


Re: [CentOS] Are linux distros redundant?

2019-04-25 Thread Jonathan Billings
On Thu, Apr 25, 2019 at 07:35:53AM -0400, mark wrote:
> On 04/25/19 04:36, Gary Stainburn wrote:
> > On Wednesday 24 April 2019 17:22:13 John R. Dennison wrote:
> > > On Wed, Apr 24, 2019 at 10:18:40AM -0400, mark wrote:
> > > > Nope. Well... actually, my manager's talking about Ubuntu or maybe even
> > > > FreeBSD. He's *extremely* upset with RH being so slow - 8 should have
> > > > been out for some time, for one, and a lot of 7, even with SCL, is far
> > > > behind,
> > > 
> > > It should have been?  Says who?
> > 
> > I may only be guessing, but maybe he was referring to the age of C7. There 
> > is
> > no doubt that C7 is now VERY old software wise.  I've just gone through
> > building a new web server, and have had to use a lot of external 
> > repositories
> > in order to pull in even reasonably new Postgresql / Apache / PHP etc.
> 
> Got it in one - that's exactly why he thinks it should have been out before.

Perhaps you've never seen the Software Collections repositories?
https://wiki.centos.org/AdditionalResources/Repositories/SCL

For what its worth, RHEL8 (and subsequently, CentOS8) will have
Application Streams, which will be somewhat like SCLs, except they'll
be more core to the OS.  That'll let you update software like python,
perl, apache httpd, etc. without interferring with the OS.

https://developers.redhat.com/blog/2018/11/15/rhel8-introducing-appstreams/

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


Re: [CentOS] Are linux distros redundant?

2019-04-25 Thread mark

On 04/25/19 04:36, Gary Stainburn wrote:

On Wednesday 24 April 2019 17:22:13 John R. Dennison wrote:

On Wed, Apr 24, 2019 at 10:18:40AM -0400, mark wrote:

Nope. Well... actually, my manager's talking about Ubuntu or maybe even
FreeBSD. He's *extremely* upset with RH being so slow - 8 should have
been out for some time, for one, and a lot of 7, even with SCL, is far
behind,


It should have been?  Says who?


I may only be guessing, but maybe he was referring to the age of C7. There is
no doubt that C7 is now VERY old software wise.  I've just gone through
building a new web server, and have had to use a lot of external repositories
in order to pull in even reasonably new Postgresql / Apache / PHP etc.


Got it in one - that's exactly why he thinks it should have been out before.

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


Re: [CentOS] : Iptables blocks out going connetion some times

2019-04-25 Thread likun
Yes, I have double checked and am sure there is no IP address conflicts.

Likun

On 4/24/19 23:28, centos wrote:
>On 4/24/19 10:31, likun wrote:
>> Hello, Stephen, thank you for input.
>> 
>> Yes, these servers have the same firewall rules, and both of them have
the same problem from time to time, most of time they are good.
>> 
>> Actually, these servers are newly installed to be used as the Glusterfs
storage server, so not much data flowing at this time.
>
>As a WAG - have you double checked to make sure there aren't any IP
addressing conflicts in play?
___
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] UEFI and PXE

2019-04-25 Thread isdtor
Chris Adams writes:
> Once upon a time, isdtor  said:
> > We have a working PXE setup. I've tried to adapt it to UEFI as per
> > RHEL6 manual, but the client won't boot.
> 
> I have BIOS+UEFI PXE boot set up, although it took some doing.  I still
> use SYSLINUX for BIOS, but GRUB2 plus Red Hat's secure boot shim for
> UEFI.  I never could get SYSLINUX's UEFI support working very well or
> reliably, and it didn't support secure boot at all last I looked.
> 
> I also feed most of the content out via HTTP (much faster than TFTP).
> That includes generating menus on the fly from perl CGIs (I'm
> old-fashioned that way :) ).
> 
> I'm using dnsmasq as my DHCP server, so I have this in its config (where
> pxesrv.cmadams.net has IP 10.10.10.2):

Thanks for the detailed info. But my setup is different. ISC dhcpd is set up as 
per 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/installation_guide/s1-netboot-pxe-config-efi,
 and grub.

next-server points to to the tftp server but seems to be ignored. When the 
client boots, tcpdump reports

09:02:02.911381 IP client.cisco-ipsla > dhcp-server.tftp:  56 RRQ 
"linux-install/bootx64.efi" octet tsize 0 blksize 32768
09:02:02.911403 IP dhcp-server > client: ICMP dhcp-server udp port tftp 
unreachable, length 92

on the dhcp server and nothing on the tftp server. The dhcp server also logs 
that a DHCPOFFER is made and accepted by the client.

This poster had the same problem and it was not resolved.
https://superuser.com/questions/1182862/uefi-mode-pxe-booting-doesnt-work

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


Re: [CentOS] Are linux distros redundant?

2019-04-25 Thread Gary Stainburn
On Wednesday 24 April 2019 17:22:13 John R. Dennison wrote:
> On Wed, Apr 24, 2019 at 10:18:40AM -0400, mark wrote:
> > Nope. Well... actually, my manager's talking about Ubuntu or maybe even
> > FreeBSD. He's *extremely* upset with RH being so slow - 8 should have
> > been out for some time, for one, and a lot of 7, even with SCL, is far
> > behind,
>
> It should have been?  Says who?

I may only be guessing, but maybe he was referring to the age of C7. There is 
no doubt that C7 is now VERY old software wise.  I've just gone through 
building a new web server, and have had to use a lot of external repositories 
in order to pull in even reasonably new Postgresql / Apache / PHP etc.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos