[CentOS] Does centos 6.8 support gstreamer 1.8?
Hi,
I found gstreamer offcial have just announced 1.8.2 version.
("gstreamer.freedesktop.org")
But centos 6 only support gstreamer 0.10. When will centos 6 support gstreamer
1.8?
Thanks!
Regards
Andrew
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Does centos 6.8 support gstreamer 1.8?
On 06/30/2016 09:46 AM, qw wrote:
Hi,
I found gstreamer offcial have just announced 1.8.2 version.
("gstreamer.freedesktop.org")
But centos 6 only support gstreamer 0.10. When will centos 6 support gstreamer
1.8?
When rhel6 does. That means: probably never.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] .NET on Centos.
On 06/28/2016 12:52 PM, Johnny Hughes wrote: > On 06/28/2016 12:17 PM, Peter Q. wrote: >> Hi there, I was reading about it. >> https://www.redhat.com/en/about/blog/net-core-now-available-and-supported-red-hat-enterprise-linux-and-red-hat-openshift >> >> What will happen with Centos and .NET? >> In the side of security and stability. > > That announcement, and this website: > > http://developers.redhat.com/dotnet/ > > Are both Microsoft and Red Hat initiatives / agreements. The .NET being > discussed is in OpenShift containers running on Microsoft's Azure Cloud. > > None of that is currently slated, to the best of my knowledge, to be > rolled into the Base distribution for RHEL. Therefore it is also not > being added into the CentOS Linux distribution. If / when Red Hat does > add things into the base RHEL Server, Workstation, Desktop platforms and > releases the source code for it, we will of course rebuild that source > code and add the resulting software to CentOS Linux. > > Another method of getting things into the CentOS universe is to start a > Special Interest Group that provides optional software to CentOS > repositories (Currently things like Xen support, GlusterFS, Ceph, RDO, > Software Collections, Opennfv, etc). I do not know of any current or > planned .NET SIG for CentOS. There certainly could be one in the future > (if there is interest), or one of the current SIGs might need to bring > in .NET for developing software for their SIG. But I currently know of > no one bringing it in. > > Microsoft has stated that will also make .NET Core available for Ubuntu, > Debian and CentOS Linux. That is not something that I know anything > about right now either. > > The CentOS team certainly welcomes development software like .NET being > provided by the software owner for use on CentOS Linux. I am hearing now that there should be some kind of release of dotnet source code into git.centos.org sometime soon. I don't yet know if it will be code that goes into base CentOS or if it will be code built buy one or more of the Special Interest Groups. When I know more, so will the list. Thanks, Johnny Hughes signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CENTOS ]IPTABLES - How Secure & Best Practice
On Wed, Jun 29, 2016 at 1:49 PM, Gordon Messmer wrote: > > By putting these rules first, before the "ESTABLISHED,RELATED" rule, you're > applying additional processing (CPU time) to the vast majority of your > packets for no reason. The "E,R" rule should be first. It won't match the > invalid packets you're trying to drop. > > You're not specifying the "new" state in any of your input ACCEPT rules, > which means that you're also ACCEPTing invalid packets that don't match the > handful of invalid states you DROPped earlier. > >> 1. The drop commands at the beginning of each chain is for increase >> performance. > > > I understand what you're trying to do, but in the real world, this will > decrease performance. > Gordon, I appreciate your observations. I've been using iptables for a long time and still don't really know how to configure the order of rules to optimize performance while providing thorough filtering as a component of security. Can you share links and/or other sources and guides on this subject. Thank you. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] netbook screen suddenly goes black
On Mon, Jun 20, 2016 at 05:02:32PM -0400, m.r...@5-cent.us wrote: > Fred Smith wrote: > > On Mon, Jun 20, 2016 at 04:13:35PM -0400, m.r...@5-cent.us wrote: > >> Fred Smith wrote: > >> > On Mon, Jun 20, 2016 at 02:59:29PM -0400, Jon LaBadie wrote: > >> >> On Mon, Jun 20, 2016 at 08:58:54AM -0400, Fred Smith wrote: > >> >> > On Mon, Jun 20, 2016 at 01:34:30PM +0300, Александр Кириллов wrote: > > >> > >> Hooold on thar! I came into this thread really late (like, today). > >> You're saying it's fine at work, but not at home? > > > > No. I'm saying it's only happened once since I installed C7, not long > > after it was released. While I haven't kept records of dates and times, > > I don't think it was at any specific time. > > > > I saw it 2 or 3 times previously, probably some Fedora version,... my > > tired old brain won't divulge that info right now. > > > > It seems reasonable that it's some kind of hardware issue but I don't > > see anything in the logs I've thought to check. > > > > I inquired, hoping some of you could suggest other places to look for > > info, in retrospect. > > Ok, then at that point, I like Valery's suggestion. Try looking at > /var/log/Xorg.0.log OK, it just did it again. The system is still up, I just can't do anything on the built-in keyboard/screen, but I CAN use SSH to log in. Doing so, I've captured a bunch of stuff from journalctl that looks like its probably related, which I'll paste in here. I will also go look at the Xorg log files to see if they contain anything further of interest. [later: xorg.0.log doesn't contain anything that appears related to this failure. the last thing in it is recognition of the USB wireless mouse I had plugged in some minutes prior to the failure (10-30 minutes, as best I can recall). It's hard to tell what is going on since Xorg.0.log does not display the actual time the reported events occurred.] BTW, this is Centos-7, probably up to date, or at least if not, no more than a few days from there, running kernel 3.10.0-327.18.2.el7.x86_64. This system has some generic Intel video chipset, and is an Atom N570, dual core, 64-bit processor, running at a _screaming_ 1.6 GHz. Oh my! :) I'm looking around in /proc to see if I can find out which generation of Intel video it has. I don't see it in /proc/cpuinfo, can someone advise me where to look for this info? LATER: this site: http://www.cpu-world.com/CPUs/Atom/Intel-Atom%20N570.html says its graphics engine is GMA-3150. lsmod shows that we have the i915 module loaded (is that correct for a GMA-3150 graphics chipset?) along with drm_kms_helper and drm. I'll let it stay in its current (broken) state for a while in case any of you smart guys can suggest other places to look, or things to look for. thanks in advance! here's an excerpt from journalctl: Jun 30 12:47:49 aspirebox.fcshome.stoneham.ma.us kernel: [ cut here ] Jun 30 12:47:49 aspirebox.fcshome.stoneham.ma.us kernel: WARNING: at drivers/gpu/drm/drm_irq.c:1141 drm_wait_one_vblank+0x19e/0x1b0 [drm]() Jun 30 12:47:49 aspirebox.fcshome.stoneham.ma.us kernel: vblank wait timed out on crtc 1 Jun 30 12:47:49 aspirebox.fcshome.stoneham.ma.us kernel: Modules linked in: rfcomm fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun ccm nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter bnep arc4 ath9k ath9k_common ath9k_hw ath coretemp uvcvideo kvm mac80211 btusb videobuf2_vmalloc videobuf2_memops videobuf2_core videodev snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec cfg80211 bluetooth snd_hda_core snd_hwdep snd_seq snd_seq_device Jun 30 12:47:49 aspirebox.fcshome.stoneham.ma.us kernel: acer_wmi iTCO_wdt sparse_keymap snd_pcm iTCO_vendor_support snd_timer rfkill snd sg wmi i2c_i801 pcspkr soundcore shpchp lpc_ich mfd_core acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables ext4 mbcache jbd2 dm_crypt drbg xts gf128mul sd_mod crc_t10dif crct10dif_generic crct10dif_common i915 i2c_algo_bit drm_kms_helper ahci libahci drm libata serio_raw i2c_core atl1c video dm_mirror dm_region_hash dm_log dm_mod Jun 30 12:47:49 aspirebox.fcshome.stoneham.ma.us kernel: CPU: 0 PID: 3165 Comm: X Not tainted 3.10.0-327.22.2.el7.x86_64 #1 Jun 30 12:47:49 aspirebox.fcshome.stoneham.ma.us kernel: Hardware name: Acer AOD255E/JE02_PT_E, BIOS V3.16(DDR3) 04/22/2011 Jun 30 12:47:49 aspirebox.fcshome.stoneham.ma.us kernel: 880077c1b7c8 623d88bd 880077c1b780 816360fc Jun 30 12:47:49 aspirebox.fcshome.stoneham.ma.us kernel: 880077c1b7b8 8107b200 88007775f800 00
Re: [CentOS] [CENTOS ]IPTABLES - How Secure & Best Practice
On 30/06/16 18:49, Mike wrote: On Wed, Jun 29, 2016 at 1:49 PM, Gordon Messmer wrote: By putting these rules first, before the "ESTABLISHED,RELATED" rule, you're applying additional processing (CPU time) to the vast majority of your packets for no reason. The "E,R" rule should be first. It won't match the invalid packets you're trying to drop. You're not specifying the "new" state in any of your input ACCEPT rules, which means that you're also ACCEPTing invalid packets that don't match the handful of invalid states you DROPped earlier. 1. The drop commands at the beginning of each chain is for increase performance. I understand what you're trying to do, but in the real world, this will decrease performance. Gordon, I appreciate your observations. I've been using iptables for a long time and still don't really know how to configure the order of rules to optimize performance while providing thorough filtering as a component of security. Can you share links and/or other sources and guides on this subject. Thank you. Hi Mike, If I may reply... The premise is simple, rules are located in chains. Chains of rules are evaluated from top to bottom, until the packet being evaluated matches a rule. You want to order your rules so that packets pass through as few rules as possible, i.e they are matched and either accepted or rejected as soon as possible. Each time a packet is evaluated against a rule it is using CPU cycles, so the fewer the better. Of course the number of rules evaluated will depend on the packet. For example, if you run a mail server receiving 1,000 emails per day, a web server with 10,000 hits per day and a DNS server with 100,000 queries per day, it makes sense to order your rules to accept the DNS queries first, followed by http traffic, and to accept the smtp traffic last. This ordering would cause 111,000 packets to be evaluated by the first rule, 11,000 by the second rule and 1,000 by the third rule giving a total of 123,000 times a packet was inspected by a rule. If we reversed the order we would see 111,000 for our first rule, 110,000 for our second rule and 100,000 for our third rule, giving a total of 321,000 examinations which is 2.6 times more than our first example. Don't forget it's only the initial (first) packet of each connection that is passing down through our chain of rules - all subsequent packets would be matched against our Established,Related SPI rule which is typically placed at the very top of the chain so our firewall doesn't have to examine every packet of that 100MB email you just received in the same way as it examines the first packet. This is the rule that will always by far match the most packets hence why it's always placed near or at the top of the chain. This is a very simplistic approach but you get the idea. As things get more complicated, you can create user-defined chains to filter off certain traffic for further examination, maybe logging action and/or rate-limiting, rather than subjecting all packets to that extra scrutiny where it is not applicable thus improving the overall efficiency. You want to make the flow of packets through the firewall as efficient as possible. This approach is only really needed where you want a given packet to be evaluated by two or more rules (e.g, log the packet then drop it). In reality most modern hardware is more than capable of achieving throughput that isn't going to be rate limiting even with quite complex rule sets, but we all like to optimise stuff anyway don't we :-) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] OT: hardware, MegaRAID SAS 2008 (falcon)
I've been googling, and haven't yet found the answer: does anyone here know if a MegaRAID SAS 2008 (falcon) (rev 03) can handle drives bigger than 2TB? mark ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT: hardware, MegaRAID SAS 2008 (falcon)
On Thu, June 30, 2016 2:59 pm, m.r...@5-cent.us wrote: > I've been googling, and haven't yet found the answer: does anyone here > know if a MegaRAID SAS 2008 (falcon) (rev 03) can handle drives bigger > than 2TB? > One way to find out is to plug 4TB drive and take a look. Another is to ask one who has the same controller to do the same for you. I am going to play with similar on one of my machine, but it sounds like my controller is different: in my case lspci gives me: 01:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04 ) Subsystem: Dell PERC 6/i Integrated RAID Controller Sorry, can't answer the question, only what I would do - just my poor experientalist's approach... Valeri 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: hardware, MegaRAID SAS 2008 (falcon) [SOLVED]
Valeri Galtsev wrote: > > On Thu, June 30, 2016 2:59 pm, m.r...@5-cent.us wrote: >> I've been googling, and haven't yet found the answer: does anyone here >> know if a MegaRAID SAS 2008 (falcon) (rev 03) can handle drives bigger >> than 2TB? > > One way to find out is to plug 4TB drive and take a look. Another is to > ask one who has the same controller to do the same for you. I am going to > play with similar on one of my machine, but it sounds like my controller > is different: in my case lspci gives me: Yeah, I know. Thanks - unfortunately, their hot-swap drive bays are full. However, after I posted it, it finally percolated through my brain that they were still under warranty (5 yrs is what we buy), so I just called Dell, and am told they'll do 4TBs. Now, that, I assume, means they'll take larger, but he's researching it for me to be sure. mark ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CENTOS ]IPTABLES - How Secure & Best Practice
Ned, Thank you very much for the response. Great example following through on the premise. It sounds like I need to have a better understanding of the traffic patterns on my network to know the optimal order for iptables filtering rules. My brief example - Premise: I want to limit outsiders from interfering with LAN client machines. So, I have the following rules regarding forwarding traffic: -A FORWARD -m state --state INVALID -j DROP -A FORWARD -p tcp --tcp-flags ACK,FIN FIN -j DROP -A FORWARD -p tcp --tcp-flags ACK,PSH PSH -j DROP -A FORWARD -p tcp --tcp-flags ACK,URG URG -j DROP -A FORWARD -p tcp --tcp-flags FIN,RST FIN,RST -j DROP -A FORWARD -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP -A FORWARD -p tcp --tcp-flags SYN,RST SYN,RST -j DROP -A FORWARD -p tcp --tcp-flags ALL ALL -j DROP -A FORWARD -p tcp --tcp-flags ALL NONE -j DROP -A FORWARD -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP -A FORWARD -p tcp --tcp-flags ALL SYN,FIN,PSH,URG -j DROP -A FORWARD -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT -A FORWARD -i LAN-NIC -s 10.100.100.0/24 -o INET-NIC -m state --state NEW -j ACCEPT -A FORWARD -i INET-NIC -o LAN-NIC -d 10.100.100.0/24 -m state --state NEW -j ACCEPT But I don't know if this is interfering with, or delaying DNS requests between LAN clients and the DHCP server. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Does centos 6.8 support gstreamer 1.8?
On Thu, Jun 30, 2016 at 03:46:49PM +0800, qw wrote:
> Hi,
>
> I found gstreamer offcial have just announced 1.8.2 version.
> ("gstreamer.freedesktop.org")
>
> But centos 6 only support gstreamer 0.10. When will centos 6 support
> gstreamer 1.8?
>
I've no idea, but my centos7 system has both
gstreamer (ver. 0.10) and gstreamer1 (ver. 1.4.5).
jl
--
Jon H. LaBadie j...@jgcomp.com
11226 South Shore Rd. (703) 787-0688 (H)
Reston, VA 20190 (703) 935-6720 (C)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT: hardware, MegaRAID SAS 2008 (falcon) [SOLVED]
On Thu, June 30, 2016 4:38 pm, m.r...@5-cent.us wrote: > Valeri Galtsev wrote: >> >> On Thu, June 30, 2016 2:59 pm, m.r...@5-cent.us wrote: >>> I've been googling, and haven't yet found the answer: does anyone here >>> know if a MegaRAID SAS 2008 (falcon) (rev 03) can handle drives bigger >>> than 2TB? >> >> One way to find out is to plug 4TB drive and take a look. Another is to >> ask one who has the same controller to do the same for you. I am going >> to >> play with similar on one of my machine, but it sounds like my controller >> is different: in my case lspci gives me: > > Yeah, I know. Thanks - unfortunately, their hot-swap drive bays are full. > However, after I posted it, it finally percolated through my brain that > they were still under warranty (5 yrs is what we buy), so I just called > Dell, and am told they'll do 4TBs. Now, that, I assume, means they'll take > larger, but he's researching it for me to be sure. > With larger drives, say 8 TB, you may want to pay attention to drive format (namely, 4Kn may be not supported by that particular controller). Just my $0.02. Valeri 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 update glib-2.28.8 to glib-2.40.0 or newer version
Hi, I'm trying to build gstreamer sdk on centos 6.7. When configure is run for 'gstreamer-1.8.2.tar.xz' on centos 6.7, error messages are reported as below: checking for GLIB... no configure: Requested 'glib-2.0 >= 2.40.0' but version of GLib is 2.28.8 configure: error: This package requires GLib >= 2.40.0 to compile. The command of 'yum install glib*' can only update glib to glib-2.28.8. How to update glib to the version of >=2.40.0 on centos 6.7? Thanks! Regards Andrew ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CENTOS ]IPTABLES - How Secure & Best Practice
On 30/06/16 23:19, Mike wrote: Ned, Thank you very much for the response. Great example following through on the premise. It sounds like I need to have a better understanding of the traffic patterns on my network to know the optimal order for iptables filtering rules. Try running: iptables -nv -L which will show you in the left hand column a counter for the number of packets that has matched each rule. That will give you an exact breakdown of how often your rules are being hit. My brief example - Premise: I want to limit outsiders from interfering with LAN client machines. So, I have the following rules regarding forwarding traffic: -A FORWARD -m state --state INVALID -j DROP -A FORWARD -p tcp --tcp-flags ACK,FIN FIN -j DROP -A FORWARD -p tcp --tcp-flags ACK,PSH PSH -j DROP -A FORWARD -p tcp --tcp-flags ACK,URG URG -j DROP -A FORWARD -p tcp --tcp-flags FIN,RST FIN,RST -j DROP -A FORWARD -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP -A FORWARD -p tcp --tcp-flags SYN,RST SYN,RST -j DROP -A FORWARD -p tcp --tcp-flags ALL ALL -j DROP -A FORWARD -p tcp --tcp-flags ALL NONE -j DROP -A FORWARD -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP -A FORWARD -p tcp --tcp-flags ALL SYN,FIN,PSH,URG -j DROP -A FORWARD -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT -A FORWARD -i LAN-NIC -s 10.100.100.0/24 -o INET-NIC -m state --state NEW -j ACCEPT -A FORWARD -i INET-NIC -o LAN-NIC -d 10.100.100.0/24 -m state --state NEW -j ACCEPT The first thing I would do is move your ESTABLISHED,RELATED rule to the top of the chain. Once you've accepted the first packet you may as well accept the rest of the stream as quickly and efficiently as possible as you've established the connection is not malicious. What is the default policy for the FORWARD table? Assuming it is accept then the last two accept rules can be removed. But I don't know if this is interfering with, or delaying DNS requests between LAN clients and the DHCP server. The FORWARD chain only processes packets being router through the machine, so in your case that would be packets from the lan destined for the wan, or packets from the wan destined to the lan. All internal lan traffic such as dns requests from clients to the dchp server are internal and not subject to the FORWARD chain. Of course the dhcp server probably forwards those dns requests to a dns server outside of the lan so those requests will pass through the FORWARD chain at that point. Assuming your hardware is not crippled or the cpu constantly overloaded, it's not going to have any problems routing traffic through your rule set. But if you want to ensure particular traffic is processed quickly and bypasses all other rules, place a rule matching it near the top to accept that traffic. For example, if you trust all traffic coming from inside your network that is destined for the outside and want to pass that traffic without testing for all those tcp flags (and any other rules), you could do something like: -A Forward -p all -i LAN-NIC -o INET-NIC -j ACCEPT ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Securing RPC
Dear Community I hope you are all doing well. Recently I have been receiving several complaints from our service provider. Please see the complaint below: A public-facing device on your network, running on IP address XXX.XXX.XXX.XXX, operates a RPC port mapping service responding on UDP port 111 and participated in a large-scale attack against a customer of ours, generating responses to spoofed requests that claimed to be from the attack target. Please consider reconfiguring this server in one or more of these ways: 1. Adding a firewall rule to block all access to this host's UDP port 111 at your network edge (it would continue to be available on TCP port 111 in this case). 2. Adding firewall rules to allow connections to this service (on UDP port 111) from authorized endpoints but block connections from all other hosts. 3. Disabling the port mapping service entirely (if it is not needed). Unfortunately, I cannot disable NFS which lies at the root of this problem. In addition, I am struggling to find a proper tutorial of moving NFS from udp over to tcp. May I kindly ask you to point me in a direction or provide me with ideas on how to nail this thing in the Kind Regards Leon ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Securing RPC
Are you really exposing portmapper (RPC) and NFS to public network? Eero 2016-07-01 9:38 GMT+03:00 Leon Vergottini : > Dear Community > > I hope you are all doing well. > > Recently I have been receiving several complaints from our service > provider. Please see the complaint below: > > A public-facing device on your network, running on IP address > XXX.XXX.XXX.XXX, operates a RPC port mapping service responding on UDP port > 111 and participated in a large-scale attack against a customer of ours, > generating responses to spoofed requests that claimed to be from the attack > target. > > Please consider reconfiguring this server in one or more of these ways: > > 1. Adding a firewall rule to block all access to this host's UDP port 111 > at your network edge (it would continue to be available on TCP port 111 in > this case). > 2. Adding firewall rules to allow connections to this service (on UDP port > 111) from authorized endpoints but block connections from all other hosts. > 3. Disabling the port mapping service entirely (if it is not needed). > > > > Unfortunately, I cannot disable NFS which lies at the root of this > problem. In addition, I am struggling to find a proper tutorial of moving > NFS from udp over to tcp. > > May I kindly ask you to point me in a direction or provide me with ideas on > how to nail this thing in the > > Kind Regards > Leon > ___ > 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
