Re: [389-users] ACL processing
On 02/28/2014 01:31 AM, Rich Megginson wrote: On 02/27/2014 05:06 PM, Russell Beall wrote: Thanks again for your comments on this. I tried an alternate approach in which I deleted a number of relevant indexes that theoretically should be needed all across the ACIs. I was shocked to find out that the processing time was totally unaffected. Then I took it a step further and deleted all of our custom indexes. Then even further to delete uniquemember and uid indexing. Again, performance was unaffected, and the results of ACI filtering still seem to be accurate. It seems this means that the ACI processing is not correctly using the indexes, or I didn't create them properly. Aci processing is done per entry, so you already have looked up all the entries (which could use some indexes) and now perform evaluation on a single entry. If you have acis with groupdns and you have very large groups the check if the bound user is a member of th egroup can become a severe performance problem It could mean 1) the aci performance is not related to indexing 2) we don't know what indexes it is using I have run db2index.pl and it successfully reprocessed the entire set of indexes. I also ran dbverify to successful completion. I can tell that the indexes are being used in simple searches (based on the fact that I get the Administrative Limit Exceeded error when there is no index). Does this information point to anything that I should look into further? If the aci processing is doing internal searches that don't show up in logconv.pl, then turning on access logging for internal searches should show those unindexed internal searches, which should show up using logconv.pl Thanks, Russ. On Feb 27, 2014, at 1:19 PM, Rich Megginson rmegg...@redhat.com mailto:rmegg...@redhat.com wrote: On 02/27/2014 12:49 PM, Russell Beall wrote: Hi Rich, Thanks for the data. I've been continuing to experiment and work on this and especially making sure that everything that might be used in the ACIs is indexed. All the indexes appear to be in order, but I am confused by one thing… It looks like there is no entryDN index and only an entryrdn index. Correct. This new format will be fully workable for complicated dn lookups in the ACIs, correct? (We have a lot of groupdn= and userdn= restrictions). Correct. groupdn= and userdn= do not use the entrydn index. There is no one single ACI which degrades performance, but I did notice that when adding back in certain of the ACIs, performance does degrade quicker than should be expected just for the cost of processing only one additional ACI. I believe there may definitely be a problem with the indexes as you suggested but It is hiding well... You could enable access logging of internal operations. https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnconfig-nsslapd_accesslog_level An additional symptom which may point to a server configuration problem is a strange inability to import or reindex quickly. My small dev VM can import several hundred entries at a time, but this server will only import or reindex at a rate of 18-30 records per second. I've ensured that there is plenty of import memory as well as cachememsize which should enable a very speedy import, but even though all 32 cores are burning bright, the import speed seems incredibly slow. (This is of course after all indexes are created and it is trying to index while importing. Import speed with no indexes is fairly fast). Any obvious clues I'm missing? No, not sure what's going on. Thanks, Russ. On Feb 19, 2014, at 4:08 PM, Rich Megginson rmegg...@redhat.com mailto:rmegg...@redhat.com wrote: On 02/19/2014 04:56 PM, Russell Beall wrote: Hi all, We've just set up monster-sized server nodes to run 389 as a replacement to Sun DS. I've been running my tests and I am pleased to report that the memory issue seems to be in check with growth only up to double the initial memory usage after large quantities of ldapmodify calls. We have plenty of room in these boxes to accommodate caching the entire database. The key blocker on this is still the ACL processing times for which I have been unable to find a decent resolution. We have 135 ACIs at the root of the suffix. When I comment out most of them but leave one service account active, processing times are very nicely fast. When I leave them all on, that same service account takes 2.5 seconds to respond when only one request is pending. A new kink in the puzzle here which is probably going to be a deal breaker is that if I run the same request on multiple threads, each thread takes proportionately longer to respond depending on the number of threads. If I have 12 threads going doing a simple lookup, each thread responds in 45-55 seconds. If I have 24 threads going, each
Re: [389-users] Synchronizing with Active Directory
On 02/28/2014 12:46 PM, Riss Nicolas wrote: Hi, We are making some test in order to synchronize 389 Directory with an Active Directory. We don’t install pass sync because we need only to synchronize password from the 389 Directory instance. Everything works well, but when we analyze the user on Active Directory that were synchronized from the 389 Directory, we notice that the AccountUserControl value was 544, that’s mean NORMAL ACCOUNT + PASSWD_NOTREQD. Due to security reason it is not acceptable for us, at least it must be 514 (only NORMAL_ACCOUNT). We search a way to modify this behavior, but we cannot find anything. Is there any way to force this value for new user synchronize to the Active Directory ? No. Please file a ticket at https://fedorahosted.org/389/newticket OS : CentOS 6.5 389 Directory version : 389-Directory/1.2.11.15 B2013.357.177 Active Directory on Windows 2008R2 Thanks. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] ACL processing
Yes. Many rules are groupdn based, sometimes with multiple rules where the dn must be in some groups but not in others. And some of the groups have 50,000-100,000+ members. Breaking out the groupdn checks into something very simple did not change the performance at all. Changing all the targetfilter checks to something simple very significantly affected performance. This has led me to finally discover the true bottleneck in the indexing of one particular attribute. The attribute is a custom attribute similar to memberOf. When converting from SJES I took the syntax, which was DN syntax, and modified the matching rule in the schema into distinguishedNameMatch. So the index of this attribute was constructed based on that. Apparently even though the values are DN values (almost all of them), this particular index type must be incompatible. When I switched from distinguishedNameMatch to caseExactMatch, performance improved drastically (I'm now switching to caseIgnoreMatch to see how that fares). Now we are on par with the old Sun servers and no longer clogging up when many threads are running simultaneously. Thank you so much, Rich and Ludwig, for helping me dig through this! Thanks, Russ. On Feb 28, 2014, at 12:50 AM, Ludwig Krispenz lkris...@redhat.commailto:lkris...@redhat.com wrote: It seems this means that the ACI processing is not correctly using the indexes, or I didn't create them properly. Aci processing is done per entry, so you already have looked up all the entries (which could use some indexes) and now perform evaluation on a single entry. If you have acis with groupdns and you have very large groups the check if the bound user is a member of th egroup can become a severe performance problem It could mean 1) the aci performance is not related to indexing 2) we don't know what indexes it is using I have run db2index.pl and it successfully reprocessed the entire set of indexes. I also ran dbverify to successful completion. I can tell that the indexes are being used in simple searches (based on the fact that I get the Administrative Limit Exceeded error when there is no index). Does this information point to anything that I should look into further? If the aci processing is doing internal searches that don't show up in logconv.pl, then turning on access logging for internal searches should show those unindexed internal searches, which should show up using logconv.pl Thanks, Russ. On Feb 27, 2014, at 1:19 PM, Rich Megginson rmegg...@redhat.commailto:rmegg...@redhat.com wrote: On 02/27/2014 12:49 PM, Russell Beall wrote: Hi Rich, Thanks for the data. I've been continuing to experiment and work on this and especially making sure that everything that might be used in the ACIs is indexed. All the indexes appear to be in order, but I am confused by one thing… It looks like there is no entryDN index and only an entryrdn index. Correct. This new format will be fully workable for complicated dn lookups in the ACIs, correct? (We have a lot of groupdn= and userdn= restrictions). Correct. groupdn= and userdn= do not use the entrydn index. There is no one single ACI which degrades performance, but I did notice that when adding back in certain of the ACIs, performance does degrade quicker than should be expected just for the cost of processing only one additional ACI. I believe there may definitely be a problem with the indexes as you suggested but It is hiding well... You could enable access logging of internal operations. https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnconfig-nsslapd_accesslog_level An additional symptom which may point to a server configuration problem is a strange inability to import or reindex quickly. My small dev VM can import several hundred entries at a time, but this server will only import or reindex at a rate of 18-30 records per second. I've ensured that there is plenty of import memory as well as cachememsize which should enable a very speedy import, but even though all 32 cores are burning bright, the import speed seems incredibly slow. (This is of course after all indexes are created and it is trying to index while importing. Import speed with no indexes is fairly fast). Any obvious clues I'm missing? No, not sure what's going on. Thanks, Russ. On Feb 19, 2014, at 4:08 PM, Rich Megginson rmegg...@redhat.commailto:rmegg...@redhat.com wrote: On 02/19/2014 04:56 PM, Russell Beall wrote: Hi all, We've just set up monster-sized server nodes to run 389 as a replacement to Sun DS. I've been running my tests and I am pleased to report that the memory issue seems to be in check with growth only up to double the initial memory usage after large quantities of ldapmodify calls. We have plenty of room in these boxes to accommodate caching the entire database. The key blocker on
Re: what just happened (time went backwards?)
On 02/28/2014 12:54 AM, Chris Murphy wrote: On Feb 27, 2014, at 12:28 PM, Lars E. Pettersson l...@homer.se wrote: On 02/26/14 19:23, lee wrote: What is the purpose of this log duplication? When systemd has its own logs, it doesn´t seem necessary to duplicate them by sending their contents to syslogd. One could also ask why systemd duplicates the logging formerly only done by syslogd. This has been answered many times already, it's an old argument. That was not my point of argument. For me looking through my ASCII-based text-logs created by syslogd is far faster than using journalctl. Things that takes over 25 minutes with journalctl, only takes 66 seconds grepping the syslogd logs. (see bug 1047719, that no-one seems to care about) Why are the logs so large? Each log file I have is either 8MB, 16MB, or maximum 24MB. So somehow yours are getting very large before they are turned over. Also do you normally search all logs for all time? Or are you searching in the most recent boot? You can use journalctl -b -1 to search the last boot, -2 the one before that. It can be done using --since with a date to encompass multiple boots yet not all boots. There is also -u to filter by unit. If you have journalctl do some filtering in advance then not so much stuff is dumped into grep to filter. Why the journal is 4GB? Have no idea, perhaps you could enlighten me? The syslogd created text files are only using about 700MB of space for the same duration. The problem is not the size of the text files, the problem is that systemd/journalctl is extremely sluggish when the journal is big. If it takes 20-25 minutes to get the same information from journalctl, when it takes about 1 minute going through all syslogd created text-files for the same duration, then something is utterly wrong with how the journal works, and if it (the journal) is supposed to replace the syslogd generated text files, it has to be at least equally fast to be usable. Also note that this sluggishness creates problem for the 'systemctl status' command, which is a really bad thing. Using -b, --since, etc. is not the point, the point is the sluggishness shown when the journal is big. ASCII-based logs can be read by anybody using any editor. To read the journal you need journalctl, or similar program, as the journal is binary and not readily readable. It's fine to want plain logs but that is a subset of the amount of information the journal can only retain with binary including checksumming so the logs can be verified, and universal time/date stamping that causes journalctl to report the even in local time even if the server is not local, the list of things that can be done are unlimited. So the superset log is a necessity in any case and if the plain text rsyslog is meeting your needs then why would you bother with journalctl at all? That is all fine and dandy, but does not change the fact that a text file can be read by anyone. The journal needs programs of some sort to be read. Another reason is that there still exist programs/daemons/etc. that rely on the logs in /var/log. If you do not like syslogd, well F20 does not ship it anymore… I think the repo has both rsyslog and syslog-ng. That does not change the fact that the F20 install has dameons etc. that actually relies on a present MTA and/or the syslog daemon. Lars -- Lars E. Pettersson l...@homer.se http://www.sm6rpz.se/ -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: what just happened (time went backwards?)
On Fri, Feb 28, 2014 at 8:54 AM, Chris Murphy li...@colorremedies.com wrote: On Feb 27, 2014, at 12:28 PM, Lars E. Pettersson l...@homer.se wrote: On 02/26/14 19:23, lee wrote: What is the purpose of this log duplication? When systemd has its own logs, it doesn´t seem necessary to duplicate them by sending their contents to syslogd. One could also ask why systemd duplicates the logging formerly only done by syslogd. This has been answered many times already, it's an old argument. It's an old argument because someone who is scared of the argument is trying to define it away. [...] It's fine to want plain logs but that is a subset of the amount of information the journal can only retain with binary including checksumming so the logs can be verified, and universal time/date stamping that causes journalctl to report the even in local time even if the server is not local, the list of things that can be done are unlimited. So the superset log is a necessity in any case and if the plain text rsyslog is meeting your needs then why would you bother with journalctl at all? Every time I see a defense of systemd and its spawn, I see this kind of bunk. If information can be logged in binary form, it can be logged in human readable form. It's just a matter of pushing the data through appropriate filters, that's all. The real problem with logs is what to retain and what to strip out. And logs that can't be directly read by humans are not worth the having. Nobody will read them until long after the bad things happened and left the system corrupted. Enforced universalism is the last thing we want computers for. [...] -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Hard Freezes with F20 on Lenovo ThinkPad T430
On 02/27/2014 03:18 PM, Joe Zeff wrote: On 02/27/2014 01:15 PM, Kevin Martin wrote: On 02/27/2014 02:40 PM, Joe Zeff wrote: On 02/27/2014 11:32 AM, Kevin Martin wrote: I find that I can't run with acceleration turned on with the nouveau driver at all and I've been loathe to try the nVidia driver again since I update the kernel fairly often using rawhide and rpmfusion doesn't tend to keep up. Just install akmod-nvidia and it will build a new kmod as needed. Sometimes that's true, sometimes it's not. It's not true when kernel versions change (say from 3.12 to 3.13) and either nVidia hasn't updated their code to compile for it or rpmfusion hasn't loaded the latest nVidia drivers. Then I'm stuck having to go back to nouveau, blah blah blah...It becomes quite a hassle..Sigh...guess that's what's meant by bleeding edge! I have both kmod and akmod installed. That way, if the new kernel and the kmod come out together, it's taken care of by the update. If not, it's taken care of as soon as I boot into the new kernel. So far, I've never had this combo fail, and I've been doing it for several years. So I gave your suggestion a try last night and no joy. Installed kmod and akmods for nvidia, it pulled in the requisite x nvidia packages, and it just wouldn't run at all. When I looked to see what was up I realized that the nvidia module hadn't loaded...strange, thought I! So I tried to manually load it with modprobe and received the error Error: could not insert 'nvidia' :Exec format error. Bummer. So then I downloaded the nvidia package from nvidia directly and, no joy, won't compile (I did do a little looking around and saw some information about patches that needed to be applied to get nvidia to build on 3.13+ kernels and tried those patches but the build failed in other places). So I had to fall back to nouveau. Bleah! Ah well, at least I've got a functioning (albeit not accelerated) system! I'm running latest updated rawhide (3.14.0-0.rc4.git0.1). Kevin -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
fedora 20 firewalld multicast DLNA
Setting up a media server on a Fedora 20 box. It must have reception of multicast messages enabled. If I do a 'iptables -F' blowing away the firewall, then the media server sees the smart tv and the smart tv sees the media server. Given the default firewall that comes with Fedora 20 and firewalld, how do I add configuration info to it so that multicast messages are enabled? This is a pretty general how to configure firewalld so that Fedora can be used as a DLNA media server question. Thanks -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Most Efficient Network File sharing protocol?
What do y'all consider the most efficient network file system? NFS? SMB? SFTP? I've been doing a lot of file transfers across the network, and have been, well, less than impressed with the performance of NFS. I haven't set up a samba server yet (and I wasn't sure the SMB protocol itself would support hard links, even if the underlying file system did). SFTP seems like it would put too much of a load on the CPU with the encryption, and in fact, I almost cooked an RPi by transferring stuff through SFTP and SSHFS. What am I forgetting about? -- Dan Mossor Systems Engineer at Large Fedora QA Team Volunteer FAS: dmossor IRC: danofsatx San Antonio, Texas, USA -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Most Efficient Network File sharing protocol?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/28/14 12:07, Dan Mossor wrote: What do y'all consider the most efficient network file system? NFS? SMB? SFTP? I've been doing a lot of file transfers across the network, and have been, well, less than impressed with the performance of NFS. I haven't set up a samba server yet (and I wasn't sure the SMB protocol itself would support hard links, even if the underlying file system did). SFTP seems like it would put too much of a load on the CPU with the encryption, and in fact, I almost cooked an RPi by transferring stuff through SFTP and SSHFS. What am I forgetting about? SCP? Rsync? I use those a lot. Samba seems to work pretty well for me when I need it, which is fairly often. But I much prefer to SCP it or rsync if possible. - -- Mark Haney Network/Systems Administrator Practichem W: (919) 714-8428 Fedora release 20 (Heisenbug) 3.13.4-200.fc20.x86_64 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTEMPGAAoJEM/YzwEAv6e7Cc4IAJSKEhrcprBUfWGEOjaAsO3M P42bYdpN7d/9E76jZbw8tREg9tGCNp0IERtUfcxC03oiAvJOJsj3BoDMk9tnj8DL jvXSfn/BPve86Nw1S/gY4s+r/wT1M5gvULnY+9DJD7afQ4eUjVe1w1wTlm2ZDZC5 VnKBfOgCb3qPrMUaSusBPfNMgG1iIOYhJQbv4k8uSsDJufoUq6Uen+tSWpN9sCyb 1WUxVMmhK5ylZRCTwyApRkkL7iWoBfgJUo9m+iR6pSKSpQv3zAlrYl8KgSTPX1nB LDnjqNvFO7j17ve49BJNl1x3FUgR1WhS4ogFqiGC3nBBZWGR76dS6on3TWHzgGI= =d5Xg -END PGP SIGNATURE- -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Most Efficient Network File sharing protocol?
On Fri, Feb 28, 2014 at 2:13 PM, Mark Haney mha...@practichem.com wrote: Samba seems to work pretty well for me when I need it, which is fairly often. Old-school Netbeui was faster, but it's also ancient and deprecated. FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto Revolucionario - George Orwell -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Most Efficient Network File sharing protocol?
On Fri, Feb 28, 2014 at 2:45 PM, Fernando Cassia fcas...@gmail.com wrote: Old-school Netbeui was faster, but it's also ancient and deprecated. To expand on the above, a helpful quote: http://h71000.www7.hp.com/doc/73final/6556/6556pro_021.html --- A.3.2 NetBEUI Protocol The NetBIOS Extended User Interface (NetBEUI) was first introduced by IBM in 1985. NetBIOS, an integral part of the NetBEUI protocol driver, is a programming interface that implements many session layer functions. NetBEUI is a small, efficient, and fast protocol with low overhead. Note Overhead in this context refers to the additional network control information, such as routing and error checking, that the protocol adds to data that the application layer needs to send across the network. One reason for NetBEUI's lower overhead is that NetBEUI does not require an explicit acknowledgment (ACK) of each frame before it sends the next. Instead, the computer packages up several ACKs and sends them all at once. Requiring an ACK for every packet wastes network resources. NetBEUI dynamically determines the number of frames the sender can transmit before receiving an ACK, based on the network's current conditions. NetBEUI was developed for LANs segmented into workgroups of 20 to 200 computers, with gateways connecting LAN segments to one another or to mainframes. NetBEUI is optimized for very high performance when used in departmental LANs or LAN segments. For traffic within a LAN segment, NetBEUI typically is the fastest protocol. While NetBEUI is fast on small LANs, it is not so effective on large networks because it has a poor addressing scheme. NetBEUI does not allow duplicate computer names on the same network. This prevents a network from having two computers with the same name---something difficult to eliminate on a large network. Table A-3, NetBEUI Protocol, summarizes the advantages and disadvantages of the NetBEUI protocol. --- I haven't used Netbeui on my small LAN since I stopped using IBM OS/2 WSeB FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto Revolucionario - George Orwell -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: fedora 20 firewalld multicast DLNA
I'm using rygel with firewalld using a static port in the rygel.conf file. 1) cp /etc/rygel.conf ~/.config/rygel.conf for the user that will run the DLNA server 2) edit ~/.config/rygel.conf and change line port=0 to some high numbered port like 5 3) Set firewalld to allow 5/tcp and 1900/udp using the following commands: firewall-cmd --zone=public --permanent --add-port=5/tcp firewall-cmd --zone=public --permanent --add-port=1900/udp Then start rygel. -- john 2014-02-28 16:55 GMT+01:00 Rich Emberson emberson.r...@gmail.com: Setting up a media server on a Fedora 20 box. It must have reception of multicast messages enabled. If I do a 'iptables -F' blowing away the firewall, then the media server sees the smart tv and the smart tv sees the media server. Given the default firewall that comes with Fedora 20 and firewalld, how do I add configuration info to it so that multicast messages are enabled? This is a pretty general how to configure firewalld so that Fedora can be used as a DLNA media server question. Thanks -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Most Efficient Network File sharing protocol?
On Fri, Feb 28, 2014 at 5:13 PM, Mark Haney mha...@practichem.com wrote: On 02/28/14 12:07, Dan Mossor wrote: What do y'all consider the most efficient network file system? NFS? SMB? SFTP? Maybe you should outline your requirements a bit more. For example SFTP is not a filesystem, so are you only concerned about end-to-end transfer rates? poc -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Most Efficient Network File sharing protocol?
On Fri, Feb 28, 2014 at 11:07:38AM -0600, Dan Mossor wrote: What do y'all consider the most efficient network file system? NFS? SMB? SFTP? NFS over UDP. Less reliable, but less overhead. Can be significant if you have a lot of data to push around. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Fedora 19 assistance on modprobe /etc/modprobe.d/ .conf file being ignored
I need some assistance in troubleshooting problem with passing a modprobe parameter to the lirc_zilog module. I'm running Fedora 19 with the most recent updates: # uname -r 3.12.11-201.fc19.x86_64 I have a file /etc/modprobe.d/lirc_zilog.conf file that contains the following: # cat /etc/modprobe.d/lirc_zilog.conf options lirc_zilog tx_only=1 This file previously worked to disable the IR receive mode on the lirc_zilog module but something seems to have changed to prevent this from happening. The above parameter is being ignored since the lirc_zilog module is running both transmit and receive. Here is the command to receive IR signals: #irw 17b5 00 play Hauppauge 17b5 01 play Hauppauge 17b5 02 play Hauppauge The lirc_zilog module is being loaded at system boot time: # lsmod | grep lirc lirc_zilog 22473 0 i2c_core 38476 8 drm,i915,i2c_i801,hdpvr,lirc_zilog,drm_kms_helper,i2c_algo_bit,videodev lirc_dev 19504 1 lirc_zilog rc_core26896 1 lirc_dev The systemd-modules-load.service appears to have completed normally: # systemctl status systemd-modules-load.service systemd-modules-load.service - Load Kernel ModulesLoaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)Active: active (exited) since Mon 2014-02-24 18:06:33 EST; 1min 46s ago Docs: man:systemd-modules-load.service(8)man:modules-load.d(5) Process: 214 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS) Feb 24 18:06:32 divo systemd[1]: Starting Load Kernel Modules... The tx_only option is a valid option for lirc_zilog: # modinfo lirc_zilog filename: /lib/modules/3.12.11-201.fc19.x86_64/kernel/drivers/staging/media/lirc/lirc_zilog.ko alias: lirc_pvr150 license:GPL author: Gerd Knorr, Michal Kochanowicz, Christoph Bartelmus, Ulrich Mueller, Stefan Jahn, Jerome Brock, Mark Weaver, Andy Walls description:Zilog/Hauppauge infrared transmitter driver (i2c stack) depends:i2c-core,lirc_dev staging:Y intree: Y vermagic: 3.12.11-201.fc19.x86_64 SMP mod_unload signer: Fedora kernel signing key sig_key:FC:A0:01:2C:8A:A6:A3:A0:0F:CC:4E:16:E4:8C:17:FD:D9:C6:31:21 sig_hashalgo: sha256 parm: minor:Preferred minor device number (int) parm: debug:Enable debugging messages (bool) parm: tx_only:Only handle the IR transmit function (bool) I can manually unload the lirc_zilog module and manually reload lirc_zilog with the tx_only=1 option and lirc_zilog module works as desired with IR receive disabled. I've tried various filenames.conf and the different directories (/lib/modprobe.d) for modprobe without success. If I run dmesg and grep for IR, I see that lirc_zilog is probing for IR Rx and IR Tx. [Mon Feb 24 18:06:34 2014] lirc_zilog: probing IR Rx on Hauppage HD PVR I2C (i2c-8) [Mon Feb 24 18:06:34 2014] lirc_zilog: probe of IR Rx on Hauppage HD PVR I2C (i2c-8) done. Waiting on IR Tx. [Mon Feb 24 18:06:34 2014] lirc_zilog: probe of IR Rx on Hauppage HD PVR I2C (i2c-8) done [Mon Feb 24 18:06:34 2014] lirc_zilog: probing IR Tx on Hauppage HD PVR I2C (i2c-8) [Mon Feb 24 18:06:34 2014] lirc_zilog: IR unit on Hauppage HD PVR I2C (i2c-8) registered as lirc0 and ready [Mon Feb 24 18:06:34 2014] lirc_zilog: probe of IR Tx on Hauppage HD PVR I2C (i2c-8) done Previously when the tx_only=1 option was being properly processes, the lirc_zilog module was only probing for IR Tx. Looking at the systemd entries from dmesg doesn't give any hints for why the lirc_zilog.conf options file isn't being read. Looking at the output from journalctl -b doesn't provide any clues. I've exhausted my ability to troubleshoot the systemd-modules-load.service to see the details of what is going on during the boot process. I need help with how to enable debug on the systemd-modules-load process or help of where to look next to resolve this issue. Thanks in advance for any assistance you can provide.I think you're saying that if you manually unload the module and then load it the .conf file is honored and loaded as you want.If so, did you run dracut to create a new initramfs with the changes you made?Thanks for your help. You were correct that it was a problem with the kernel needing to be rebuilt after adding/changing files to the /etc/modules-load.d and /etc/modprobe.d directory.Made a copy of the existing /boot/initramfs-$(uname -r).img file and re-ran the command to rebuild the kernel file:# dracut -f /boot/initramfs-$(uname -r).img $(uname -r)I went back and checked the man pages on modules-load.d and modprobe.d and neither mentions having to run dracut or mkinitrd after adding file to these directories. Lesson learned. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct:
Re: Fedora 19 assistance on modprobe /etc/modprobe.d/ .conf file being ignored
On 03/01/14 07:14, dennismccl...@earthlink.net wrote: Thanks for your help. You were correct that it was a problem with the kernel needing to be rebuilt after adding/changing files to the /etc/modules-load.d and /etc/modprobe.d directory. Made a copy of the existing /boot/initramfs-$(uname -r).img file and re-ran the command to rebuild the kernel file: # dracut -f /boot/initramfs-$(uname -r).img $(uname -r) I went back and checked the man pages on modules-load.d and modprobe.d and neither mentions having to run dracut or mkinitrd after adding file to these directories. Lesson learned. You're welcome. I don't know where that information may be documented. -- Getting tired of non-Fedora discussions and self-serving posts -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Database - web-based dynamic pivot table - does it exist?
Greetings, I've been trying to find a mechanism to directly connect a database to a dynamic web-based pivot table. The functionality exists for MS Excel (connections can be made from either SQL server or Access to Excel). Any suggestions on where to look? Thanks. Max Pyziur p...@brama.com -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Fedora 19 assistance on modprobe /etc/modprobe.d/ .conf file being ignored
On 02/28/2014 03:23 PM, Ed Greshko issued this missive: On 03/01/14 07:14, dennismccl...@earthlink.net wrote: Thanks for your help. You were correct that it was a problem with the kernel needing to be rebuilt after adding/changing files to the /etc/modules-load.d and /etc/modprobe.d directory. Made a copy of the existing /boot/initramfs-$(uname -r).img file and re-ran the command to rebuild the kernel file: # dracut -f /boot/initramfs-$(uname -r).img $(uname -r) I went back and checked the man pages on modules-load.d and modprobe.d and neither mentions having to run dracut or mkinitrd after adding file to these directories. Lesson learned. You're welcome. I don't know where that information may be documented. It wouldn't be. If the device in question is hot-pluggable, then the act of plugging it in after boot would cause the udev stuff to invoke the modprobe. Since the device isn't hot-pluggable (it's there when you boot the machine), then the module must be loaded in the initrd image to be active at boot. Hence the need to run dracut. As far as I know, this has always been the case. If you need the module at boot, you need to have it in the initrd image. -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- -I'm afraid my karma just ran over your dogma- -- -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Fedora 19 assistance on modprobe /etc/modprobe.d/ .conf file being ignored
On 03/01/14 08:43, Rick Stevens wrote: It wouldn't be. If the device in question is hot-pluggable, then the act of plugging it in after boot would cause the udev stuff to invoke the modprobe. Since the device isn't hot-pluggable (it's there when you boot the machine), then the module must be loaded in the initrd image to be active at boot. Hence the need to run dracut. As far as I know, this has always been the case. If you need the module at boot, you need to have it in the initrd image. Sure, it probably has been always the case. I don't know how I came to know that. And, I don't know how those who don't know it will come to know it. Apparently, they won't come to know it by reading any available documentation. That is the entirety of my point. -- Getting tired of non-Fedora discussions and self-serving posts -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Fedora 19 assistance on modprobe /etc/modprobe.d/ .conf file being ignored
On 02/28/2014 04:46 PM, Ed Greshko issued this missive: On 03/01/14 08:43, Rick Stevens wrote: It wouldn't be. If the device in question is hot-pluggable, then the act of plugging it in after boot would cause the udev stuff to invoke the modprobe. Since the device isn't hot-pluggable (it's there when you boot the machine), then the module must be loaded in the initrd image to be active at boot. Hence the need to run dracut. As far as I know, this has always been the case. If you need the module at boot, you need to have it in the initrd image. Sure, it probably has been always the case. I don't know how I came to know that. And, I don't know how those who don't know it will come to know it. Apparently, they won't come to know it by reading any available documentation. That is the entirety of my point. Ah, I see. Yes, I don't know that it's documented anywhere that clearly. The old /usr/src/doc/kernel-(version)/Documentation/initrd.txt file sort of describes it as does the man page for dracut. I'm sure I learned it long ago when I started building kernels and drivers for some (at the time) esoteric hardware and now it's self-evident to me. -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - I haven't lost my mind. It's backed up on tape somewhere, but - - probably not recoverable.- -- -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
