search for: enp5s0

...y that bought the software $15k (no kidding) so that they can shift the license to the new workstation, and that's tied to eth0 and the MAC. And *why* random NIC names? Quick, you've got servers from 5 manufacturers, of different ages... what's the NIC going to be called? Do names like enp5s0 offer any convenience to *anyone* not a hardware engineer? And the binary message log.... At home, I'm staying on CentOS 6 until it EoLs. mark

https://bugzilla.mindrot.org/show_bug.cgi?id=3161 Bug ID: 3161 Summary: ssh -J <public IPv6> <LL IPv6%scopeID> doesn't work as expected Product: Portable OpenSSH Version: 8.2p1 Hardware: 68k OS: Mac OS X Status: NEW Severity: enhancement Priority: P5

On Tue, Apr 11, 2017 at 08:09:01AM -0400, Pete Orrall wrote: > > And *why* random NIC names? Quick, you've got servers from 5 > > manufacturers, of different ages... what's the NIC going to be called? Do > > names like enp5s0 offer any convenience to *anyone* not a hardware > > engineer? > > As someone else had stated, it's not related to SystemD but > Fedora/RHEL has changed the way they handle some things. NICs, for > instance, are no longer named after the device number (eth0, eth1, > eth2,...

...;/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x0f' slot='0x00' function='0x0'/> </interface> # virsh start rhel Domain rhel started 2. login guest and check the interfaces: # ip addr ... 2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 00:0c:29:e7:9b:cb brd ff:ff:ff:ff:ff:ff inet 192.168.122.142/24 brd 192.168.122.255 scope global dynamic noprefixroute enp5s0 valid_lft 3584sec preferred_lft 3584sec inet6...

Hi, I haven't been to find this (NetworkManager) change documented. On: CentOS Linux release 7.1.1503 (Core) $ /bin/nmcli con NAME UUID TYPE DEVICE ens32 7629e52d-bd42-4cd5-a424-8c58e7e0bf37 802-3-ethernet ens32 On: CentOS Linux release 7.2.1511 (Core) $ /bin/nmcli con NAME UUID TYPE

...an/listinfo/centos > I don't see 'System' in any of the CentOS 7.2.1511 boxes or VMs that were recently upgraded: /bin/nmcli con NAME UUID TYPE DEVICE virbr0 ccd9a252-0765-4e88-bb5d-bfc34eb278e3 bridge virbr0 enp5s0 ccbafeb6-ce6c-4713-b1ac-2cd0705bf16e 802-3-ethernet enp5s0 docker0 a4d7d1e6-0eb2-47d7-8c7e-b63cdc9d8f8d bridge docker0 virbr1-nic 9de87ba3-5c90-490a-b7f1-e273b0525fac generic virbr1-nic virbr1 0638f08b-b6c9-4e66-aee2-f64f2764ecf4 bridge virbr1 virbr0-nic...

...<LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 90:2b:34:68:84:c0 brd ff:ff:ff:ff:ff:ff inet 192.168.1.8/24 brd 192.168.1.255 scope global enp5s0 valid_lft forever preferred_lft forever inet6 fe80::922b:34ff:fe68:84c0/6...

https://bugzilla.mindrot.org/show_bug.cgi?id=2578 Bug ID: 2578 Summary: -W should honor -4 and -b Product: Portable OpenSSH Version: 7.2p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org

...; $15k (no kidding) so that they can shift the license to the new > workstation, and that's tied to eth0 and the MAC. > > And *why* random NIC names? Quick, you've got servers from 5 > manufacturers, of different ages... what's the NIC going to be called? Do > names like enp5s0 offer any convenience to *anyone* not a hardware > engineer? Unrelated to systemd. This actually started happening in RHEL6 with the biosdevname feature. systemd can handle the NIC naming stuff, but it started happening well before systemd appeared in RHEL. Having consistent device names is...

> And *why* random NIC names? Quick, you've got servers from 5 > manufacturers, of different ages... what's the NIC going to be called? Do > names like enp5s0 offer any convenience to *anyone* not a hardware > engineer? As someone else had stated, it's not related to SystemD but Fedora/RHEL has changed the way they handle some things. NICs, for instance, are no longer named after the device number (eth0, eth1, eth2, etc.) but after the *driver*...

