similar to: remote | local blocks in protocol settings

On 19 Jan 2016, at 13:34, Nikolaos Milas <nmilas at noa.gr> wrote: > > On 15/1/2016 8:02 ??, Nikolaos Milas wrote: > > Having received no reply, I tried using the above info by configuring: > > protocol imap { > imap_client_workarounds = "delay-newmail" > mail_plugins = quota imap_quota notify replication > mail_max_userip_connections

> On 19 Jan 2016, at 16:04, Nikolaos Milas <nmilas at noa.gr> wrote: > > On 19/1/2016 3:31 ??, Timo Sirainen wrote: > >> Change it the other way around: >> >> remote 127.0.0.1 { >> protocol imap { >> ... >> } >> } > > Thank you for your advice Timo (on "remote" blocks). > > So, the "remote"

On 5/5/2017 8:29 ??, Nikolaos Milas wrote: > I am very puzzled with "unknown filesystem". After more googling, I found this bug report with a very recent fix: https://bugzilla.redhat.com/show_bug.cgi?id=1399487 It seems to me that this may be relevant in our case. If so, may it be that this fix has not been rolled out to CentOS repos yet? What is your opinion and your

Op 8/21/2015 om 1:31 PM schreef Nikolaos Milas: > On 20/8/2015 11:09 ??, Nikolaos Milas wrote: > >> As soon as I manage to re-build Dovecot with the latest snapshot, >> I'll test it! > > Hello, > > I've built dovecot with a today snapshot from hg > (dovecot-2-2-9f815e781beb) and I am trying to enable haproxy. > > I configured as follows (lines added

On 22/8/2015 2:56 ??, Nikolaos Milas wrote: > Can we "stamp" log entries originating from different listeners with a > configurable label? Hello, I haven't received any reply on it. Is it possible or not? Thanks, Nick

Hi, -- This message refers to the maillist itself rather than to dovecot software -- I have noticed that when I post to this list (only), I get DKIM Verification failure reports from: root at moncton.sidefx.com (e.g. for my last post: "DKIM failure report for job 4D27B5DC4E on mail.sidefx.com") root at mail.rmacd.com (e.g. for my last post: "DKIM failure report for job

Hello, I am trying to switch from LDA to LMTP on a Postfix/Dovecot setup, but something is going wrong. I have followed the directions at: https://wiki.dovecot.org/HowTo/PostfixDovecotLMTP Here is a session from dovecot.log: Aug 4 12:19:42 vmail2 dovecot: lmtp(3152): Connect from local Aug 4 12:19:42 vmail2 dovecot: auth: ldap(imaptester at noa.gr): unknown user Aug 4 12:19:42 vmail2

Hello, On CentOS 6.5 x86_64 I have (/etc/sysconfig/iptables): *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A

On 4/5/2017 5:56 ??, Marcelo Roccasalva wrote: > dracut -f /boot/initramfs-<kernel_version>.img <kernel_version> I did: # dracut -f /boot/initramfs-3.10.0-514.10.2.el7.x86_64.img 3.10.0-514.10.2.el7.x86_64 and it ended without reporting any error. However, when I rebooted, nothing changed ("no such device: <UUID>. Entering rescue mode..."). Am I missing

Hi, I am running CentOS 7 (fully updated) on a VM. This has a mounted nfs share (via fstab) (which mounts a remote storage system) on which we have created the home directories of 2 users Here are the home directories: /mynfsmount | |--/user1 |--/user1 We want to move this whole branch from the mounted NFS share to the local disk. What is the way to do so? Would it be enough to create a

I am using a VM with CentOS 5.8 x86_64 under KVM. I only have console access to the VM through a virtual console (web based). Tonight, after a routine "yum update", I did a "shutdown -r now" due to kernel update and the VM won't start. See console screenshot vm1.png: https://vmail.noa.gr/files/vm1.png There is an error (which I haven't seen before): type=1404

On 01/04/2017 03:07 AM, Nikolaos Milas wrote: > Is it normal in CentOS 7 to have a device map with two entries esp. > when the (physical or virtual) hardware has only one hd ? I don't see that on VMs that I manage. Some of the physical machines that I manage do have duplicates in the device.map.

On 5/5/2017 1:19 ??, Gianluca Cecchi wrote: > Could you verify, if /dev/sda is your boot disk, with the command > > fdisk -l /dev/sda > ? It's /dev/vda in my case: # fdisk -l /dev/vda Disk /dev/vda: 21.5 GB, 21474836480 bytes, 41943040 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512

On 3/5/2017 10:41 ??, Marcelo Roccasalva wrote: > Does the UUID of root filesystem in /etc/fstab match the actual UUID > as reported by blkid? And remove/etc/lvm/cache/.cache if it exists Thank you Marcelo for replying, The directory /etc/lvm/cache/ is empty. And, yes, the UUID matches: # blkid /dev/vda1: UUID="297e2939-d6f5-431a-9813-9848368ee306" TYPE="xfs"

On 19/8/2015 5:43 ??, Stephan Bosch wrote: > Well... > > http://hg.dovecot.org/dovecot-2.2/rev/4d7a83ddb644 > > Regards, > > Stephan. That was impressive! Thank you Timo and Stephan. You are superb! I hope you will be able to provide some basic guidelines on how to enable/use the new functionality. (I am not very code-literate.) Looking forward to it! Thanks again!

Hello, Assuming we have two (low traffic) servers (on different data centers) replicated using dsync, what is the best way to automatically direct users to the main server when it is up and to the redundant one when the main server is down? Using DNS? I've seen that DNS-based failover has generally issues (for example:

On Thu, Jan 5, 2017 at 4:04 AM, Nikolaos Milas <nmilas at noa.gr> wrote: > On 4/1/2017 7:37 ??, Gordon Messmer wrote: > > I don't see that on VMs that I manage. Some of the physical machines that >> I manage do have duplicates in the device.map. >> > > Thank you Gordon for your feedback! > > Can others please report the content of /boot/grub2/device.map

Hello, I'm struggling to make a cloned CentOS 7 VM (under KVM) to work. The VM was cloned using mondorestore. Restore appears successful but the VM won't boot; see: http://iweb.noa.gr/files/centos7/supergrub2-scratchvm-20170503-04.png I booted with CentOS 7 disk in troubleshooting mode (where the virtual disk was automatically mounted without issues) and I tried to repair:

On Fri, May 5, 2017 at 12:52 PM, Nikolaos Milas <nmilas at noa.gr> wrote: > On 5/5/2017 1:42 ??, Nikolaos Milas wrote: > > Hmm, it seems that the boot flag should be removed from /dev/vda2 >> partition? >> > > Actually, I tried this and left the boot flag only to /dev/vda1. I > rebooted and I am still getting the same error. :-( > > I was hoping we were

On 5/5/2017 5:11 ??, Barry Brimer wrote: > Are the correct volumes referenced in your /etc/default/grub file? Thanks Barry for your feedback. Here is the output: http://iweb.noa.gr/files/centos7/scratchvm-data-20170505-01.png What can you tell from that? Cheers, Nick