Re: Fedora *is* for servers! [was Re: Need advice]
As are many things... Time is the only truly non-renewable resource. --Russell Which we seem never to have enough of. :) Cheers. Happy chocolate day. Robin -- 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: advice needed before changing inotify max_user_watches
On 04/20/14 13:49, M. Fioretti wrote: Greetings, a while ago, I noticed that on my Fedora box digiKam would not load and display picture galleries anymore, and when launched from the prompt would produce this message: digikam(14981)/digikam (core): Reached inotify limit which IIUC means this is a general problem on that computer, not digikam specific. An online search returned always the same fix described e.g. at http://monodevelop.com/Inotify_watches_limit, that is: ## To change the limit, run: # echo 16384 /proc/sys/fs/inotify/max_user_watches To make the change permanent, edit the file /etc/sysctl.conf and add this line to the end of the file: fs.inotify.max_user_watches=16384 ## (the current value now is 8192) I could not, however, find any clear (to me at least) explanation of possible unwanted side-effects of this. Should I check/do something else (but what?) or can I safely apply those suggestions and reboot? Is there risk that doing that stuff as is messes things up and forces me to spend a day or so recovering the system? I don't know how the system sets this value. 8192 seems rather small to me. On my system [egreshko@meimei inotify]$ cat /proc/sys/fs/inotify/max_user_watches 524288 This is the case on an F20 system with 8GB of RAM on real HW and a VM with 1 GB. And there is nothing in my sysctl.conf to override. -- 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: advice needed before changing inotify max_user_watches
On Sun, Apr 20, 2014 14:11:24 PM +0800, Ed Greshko wrote: I don't know how the system sets this value. 8192 seems rather small to me. good point, thanks. This, in fact, is a side question that I forgot to ask in my original email: what are the criteria or rule of thumb to calculate which value of max_user_watches is sensible? Does it depend on number of files, RAM amount, what else? And there is nothing in my sysctl.conf to override. same here, but I understand that I should __ADD__ that setting at the end of the file. But this is another point on which I am seeking confirmation/feedback, instead of risking to stop work for a day to fix some problem... Marco -- M. Fioretti http://mfioretti.com http://stop.zona-m.net Your own civil rights and the quality of your life heavily depend on how software is used *around* you -- 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: advice needed before changing inotify max_user_watches
On 04/20/14 14:09, M. Fioretti wrote: On Sun, Apr 20, 2014 14:11:24 PM +0800, Ed Greshko wrote: I don't know how the system sets this value. 8192 seems rather small to me. good point, thanks. This, in fact, is a side question that I forgot to ask in my original email: what are the criteria or rule of thumb to calculate which value of max_user_watches is sensible? Does it depend on number of files, RAM amount, what else? And there is nothing in my sysctl.conf to override. same here, but I understand that I should __ADD__ that setting at the end of the file. But this is another point on which I am seeking confirmation/feedback, instead of risking to stop work for a day to fix some problem... Marco Well As I noted, my 1GB VM F20 system has a value of 524288. I can't see how upping that value on your system will damage anything. In the little searching I also did on that issue I see some folks with 1M+ for that value. -- 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: advice needed before changing inotify max_user_watches
On Sun, Apr 20, 2014 14:40:07 PM +0800, Ed Greshko wrote: One silly question. What version of Fedora are you running. I found a message on the mailing lists back in 2010 which, from a reliable source, indicated this is happening on an F17 box. It **is** scheduled to be moved (full reinstall, not update) to F20 in a couple of weeks, but for reasons not really relevant here it has to stay F17 until then :-( Marco kde packagers received a request to consider shipping systems with a higher (default) value of /proc/sys/fs/inotify/max_user_watches to allow for a better experience for noticing changes (notably when using nepomuk indexing of content in users' homedir). The suggested value was something like 524288 (seems the default on f13 is 8192). -- 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 -- M. Fioretti http://mfioretti.com http://stop.zona-m.net Your own civil rights and the quality of your life heavily depend on how software is used *around* you -- 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: Disable whatever is cleaning /tmp
On 04/18/2014 12:56 AM, Rahul Sundaram wrote: On Thu, Apr 17, 2014 at 7:43 PM, Tucker wrote: That's helpful, thanks. There appear to be a number of services that depend on the tmpfiles.d conf files. I don't want to break things like kmod, I just want this thing that's doing Bad Things to my transient files in /*/tmp/* directories to stop. Maybe the right answer is to file a bug report rather than workaround it? Surely, yes. This behaviour will break all manner of things in hard-to- debug ways. Andrew. -- 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: advice needed before changing inotify max_user_watches
On 04/20/14 15:08, M. Fioretti wrote: On Sun, Apr 20, 2014 14:40:07 PM +0800, Ed Greshko wrote: One silly question. What version of Fedora are you running. I found a message on the mailing lists back in 2010 which, from a reliable source, indicated this is happening on an F17 box. It **is** scheduled to be moved (full reinstall, not update) to F20 in a couple of weeks, but for reasons not really relevant here it has to stay F17 until then :-( FWIW, everything I've seen indicates this value is not calculated but configured when the kernel is compiled. I just happen to have an old F17 disk and created a VM. As expected, it is set to 8192. -- 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: advice needed before changing inotify max_user_watches
On Sun, Apr 20, 2014 16:24:08 PM +0800, Ed Greshko wrote: On 04/20/14 15:08, M. Fioretti wrote: FWIW, everything I've seen indicates this value is not calculated but configured when the kernel is compiled. I just happen to have an old F17 disk and created a VM. As expected, it is set to 8192. ok that's why then. So the only thing I need, if anything, is further confirmation that increasing it on F17 would not cause problems. I'll wait until tomorrow for further comments and then risk the increase :-) Marco -- M. Fioretti http://mfioretti.com http://stop.zona-m.net Your own civil rights and the quality of your life heavily depend on how software is used *around* you -- 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: advice needed before changing inotify max_user_watches
On 04/20/14 16:28, M. Fioretti wrote: ok that's why then. So the only thing I need, if anything, is further confirmation that increasing it on F17 would not cause problems. I'll wait until tomorrow for further comments and then risk the increase :-) FWIW, I just made the change in /etc/sysctl.conf to up it to 524288, rebooted, and everything seems to be working as normal. -- 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: advice needed before changing inotify max_user_watches
On 20 April 2014 10:28, M. Fioretti mfiore...@nexaima.net wrote: On Sun, Apr 20, 2014 16:24:08 PM +0800, Ed Greshko wrote: On 04/20/14 15:08, M. Fioretti wrote: FWIW, everything I've seen indicates this value is not calculated but configured when the kernel is compiled. I just happen to have an old F17 disk and created a VM. As expected, it is set to 8192. ok that's why then. So the only thing I need, if anything, is further confirmation that increasing it on F17 would not cause problems. I'll wait until tomorrow for further comments and then risk the increase :-) Marco -- M. Fioretti http://mfioretti.com http://stop.zona-m.net Your own civil rights and the quality of your life heavily depend on how software is used *around* you The value of fs.inotify.max_user_watches was increased in F18, and later releases, due to this bug[1] in nepomuk. It's configured by /usr/lib/sysctl.d/97-kde-nepomuk-filewatch-inotify.conf which is installed by nepomuk-core, so ideally you'd get that value if you have KDE or installed a package that pulled nepomuk-core as a dependency. [1]https://bugzilla.redhat.com/show_bug.cgi?id=858271 -- Ahmad Samir -- 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: advice needed before changing inotify max_user_watches
On 04/20/14 20:51, Ahmad Samir wrote: The value of fs.inotify.max_user_watches was increased in F18, and later releases, due to this bug[1] in nepomuk. It's configured by /usr/lib/sysctl.d/97-kde-nepomuk-filewatch-inotify.conf which is installed by nepomuk-core, so ideally you'd get that value if you have KDE or installed a package that pulled nepomuk-core as a dependency. [1]https://bugzilla.redhat.com/show_bug.cgi?id=858271 Thanks for that. I should have know to check that directory. -- 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: advice needed before changing inotify max_user_watches
On 04/20/14 21:38, Ahmad Samir wrote: /usr/lib/sysctl.d/97-kde-nepomuk-filewatch-inotify.conf is included in the initramfs by dracut when a kernel is installed/updated. Check `lsinitrd /boot/initramfs-$(uname -r).img | grep sysctl`. So in effect you'd have to re-create the initramfs after uninstalling nepomuk-core to make that custom setting go away completely. Duh! -- 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
grub2-install ??
fedora 20 I installed Fedora 20 on /dev/sdb1 and after installation was completed it didn't select /dev/sdb1 and bootup . I have Windows on sda1 so i put a sdb in computer for Linux. Is the command, grub2-install /dev/sdb1 the correct command for booting Fedora 20 on sdb1 ? -- 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
[OT] Sendmail: Open relay was tested as closed but...
for some reason, spammers are getting through TLS and are bypassing/ignoring access database? I poured over the Internet but have yet to figure it out... How can I prevent spammers from using my sendmail server as an open relay even though open-relay is closed? Note STARTTLS=client and deferred deliveries when mail delivery fails and returns errors to my email server? /var/log/maillog small sample reveals: Apr 20 11:26:33 MYEMAILSERVER sendmail[1817]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., version=TLSv1/SSLv3, verify=OK, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128 Apr 20 11:26:36 MYEMAILSERVER sendmail[1817]: STARTTLS=client, relay=alt1.gmail-smtp-in.l.google.com., version=TLSv1/SSLv3, verify=OK, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128 Apr 20 11:26:37 MYEMAILSERVER sendmail[1817]: STARTTLS=client, relay=alt2.gmail-smtp-in.l.google.com., version=TLSv1/SSLv3, verify=OK, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128 Apr 20 11:26:39 MYEMAILSERVER sendmail[1817]: STARTTLS=client, relay=alt3.gmail-smtp-in.l.google.com., version=TLSv1/SSLv3, verify=OK, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128 Apr 20 11:26:41 MYEMAILSERVER sendmail[1817]: STARTTLS=client, relay=alt4.gmail-smtp-in.l.google.com., version=TLSv1/SSLv3, verify=OK, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128 Apr 20 11:26:42 MYEMAILSERVER sendmail[1817]: s3K1ceVt003083: to=kshitijbansa...@gmail.com,luke.m.armstr...@gmail.com,mercedesyard...@gmail.com,misti.wolan...@gmail.com,mzlangs...@gmail.com,rat.latin@gmail.com,richardthep...@gmail.com,rohith...@gmail.com,treycoo...@gmail.com, delay=16:47:57, xdelay=00:00:09, mailer=esmtp, pri=77257, relay=alt4.gmail-smtp-in.l.google.com. [173.194.75.26], dsn=4.0.0, stat=Deferred: 421-4.7.0 [50.126.86.236 15] Our system has detected an unusual rate of Apr 20 11:26:42 MYEMAILSERVER sendmail[1817]: s3K4nDlG014204: to=akang...@gmail.com,kevin.mck...@gmail.com,mman...@gmail.com,nflag...@gmail.com, delay=13:37:14, xdelay=00:00:00, mailer=esmtp, pri=67111, relay=alt4.gmail-smtp-in.l.google.com., dsn=4.0.0, stat=Deferred Apr 20 11:26:43 MYEMAILSERVER sendmail[1817]: STARTTLS=client, relay=aspmx.l.google.com., version=TLSv1/SSLv3, verify=OK, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128 Apr 20 11:26:45 MYEMAILSERVER sendmail[1817]: STARTTLS=client, relay=alt1.aspmx.l.google.com., version=TLSv1/SSLv3, verify=OK, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128 Apr 20 11:26:46 MYEMAILSERVER sendmail[1817]: STARTTLS=client, relay=alt2.aspmx.l.google.com., version=TLSv1/SSLv3, verify=OK, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128 Apr 20 11:26:47 MYEMAILSERVER sendmail[1817]: STARTTLS=client, relay=aspmx2.googlemail.com., version=TLSv1/SSLv3, verify=OK, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128 Apr 20 11:26:48 MYEMAILSERVER sendmail[1817]: STARTTLS=client, relay=aspmx3.googlemail.com., version=TLSv1/SSLv3, verify=OK, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128 Apr 20 11:26:49 MYEMAILSERVER sendmail[1817]: s3K4nDlK014204: to=announceme...@bariatricadvantage.com, delay=13:36:45, xdelay=00:00:06, mailer=esmtp, pri=64282, relay=aspmx3.googlemail.com. [74.125.196.26], dsn=4.0.0, stat=Deferred: 421-4.7.0 [50.126.86.236 15] Our system has detected an unusual rate of Apr 20 11:26:49 MYEMAILSERVER sendmail[1817]: s3K4nDlK014204: to=redbarn.kenn...@gmail.com, delay=13:36:45, xdelay=00:00:00, mailer=esmtp, pri=64282, relay=alt4.gmail-smtp-in.l.google.com., dsn=4.0.0, stat=Deferred Apr 20 11:26:52 MYEMAILSERVER sendmail[1817]: s3K51Tx3015146: to=l...@pasafarming.org,bphou...@pennswoods.net,leve...@netsync.net, delay=13:25:18, xdelay=00:00:00, mailer=esmtp, pri=66225, relay=aspmx2.googlemail.com., dsn=4.0.0, stat=Deferred Apr 20 11:26:52 MYEMAILSERVER sendmail[1817]: s3K51Tx3015146: to=l...@pasafarming.org, delay=13:25:18, xdelay=00:00:00, mailer=esmtp, pri=66225, relay=aspmx3.googlemail.com., dsn=4.0.0, stat=Deferred Apr 20 11:26:52 MYEMAILSERVER sendmail[1817]: s3K51Tx3015146: to=bethros...@gmail.com,delphin...@gmail.com, delay=13:25:18, xdelay=00:00:00, mailer=esmtp, pri=66225, relay=alt4.gmail-smtp-in.l.google.com., dsn=4.0.0, stat=Deferred Apr 20 11:26:55 MYEMAILSERVER sendmail[1817]: s3K51Tx5015146: to=dmankow...@us.com,l...@cmmpr.com, delay=13:24:48, xdelay=00:00:00, mailer=esmtp, pri=68195, relay=aspmx3.googlemail.com., dsn=4.0.0, stat=Deferred Apr 20 11:26:56 MYEMAILSERVER sendmail[1817]: STARTTLS=client, relay=aspmx5.googlemail.com., version=TLSv1/SSLv3, verify=OK, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128 Apr 20 11:26:58 MYEMAILSERVER sendmail[1817]: STARTTLS=client, relay=aspmx4.googlemail.com., version=TLSv1/SSLv3, verify=OK, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128 Apr 20 11:26:59 MYEMAILSERVER sendmail[1817]: s3K51Tx5015146: to=dmankow...@us.com, delay=13:24:52, xdelay=00:00:04, mailer=esmtp, pri=68195, relay=aspmx4.googlemail.com. [74.125.29.26], dsn=4.0.0, stat=Deferred:
Re: [OT] Sendmail: Open relay was tested as closed but...
Dan Thurman writes: for some reason, spammers are getting through TLS and are bypassing/ignoring access database? I poured over the Internet but have yet to figure it out... The most common way is by hacking the client's PC, and authenticating to the mail server using the stolen loginid and password. Change all your passwords. pgph6kp8BWL1J.pgp Description: 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: [OT] Sendmail: Open relay was tested as closed but...
On 04/20/2014 01:38 PM, jdow wrote:
Heartbleed... Anybody running an OpenSSL server has compromised passwords
for anybody using the system at least from when the vulnerability was
revealed until it was repaired should consider every password on the
system is compromised. They should ALL be changed, pronto. And you should
make sure it is the right person changing the passwords.
{^_^}
I have F8 and F18. F8 is not affected by HB and F18 is HB
fixed (recompiled) and certificates regenerated. Both Fedora
versions have the same open-relay issues and both have
similar or nearly identical sendmail.mc configurations.
Here is my sendmail.mc file and
let me know if there is a problem?:
dnl #--
dnl # You MUST enable SASLAUTHD for this to work!
dnl #--
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl
OSTYPE(`linux')dnl
dnl ### do STARTTLS
define(`CERT_DIR', `/etc/pki/tls/certs')dnl
define(`confCACERT_PATH', `CERT_DIR')dnl
define(`confCACERT', `CERT_DIR/ca-bundle.crt')dnl
define(`confCRL', `CERT_DIR/ca-bundle.crt')dnl
define(`confSERVER_CERT', `CERT_DIR/sendmail.pem')dnl
define(`confSERVER_KEY', `CERT_DIR/sendmail.pem')dnl
define(`confCLIENT_CERT', `CERT_DIR/sendmail.pem')dnl
define(`confCLIENT_KEY', `CERT_DIR/sendmail.pem')dnl
dnl ###
define(`ALIAS_FILE', `/etc/aliases')dnl
define(`confALIAS_WAIT', `0')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN
PLAIN')dnl
define(`confCONNECTION_RATE_THROTTLE', `2')dnl Denial of Service Attacks
define(`confCON_EXPENSIVE', `true')dnl
define(`confDEF_CHAR_SET', `iso-8859-1')dnl
define(`confDEF_USER_ID', ``8:12'')dnl
define(`confDIAL_DELAY', `20s')dnl
define(`confDONT_PROBE_INTERFACES', `True')dnl
define(`confLOG_LEVEL', `9')dnl
define(`confMAX_DAEMON_CHILDREN', `30')dnlDenial of service Attacks
define(`confMAX_HOP', `35')dnl
define(`confMAXRCPTSPERMESSAGE', `50')dnl Denial of service Attacks
define(`confMAX_MESSAGE_SIZE', `1500')dnl Denial of service Attacks
define(`confMAXRCPTSPERMESSAGE', `50')dnl
define(`confMILTER_MACROS_CONNECT',`t, b, j, _, {daemon_name},
{if_name}, {if_addr}')dnl
define(`confMILTER_MACROS_HELO',`s, {tls_version}, {cipher},
{cipher_bits}, {cert_subject}, {cert_issuer}')dnl
define(`confNO_RCPT_ACTION', `add-apparently-to')dnl
define(`confPRIVACY_FLAGS',
`authwarnings,goaway,restrictmailq,restrictqrun,needmailhelo')dnl
define(`confQUEUE_LA', `5')dnl
define(`confQUEUE_SORT_ORDER', `Time')dnl
define(`confREFUSE_LA', `12')dnl
define(`confSEPARATE_PROC', `False')dnl
define(`confSINGLE_LINE_FROM_HEADER', `True')dnl
define(`confSMTP_LOGIN_MSG', `$j')dnl
define(`confTO_CONNECT', `20s')dnl
define(`confTO_DATABLOCK', `35m')dnl
define(`confTO_DATAFINAL', `35m')dnl
define(`confTO_DATAINIT', `6m')dnl
define(`confTO_HELO', `5m')dnl
define(`confTO_HOSTSTATUS', `2m')dnl
define(`confTO_IDENT', `0')dnl
define(`confTO_INITIAL', `6m')dnl
define(`confTRY_NULL_MX_LIST', `True')dnl
define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl
define(`confWORK_RECIPIENT_FACTOR', `1000')dnl
define(`confWORK_TIME_FACTOR', `3000')dnl
define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail')dnl
define(`STATUS_FILE', `/var/log/mail/statistics')dnl
define(`UUCP_MAILER_MAX', `200')dnl
DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
DAEMON_OPTIONS(`Family=inet, Port=465, Name=MTA-SSL M=s')dnl
EXPOSED_USER(`root')dnl
TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
FEATURE(`access_db', `hash -TTMPF -o /etc/mail/access.db')dnl
dnl FEATURE(`authinfo',`hash /etc/mail/authinfo.db')dnl
FEATURE(always_add_domain)dnl
FEATURE(`blacklist_recipients')dnl
FEATURE(`block_bad_helo')dnl
FEATURE(delay_checks)dnl
FEATURE(`dnsbl',`b.barracudacentral.org', `Rejected
[${client_addr}] by barracudacentral.org')dnl
FEATURE(`dnsbl',`zen.spamhaus.org', `Rejected
[${client_addr}] by spamhaus.org')dnl
FEATURE(`dnsbl',`dnsbl.sorbs.net',`Rejected
[${client_addr}] by dnsbl.sorbs.net')dnl
FEATURE(`enhdnsbl', `bl.spamcop.net', `Rejected
[${client_addr}] by spamcop.net', `t')dnl
FEATURE(`dnsbl',`relays.ordb.org' `Rejected
[${client_addr}] by relays.ordb.org')dnl
dnl FEATURE(`dnsbl',`relays.osirusoft.com', `Rejected
[${client_addr}] by relays.osirusoft.com')dnl
FEATURE(`generics_entire_domain')dnl
dnl FEATURE(`greet_pause', `3000')dnl
FEATURE(local_procmail, `', `procmail -t -Y -a $h -d $u')dnl
FEATURE(lookupdotdomain)dnl
FEATURE(`mailertable', `hash -o /etc/mail/mailertable.db')dnl
FEATURE(masquerade_envelope)dnl
FEATURE(`no_default_msa', `dnl')dnl
FEATURE(`nouucp',`reject')dnl
FEATURE(redirect)dnl
dnl FEATURE(`relay_based_on_MX')dnl
FEATURE(relay_hosts_only)dnl
FEATURE(`relay_entire_domain')dnl
FEATURE(`require_rdns') dnl
FEATURE(`smrsh', `/usr/sbin/smrsh')dnl
FEATURE(use_ct_file)dnl
FEATURE(use_cw_file)dnl
FEATURE(`virtuser_entire_domain')dnl
FEATURE(`virtusertable', `hash -o
Re: Fedora 20 freezes at the login screen. System Temperature over limit.
On 04/21/14 00:13, Sudhir Khanger wrote: I booted into runlevel 3 and saw system being flooded with nouveau errors. Here is a screenshot http://i.imgur.com/qET8Zxrl.jpg nouveau W[ PFIFO][1000 and more numbers. I can boot fine with any kernel with nomodeset. I can boot fine with any kernel with Nvidia Card disabled in bios. Nouveau floods all three upgraded kernels 3.13.8/9/10. Sounds like a nouveau bugzilla time... Maybe similar to what Aleksandar Kostadinov is seeing. It would seem actually booting to runlevel 3 revealed something. Of course you always have the option of switching to the nVidia drivers from rpmfusion. I'm sure that you've thought of that already -- 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 20 freezes at the login screen. System Temperature over limit.
On 04/21/14 06:24, Ed Greshko wrote: Of course you always have the option of switching to the nVidia drivers from rpmfusion. I'm sure that you've thought of that already To continue the thought before my cat hit send. alreadyI was forced to move to nVidia when noveau produced nothing by snow on my GT240 card. The bugzilla was never fixed. -- 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: [OT] Sendmail: Open relay was tested as closed but...
Am 20.04.2014 21:23, schrieb Dan Thurman: for some reason, spammers are getting through TLS and are bypassing/ignoring access database? I poured over the Internet but have yet to figure it out... TLS is no protection against a misused of your MTA. How can I prevent spammers from using my sendmail server as an open relay even though open-relay is closed? See below. Note STARTTLS=client and deferred deliveries when mail delivery fails and returns errors to my email server? What is your question? As being a massive source of SPAM your MTA is already being blacklisted or at least temporarily blocked by other MTAs like the google mail system. /var/log/maillog small sample reveals: [ ... ] Apr 20 11:42:46 MYEMAILSERVER sendmail[3038]: AUTH=server, relay=90.148.226.111.dynamic.saudi.net.sa [90.148.226.111] (may be forged), authid=k...@cdkkt.com, mech=PLAIN, bits=0 [ ... ] Identify the source of the SPAM. In the shown case the sender - is he one of the spammers? - has authenticated itself as user k...@cdkkt.com. Watch out where the other SPAM is coming from (not going to). If it is your AUTH backend, then fix it. It may be enough to change the password of misused users accounts. Alexander -- 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 freezes at the login screen. System Temperature over limit.
On Apr 21, 2014 3:54 AM, Ed Greshko ed.gres...@greshko.com wrote: On 04/21/14 00:13, Sudhir Khanger wrote: I booted into runlevel 3 and saw system being flooded with nouveau errors. Here is a screenshot http://i.imgur.com/qET8Zxrl.jpg nouveau W[ PFIFO][1000 and more numbers. I can boot fine with any kernel with nomodeset. I can boot fine with any kernel with Nvidia Card disabled in bios. Nouveau floods all three upgraded kernels 3.13.8/9/10. Sounds like a nouveau bugzilla time... Maybe similar to what Aleksandar Kostadinov is seeing. It would seem actually booting to runlevel 3 revealed something. Of course you always have the option of switching to the nVidia drivers from rpmfusion. I'm sure that you've thought of that already -- 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 I had Bumblebee install Nvidia. I am not sure why Nouveau is blocking the boot. Blacklisting Nouveau didn't work. I will boot into working kernel run level 3 and uninstall Nouveau using dracut method. http://www.if-not-true-then-false.com/2013/fedora-19-nvidia-guide/ https://ask.fedoraproject.org/en/question/23982/how-to-disable-nouveau-in-fedora-18/ -- 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: Disable whatever is cleaning /tmp
On Apr 20, 2014, at 2:00 AM, Andrew Haley a...@redhat.com wrote: On 04/18/2014 12:56 AM, Rahul Sundaram wrote: On Thu, Apr 17, 2014 at 7:43 PM, Tucker wrote: That's helpful, thanks. There appear to be a number of services that depend on the tmpfiles.d conf files. I don't want to break things like kmod, I just want this thing that's doing Bad Things to my transient files in /*/tmp/* directories to stop. Maybe the right answer is to file a bug report rather than workaround it? Surely, yes. This behaviour will break all manner of things in hard-to- debug ways. No where in the original feature page does it say periodic cleaning of /tmp happens. In fact the opposite is indicated. https://fedoraproject.org/wiki/Features/tmp-on-tmpfs The cited blog indicates periodic clean up based on aging, and cites the FHS as saying files in /tmp aren't expected to be needed persistently between two runs of the application. http://0pointer.de/blog/projects/tmp.html I don't know when the aged based cleaning started, but it isn't expressly stated in the original feature and I'm not finding a followup feature that indicates this change. On the other hand, it sounds like most of the time applications shouldn't use (or depend on) /tmp anyway since they can't depend on any sort of persistence. Chris Murphy -- 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: how to report a nouveau bug?
On Mon, Apr 21, 2014 at 12:59 AM, Aleksandar Kostadinov akost...@redhat.com wrote: Hello, I want to report a freeze with latest fedora 3.13 kernel just on login screen. The issue is not present on the initial kernel coming with fedora 20 life CD. The problem is that when I boot I can't switch to a text console after the freeze. I don't have good access to the laptop because it's my mother's so I'm wondering what would be the easiest way to collect useful information and report it. btw I think it is nouveau issue because I see some messages realated to nouveau just before entering graphics mode. Perhaps I can boot to the freeze, then reboot into older kernel, and collect the log but my there is some risk the log to not be complete due to unclean reboot. As well I'm not sure if plain log is enough. I would like to file a good bug report from the first attempt to avoid the hassle repeating the operation for small details. 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 Let's continue the discussion over at bugzilla. -- 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
