Re: [gentoo-user] dovecot + inotify max_user instances
On 2014-01-06 2:53 PM, cov...@ccs.covici.com cov...@ccs.covici.com wrote: I put such a thing in /etc/sysctl.conf like this -- I don't have dovecot, but I needed it for crashplan fs.inotify.max_user_watches=100 or whatever value suits. Ok, after your and Alans comments and some more reading, I guess I agree, but... man sysctl, and the README in /etc/sysctl.d aren't very helpful. Would the proper line be: # Increase inotify.max_user_instances for dovecot fs.inotify.max_user_instances=1024 ? And how would I have ascertained this? Ie, I wouldn't have known to use the fs.prefix... Thanks
[gentoo-user] Question re: dovecot + filesystem permissions for vmail dirs
Hi all, Still waiting on an answer on the dovecot list, but I think there are more than a few dovecot users here too, so... I just migrated my 9+ year old gentoo mail server to a shiny new gentoo VM. Had to do some adjustments (see below if curious), but once I worked all of that out, it went rather smoothly and is now working very well. Something I neglected to confirm, though, and I want to deal, with this now, is I want to make sure the filesystem permissions are correct, and secure as possible. This is a virtual hosting setup only (no system users), and dovecot is currently running in high performance mode (I'm thinking I want to change that too, so wondering if that would affect the permissions)... /var/vmail (and everything under it) is owned by vmail:vmail. Current permissions are: Top-level dir: /var/vmail 755 Virtual domain dirs: /var/vmail/example1.com 777 /var/vmail/example2.com 777 Users home dirs (all others are the same): /var/vmail/example1.com/user1 755 Users Maildirs (all others are the same): /var/vmail/example1.com/user1/Maildir 700 All files inside the users Maildirs are 600, with the exception of the dovecot-uidvalidity.blahblah files, which are all 444 So... is this right? Anything need to be changed? If anyone is interested, the adjustments I wanted/needed to make were: 1. the users Maildirs were also their home I had to mv everything in .../example.com/user to .../example.com/user/Maildir 2. the filesystem ownership/permissions were wrong for using the dovecot LDA chown -R vmail:vmail /var/vmail 3. I wanted to get rid of the old legacy courier-imap INBOX prefix, but had to figure out how to provide compatibility settings so users wouldn't see any changes in their folders in their clients when I flipped the switch and had time to make the client changes before I remove the compatibility settings, etc. If anyone is interested I can provide the exact settings... 4. I wanted to switch my instructions for setting up new mail clients from using SSL/TLS on port 993 to STARTTLS on port 143. Simple, tell dovecot to start listening on 143 and open up 143 on the firewall, and change the instructions. Last of course I had to write up instructions for the users on how to change these settings so I can remove the compatibility settings - and of course, I'm very detail oriented, so the first instructions I sent out were overly complicated (had a few complaints from the people who don't know how to read) - so I removed all of the explanatory text and re-sent simplified instructions. I'll keep the compatibility settings for a week or two, and won't remove them until I stop seeing connections on 993 (toward the end of the week I'll start grepping the logs and fixing the stragglers). Anyway, once I figured out how to do the above, everything went very smoothly. Clients with the legacy INBOX prefix (Thunderbird, iPhones, Android/K9 clients, etc) all didn't notice a thing when I flipped the DNS switch. When users change their settings to remove the INBOX prefix and change the security/port settings to STARTTLS/143, Thunderbird users have to re-accept the SSL Cert (we use self-signed certs), but iPhone clients interestingly didn't. I think my Android did, but can't remember now... Anyway, took a lot of prep work to make the transition so seamless, but it was worth it.
Re: [gentoo-user] GSOC discussion
Wow. Can i try to do this task (aside of GSOC, simply because it's interesting)? On Tue, Jan 7, 2014 at 12:20 AM, James wirel...@tampabay.rr.com wrote: Google, Summer of Code, is a very wonderful idea for the Open Source Community: http://www.google-melange.com/gsoc/homepage/google/gsoc2014 No doubt many are scheming as to what would be good project ideas. Many really good ideas come from the rank and file of users. (Gmane.org is back online). Those (gifted? fledgling_gifted) often code good ideas directly. I think now is the time to have a robust (community) discussion on what the users of this list think would be good ideas for GSOC projects, which are Gentoo centric. My experiences with ALL current search engines, is there is quite a lot of low_quality results; which may be a direct result of the masses of those folks trying to learn/use unix/linux/gentoo by poorly formed google (et. al.) searches. Those low quality efforts statistically stack up against those few robustly accurate searches (from folks like the users of this list) so as to contaiminate search engines by the sheer number of poorly formed search engine efforts. I.E. it's not the fault of the search engine(?). So, Naturally, here is my idea. Collectively, if you look at this list archive and other such gentoo-centric resources, there is a wealth of good information that traverses our paths, and is then subsequently burried into the annals of lifeless data, only occasionally pinged by exasperating google searches, or gleaned from the multitude of records we each privately maintain. So, some sort of tool/app/parser that can glean information from the various gentoo-centric resources and store the data for later searching would be useful. Then a variety of experimental front ends could be tested (or developed anew) to query that data with relevant searches and very targeted searches. By limiting the focus to all things Gentoo, we could serve ourselves up crudely basic, but highly valuable information specific to the Gentoo-centric paramenters that one uses for this in-house database. This effort would mostly priortize the data returned in searches by some sort of *quality metric*. For example it could be simply that the most experienced dev would rate a *100 (times 100) multiplier on the quality of their searches. Recognized power users might rate a *25 rating. Ordinary folks a *1 rating on quality. This system would not even have to be open to the rank and file internet, except as a source of data returned to search engines like google, for example. Other distros could eventually do the same thing, and then Google could probe these databases, gaining specific user-community preferences of excellent quality (accuracy) search-data from folks steeped in all things Gentoo. Basically, a schemea is developed that allows the strongest of the Gentoo community to radically improve the quality of gentoo-specific searches, with very little efforts. For the devs and such, it could merely be a front-end to their own google searches. Folks would not have to use this front-end, if they do not want to. So, what is your idea for GSOC_2014? http://wiki.gentoo.org/index.php?title=Google_Summer_of_Code/2013/Ideas
[gentoo-user] jed/slang fail with gcc 4.7
Before my last update, I switched from gcc 4.6 to gcc 4.7 (some package required 4.7 -- I don't remember which one). Now jed fails: $ jed --batch loading /usr/share/jed/lib/site.sl loading /usr/share/jed/lib/os.sl loading /usr/share/jed/lib/menus.sl loading /etc/jed.conf Unable to open compress. Check the value of the S-Lang load path. /etc/jed.conf:9:top-level:Open failed Traceback: evalfile /usr/share/jed/lib/site.sl:3324:top-level:Open failed Looking at the strace output: open(/etc/jed.conf, O_RDONLY|O_LARGEFILE) = 4 write(1, loading /etc/jed.conf\n, 22) = 22 read(4, % -*- slang -*-\n\n% This is a sam..., 4096) = 328 read(4, , 3768) = 0 stat64(/usr/share/jed/lib\213V\267\335\377vF/usr/share/slsh\213V\267/usr/share/slsh/local-packages/compress, 0xbff4f$ stat64(/usr/share/jed/lib\213V\267\335\377vF/usr/share/slsh\213V\267/usr/share/slsh/local-packages/compress.slc, 0xb$ stat64(/usr/share/jed/lib\213V\267\335\377vF/usr/share/slsh\213V\267/usr/share/slsh/local-packages/compress.sl, 0xbf$ stat64(/usr/share/jed/lib\213V\267\335\377vF/usr/share/slsh\213V\267/usr/share/slsh/local-packages/compress.slc, 0xb$ rt_sigprocmask(SIG_BLOCK, [], [], 8)= 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 close(4)= 0 write(2, Unable to open compress. Check ..., 68) = 68 write(2, /etc/jed.conf:9:top-level:Open..., 40) = 40 write(2, Traceback: evalfile\n, 20) = 20 write(2, /usr/share/jed/lib/site.sl:3324:..., 56) = 56 close(3)= 0 rt_sigprocmask(SIG_BLOCK, [], [], 8)= 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [], [], 8)= 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 exit_group(30) = ? The path names being passed to the stat64() calls are garbage, they should be /usr/share/jed/lib/compress and so on. Re-emerging jed and slang using gcc 4.6 fixes the problem. Googling the Check the value of the S-Lang load path shows similar problems showing up on RedHat and Debian systems a few months back. One posted solution was to switch from -O2 to -O0 when building slang. Others say the problem was caused by an upgrade to glibc. Is it possible to configure portage to use a particular version of gcc just for one or two packages? -- Grant Edwards grant.b.edwardsYow! Were these parsnips at CORRECTLY MARINATED in gmail.comTACO SAUCE?
Re: [gentoo-user] GSOC discussion
On 07/01/14 14:35, Vladimir Romanov wrote: Wow. Can i try to do this task (aside of GSOC, simply because it's interesting)? Personally I think this project is a bit too convoluted, requires a lot of community effort and becomes fairly useless should people decide to stop contributing to it for some reason. I think the effort would be better spent updating the Wiki with the findings on the mailing lists. Google is Good Enough™ with finding the information you need. It does tend to take some time but I don't think it's so much that it justifies the amount of effort that'd have to go into the project. -- Mateusz K.
Re: [gentoo-user] how to use my SSD the right way ;-)
Am 06.01.2014 17:31, schrieb Stefan G. Weichinger: The Vertex3 seems to be way faster. the vertex3 is 60GB while the older Intel is 80GB ... not so good ... But I made some small progress in booting the thinkpad with BFQ-enabled kernel. Somehow the encrypted swap seems to have stopped things. Disabled it in /etc/fstab and now booted successfully with 3.12.6 and BFQ.
Re: [gentoo-user] dovecot + inotify max_user instances
Tanstaafl tansta...@libertytrek.org wrote: On 2014-01-06 2:53 PM, cov...@ccs.covici.com cov...@ccs.covici.com wrote: I put such a thing in /etc/sysctl.conf like this -- I don't have dovecot, but I needed it for crashplan fs.inotify.max_user_watches=100 or whatever value suits. Ok, after your and Alans comments and some more reading, I guess I agree, but... man sysctl, and the README in /etc/sysctl.d aren't very helpful. Would the proper line be: # Increase inotify.max_user_instances for dovecot fs.inotify.max_user_instances=1024 ? And how would I have ascertained this? Ie, I wouldn't have known to use the fs.prefix... Thanks Tanstaafl, You remove '/proc/sys/' from the path. Then replace every '/' with a '.' :) -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Question re: dovecot + filesystem permissions for vmail dirs
Tanstaafl tansta...@libertytrek.org wrote: Current permissions are: Virtual domain dirs: /var/vmail/example1.com 777 /var/vmail/example2.com 777 Do yourself a favour and reconsider the above 777 really carefully. I have never needed to set anything wide open like that. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