.../2017 05:30 AM, Jonathan Billings wrote: > On Tue, Apr 11, 2017 at 08:09:01AM -0400, Pete Orrall wrote: >>> And *why* random NIC names? Quick, you've got servers from 5 >>> manufacturers, of different ages... what's the NIC going to be called? Do >>> names like enp5s0 offer any convenience to *anyone* not a hardware >>> engineer? >> >> As someone else had stated, it's not related to SystemD but >> Fedora/RHEL has changed the way they handle some things. NICs, for >> instance, are no longer named after the device number (eth0...

...wrote: >> On Tue, Apr 11, 2017 at 08:09:01AM -0400, Pete Orrall wrote: >>>> And *why* random NIC names? Quick, you've got servers from 5 >>>> manufacturers, of different ages... what's the NIC going to be >>>> called? Do >>>> names like enp5s0 offer any convenience to *anyone* not a hardware >>>> engineer? >>> >>> As someone else had stated, it's not related to SystemD but >>> Fedora/RHEL has changed the way they handle some things. NICs, for >>> instance, are no longer named after the...

Jonathan Billings wrote: <snip> >> And *why* random NIC names? Quick, you've got servers from 5 >> manufacturers, of different ages... what's the NIC going to be called? >> Do names like enp5s0 offer any convenience to *anyone* not a hardware >> engineer? > > Unrelated to systemd. This actually started happening in RHEL6 with > the biosdevname feature. systemd can handle the NIC naming stuff, but > it started happening well before systemd appeared in RHEL. > > Ha...

Hi, what does Centos 7 do with UPD packets having invalid checksums? Are such packets inevitably dropped? Does a network card drop them when it does checksum verification in hardware even before the packets go anywhere? In general, if someone were to send me UPD packets with invalid checksums over the internet, how far would such packets get? In particular, how likely it is that SRTP

...roup membership. Server role: ROLE_DOMAIN_PDC # Global parameters [global] add machine script = /usr/sbin/samba-add-machine "%u" bind interfaces only = Yes domain logons = Yes domain master = Yes guest account = guest interfaces = lo enp5s0 ldap admin dn = cn=manager,ou=Internal,dc=howitts,dc=co,dc=uk ldap connection timeout = 8 ldap group suffix = ou=Groups,ou=Accounts ldap idmap suffix = ou=Idmap ldap machine suffix = ou=Computers,ou=Accounts ldap ssl = no ldap suffix =...

...h0 If it was so easy: Features for bond0: rx-checksumming: off [fixed] tx-checksumming: on tx-checksum-ipv4: off [fixed] tx-checksum-ip-generic: on tx-checksum-ipv6: off [fixed] tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] Features for enp5s0: rx-checksumming: on tx-checksumming: on tx-checksum-ipv4: off [fixed] tx-checksum-ip-generic: on tx-checksum-ipv6: off [fixed] tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] Both physical interfaces show the same. But does this mean it...

...xr-x 1 root root 282616 May 4 04:08 /bin/ip ostara ~ # ifconfig -a | grep "^[a-z]" br0: flags=4355<UP,BROADCAST,PROMISC,MULTICAST> mtu 1500 br1: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500 enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 enp5s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 enp6s2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ostara ~ # virsh -c lxc:/// dumpxml dwj-hfax-dev <domain...

...9b:23:fb:14:5f txqueuelen 0 (Ethernet) enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255 ether bc:ae:c5:16:6f:3b txqueuelen 1000 (Ethernet) device interrupt 18 memory 0xfade0000-fae00000 enp5s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet xx.xx.xx.xx netmask 255.255.252.0 broadcast xx.xx.xx.xx ether bc:ae:c5:16:70:3f txqueuelen 1000 (Ethernet) device interrupt 19 memory 0xfaee0000-faf00000 enp6s2: flags=4163<UP,BROADCAST,RUNNING,MULTICA...

https://bugs.freedesktop.org/show_bug.cgi?id=90482 Bug ID: 90482 Summary: Xorg take 100% CPU when using multiple independent screen configuration Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium

Il 31/07/20 13:08, ja ha scritto: > On Fri, 2020-07-31 at 22:35 +1200, Alan McRae via CentOS wrote: >> I am running an Intel x64 machine using UEFI to boot an SSD. >> >> Installing the latest yum update which includes grub2 and kernel >> 4.18.0-193.14.2.el8_2.x86_64 renders the machine unbootable, blank >> screen where grub should be, no error messages, just hangs.