similar to: 4.8-Release disk3 and disk4

It works ! It was THAT easy ! Can you suggest how to replace the hair I pulled out ? :-) On 2016-12-29 5:27 PM, Larry Rosenman wrote: > login_access_sockets = tcpwrap > > service tcpwrap { > unix_listener login/tcpwrap { > group = $default_login_user > mode = 0600 > user = $default_login_user > } > } > > > > On Thu, Dec 29, 2016 at

On 2015-03-02 2:02 AM, Jochen Bern wrote: > On 03/01/2015 08:53 AM, Jim Pazarena wrote: >> I wonder if there is an easy way to provide dovecot a flat text file of >> ipv4 #'s which should be ignored or dropped? >> >> I have accumulated 45,000+ IPs which routinely try dictionary and >> 12345678 password attempts. The file is too big to create firewall >>

V2 of dovecot has had the following releases (to recap) 2.0.0 2010-08-16 2.0.1 2010-08-24 2.0.2 2010-09-08 2.0.3 2010-09-17 2.0.4 2010-09-26 2.0.5 2010-10-01 I am on FreeBSD, and the port committers want to wait till dovecot V2 "stabilizes" prior to adding it to the FreeBSD ports base. So, my question is, respectfully, is dovecot V2.0.5 stable enough for prime-time on a busy ISP

I have compiled dovecot2 for FreeBSD with the tcpwrap option. A tcpwrap binary gets built and resides in the FreeBSD directory /usr/local/libexec/dovecot an examination of the compiled options (using the FreeBSD pkg install dovecot2) confirms: LIBWRAP : on yet, when I adjust dovecot.conf with: login_access_sockets = tcpwrap I get the following logged error message: 20161229 17:02:49

Can anyone share the proper config to get wrappers working in dovecot on FreeBSD? The dovecot examples do not seem to work, and I thought perhaps FBSD needs slightly different configs. I've compiled with: -DHAVE_LIBWRAP which I presume is the first step. The example for dovecot.conf in uncommenting: login_access_sockets = tcpwrap merely causes a log error of "imap-login: Error:

Hi Team, Please let me know how I can know which bricks are part of which sub-volumes in case of disperse volume, for example in below volume has two sub-volumes : Type: Distributed-Disperse Volume ID: 6dc8ced8-27aa-4481-bfe8-057133c31d0b Status: Started Snapshot Count: 0 Number of Bricks: 2 x (4 + 2) = 12 Transport-type: tcp Bricks: Brick1: pdchyperscale1sds:/ws/disk1/ws_brick Brick2:

Contact info * Author: Timo Sirainen, tss at iki.fi <mailto:tss at iki.fi>. * Please use the Dovecot mailing list <http://www.dovecot.org/mailinglists.html> for questions about Dovecot. You don't have to subscribe to it. * Depending on your needs, commercial support may be available. Send a mail if you're interested. according to the above (from

I wonder if there is an easy way to provide dovecot a flat text file of ipv4 #'s which should be ignored or dropped? I have accumulated 45,000+ IPs which routinely try dictionary and 12345678 password attempts. The file is too big to create firewall drops, and I don't want to compile with wrappers *if* dovecot has an easy ability to do this. If dovecot could parse a flat text file of

I have just come to the realization that password encryption using the crypt function in linux, ONLY USES THE FIRST 8 CHARS. I have written routines using crypt allowing 16+ chars, and find that anything past 8 is ignored. Wow. Is there a way around this that can be used in dovecot, as well as encryption routines for an email front end? (not system users). It's the integration with

Does IMAP create much additional system load vs. POP3?

First 6 bricks belong to First sub volume and next 6 bricks belong to second. On Tuesday 09 January 2018 12:11 PM, Anand Malagi wrote: > > Hi Team, > > Please let me know how I can know which bricks are part of which > sub-volumes in case of disperse volume, for example in below volume > has two sub-volumes : > > Type: Distributed-Disperse > > Volume ID:

But do we store this information somewhere as part of gluster metadata or something... Thanks and Regards, --Anand Extn : 6974 Mobile : 91 9552527199, 91 9850160173 From: Aravinda [mailto:avishwan at redhat.com] Sent: 09 January 2018 12:31 To: Anand Malagi <amalagi at commvault.com>; gluster-users at gluster.org Subject: Re: [Gluster-users] Bricks to sub-volume mapping First 6 bricks

We lost the attributes on all the bricks on servers glusterfs2 and glusterfs3 again. [root at glusterfs2 Log_Files]# gluster volume info Volume Name: StoragePool Type: Distributed-Disperse Volume ID: 149e976f-4e21-451c-bf0f-f5691208531f Status: Started Number of Bricks: 20 x (2 + 1) = 60 Transport-type: tcp Bricks: Brick1: glusterfs1sds:/ws/disk1/ws_brick Brick2: glusterfs2sds:/ws/disk1/ws_brick

Greetings. At the moment, I'm applying R to some AIX 'nmon' output, trying to get a handle on some disk performance metrics. In case anyone's interested: http://docs.osg.ufl.edu/tsm/pdf/ some of them are more edifying than others. (ahem) I'm trying to develop a somewhat general framework for plotting these measures, in the hopes that it's of some use to people other

Ram, As per the code, self-heal was the only candidate which *can* do it. Could you check logs of self-heal daemon and the mount to check if there are any metadata heals on root? +Sanoj Sanoj, Is there any systemtap script we can use to detect which process is removing these xattrs? On Sat, Jul 8, 2017 at 2:58 AM, Ankireddypalle Reddy <areddy at commvault.com> wrote: >

No, we don't store the information separately. But it can be easily predictable from the Volume Info. For example, in the below Volume info, it shows "Number of Bricks" in the following format, ??? Number of Subvols x (Number of Data bricks + Number of Redundancy bricks) = Total Bricks Note: Sub volumes are predictable without storing it as separate info since we do not have

On Fri, Jul 7, 2017 at 9:25 PM, Ankireddypalle Reddy <areddy at commvault.com> wrote: > 3.7.19 > These are the only callers for removexattr and only _posix_remove_xattr has the potential to do removexattr as posix_removexattr already makes sure that it is not gfid/volume-id. And surprise surprise _posix_remove_xattr happens only from healing code of afr/ec. And this can only happen

@ pranith , yes . we can get the pid on all removexattr call and also print the backtrace of the glusterfsd process when trigerring removing xattr. I will write the script and reply back. On Sat, Jul 8, 2017 at 7:06 AM, Pranith Kumar Karampuri <pkarampu at redhat.com > wrote: > Ram, > As per the code, self-heal was the only candidate which *can* do > it. Could you check

Please use the systemtap script( https://paste.fedoraproject.org/paste/EGDa0ErwX0LV3y-gBYpfNA) to check which process is invoking remove xattr calls. It prints the pid, tid and arguments of all removexattr calls. I have checked for these fops at the protocol/client and posix translators. To run the script .. 1) install systemtap and dependencies. 2) install glusterfs-debuginfo 3) change the path

using both thunderbird and roundcube with dovecot IMAP, I can create all the folders I desire, but cannot create subfolders; I also cannot delete a folder once created. I get a very un-informative error message from each. Is there a special setting required to permit sub-folder creation? folder deletion? I've got 770 mail:mail virtual_user_home 770 mail:mail mail_sub-directory