Local mail server not working prpoperly in centos 6.5 - smtp

I want to setup a local mail server which want to work in local environment. For that i used the sendmail and dovecot.
i have a development server and in that we uses mantis like tools. so after resolving the issue each developer got the mail previously but now it is not getting in local intranet.
so i need to resolve this problem for that i installed sendmail server.
yum install sendmail* -y
yum install m4* -y
changed in sendmail.mc
dnl # DAEMON_OPTIONS(`Port=smtp, Addr=192.168.1.91, Name=MTA')dnl
then
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
then service sendmail restart
for receiving mail i installed dovecot
yum install dovecot* -y
in that i changed
in dovecot.conf
uncomment pop3 imap
10-auth.conf
changed
disable_plaintext_auth = no
auth_mechanisms = plain login
in 10-mailconf
uncomment the mailDir.
in 10-master.conf
user and group left blank
everything is works all said ok.
sendmail ok. dovecot ok.
no error but mail dosen't receive.
but nothing happened i am not able to receive mail.
I need to do like if i have a email user1#example.com and user2#example.com so both are using mantis user1 is admin of mantis. if any issue get resolve then user2 will get the automatic mail for that from user1.
for that how i configure the mail server.

In sendmail.mc change
dnl # DAEMON_OPTIONS(`Port=smtp, Addr=192.168.1.91, Name=MTA')dnl
to
DAEMON_OPTIONS(`Port=smtp, Addr=192.168.0.0, Name=MTA')dnl
To accept mail on port 25 from local address 192.168.xxx.xxx
Also add a line in access file (to relay mail from those IP's):
Connect:192.168 RELAY
Don't forget to type make after editing.

Related

How do I get xdebug/step-debugging working with ddev?

I've been working with ddev on my Drupal projects, and now want to use xdebug so I have step-debugging with PhpStorm (or really any IDE would be fine). But I can't seem to get it to stop on breakpoints. I tried to follow the instructions in ddev docs but that doesn't do get me going, and I don't know what to do next. I did:
Set the 172.28.99.99 IP address as discussed there
Enabled xdebug using config.yaml xdebug_enabled: true and ddev start (and checked with phpinfo to see that xdebug was enabled.)
Put PHPStorm in "listen for debug connections" mode
Debugging xdebug in any setup can be a little trouble, but here are the steps to take:
First, reread the docs. You may want to read the troubleshooting docs rather than this issue, since they're maintained more often.
Make sure xdebug has been enabled; it's disabled by default for performance reasons. Most people use ddev xdebug on to enable it when they want it, and ddev xdebug off when they're done with it, but it can also be enabled in .ddev/config.yaml.
Don't assume that some obscure piece of code is being executed and put a breakpoint there. Start by putting a breakpoint at the first executable line in your index.php. Oh-so-many times people think it should be stopping, but their code is not being executed.
ddev ssh into the web container. Can you ping host.docker.internal (and get responses)? If you can't, you might have an over-aggressive firewall.
In PHPStorm, disable the "listen for connections" button so it won't listen. Or just exit PHPStorm.
ddev ssh: Can telnet host.docker.internal 9003 connect? If it does, you have something else running on port 9003, probably php-fpm. Use lsof -i :9003 -sTCP:LISTEN to find out what is there and stop it, or change the xdebug port and configure PHPStorm to use the new one . Don't continue until your telnet command does not connect.
Now click the listen button on PHPStorm to start it listening for connections.
ddev ssh and try the telnet host.docker.internal 9003 again. It should connect. If not, maybe PHPStorm is not listening, or not configured to listen on port 9003?
Check to make sure that Xdebug is enabled. You can use php -i | grep grep Xdebug inside the container, or use any other technique you want that gives the output of phpinfo(), including Drupal's admin/reports/status/php. You should see with Xdebug v2.9.6, Copyright (c) 2002-2020 and php -i | grep "xdebug.remote_enable" should give you xdebug.remote_enable: On.
Set a breakpoint in the first relevant line of the index.php of your project and then visit the site with a browser. It should stop there.
A note from #heddn: If you want to have xdebug running only for fpm, phpenmod -s fpm xdebug for example, instead of running enable_xdebug.
A note from #mfrieling: If you use a browser extension like XDebug Helper which sets an IDE key, that must be the same as on the server. Since DDEV 1.10.0 "there's a real user created for you inside the web and db containers, with your username and userid" which is also used as IDE key by default. The used IDE key must be the same on the server, the browser extension/cookie sent and PHPStorm. You can change the IDE key in DDEV by creating a file .ddev/php/xdebug.ini with the following two lines (replace PHPSTORM with the value you want use:
[XDebug]
xdebug.idekey = PHPSTORM
Your followups are welcome here!
Thanks, had the same problem and adding the file .ddev/docker-compose.xdebug.yaml fixed the issue.
However, I am running on a Mac / OSX and found these additional steps worked to discover the IP address of the internal host from inside the container:
1.) Log into the web continaner ddev ssh
2.) Run ping docker.for.mac.localhost
3.) Set the returned IP address for host.docker.internal in the above yaml file.
4.) Remove and start the DDEV.
Also worth mentioning validating xdebug in PHPStorm is useful to check the config.
Careful with Macs, as they may have php-fpm running. If it's the case PHP Storm won't find the connection (as it's already taken by php-fpm).
To see if it's the case run:
lsof -i :9000 -sTCP:LISTEN
if it returns something like php-fpm, then you have this issue
Try closing it (see PHP-FPM can't be closed ).
Running it once you have fixed it (potentially restarted your mac) you should see something like this:
➜ solrpoc lsof -i :9000 -sTCP:LISTEN
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
phpstorm 512 alejandro.moreno 490u IPv6 0xaf3eef0f3233a83 0t0 TCP *:cslistener (LISTEN)

Vagrant, Mercurial Keyring: constantly requests password for encrypted keyring

So I'm running Ubuntu 14.04 on VirtualBox via Vagrant, and want to set up Mercurial so that it doesn't constantly ask for a password when pulling latest. In that regard, I've installed Mercurial-Keyring, and changed my ~/.hgrc file to look like:
[extensions]
mercurial_keyring =
[auth]
ono.schemes = https
ono.prefix = <URL>
ono.username = <username>
However, now it asks me to enter a password for the encrypted keyring every time I want to use Mercurial - even on the same session.
Does anyone know what the cause of this is?

Couchbase Mobile (Sync Gateway) sample TODOlite application doesn't replicate; complains _facebook doesn't exist

My objective: get https://github.com/couchbaselabs/ToDoLite-iOS syncing with a Couchbase Server and sync gateway on localhost rather than the default demo URL.
I run sync gateway like so: bin/sync_gateway -url http://localhost:8091
And then the only thing I changed in the example is:
-#define kSyncGatewayUrl #"http://demo.mobile.couchbase.com/todolite"
+#define kSyncGatewayUrl #"http://localhost:4984/sync_gateway/"
And when I run
Error: Error Domain=CBLHTTP Code=404 "404 not_found" UserInfo=0x7ff11941fb50 {NSURL=http://localhost:4984/sync_gateway/_facebook, NSLocalizedFailureReason=not_found, NSLocalizedDescription=404 not_found}
How do I fix this?
I solved it. The reason is that I ran sync_gateway without enabling Facebook registration support.
Normally this is done in config.json file. In fact, this configuration file was supplied in ToDoLite all along.
It is crucial that you launch sync_gateway with this configuration file. The README actually states this but in a loose and casual way...
cd ToDoLite-iOS
sync_gateway -url http://localhost:8091 sync-gateway-config.json
NB: I assume above that sync_gateway has been made accessible through $PATH. It's a good idea to do that anyway.
Also, I didn't pay attention to the dbname. So you'll need to replace
#define kSyncGatewayUrl #"http://demo.mobile.couchbase.com/todolite"`
with
#define kSyncGatewayUrl #"http://localhost:4984/todos"
So, what's the complete sequence of steps to get it working?:
If you want to wipe everything on the server, rm -rf Library/Application\ Support/Couchbase and start over. Homebrew cask hides this setting somewhere else where it's hard to reset so a manual install is very recommended.
Install Couchbase Server
Set up login credentials if fresh install; otherwise just login
Create a bucket (a database) with name todos on the cluster. This is the dbname used by TODOLite.
Launch sync gateway. Be sure to pass in the replication URL AND the JSON config file.
bin/sync_gateway -url http://localhost:8091 sync-gateway-config.json; keep sync gateway running
In the TODOLite AppDelegate.m, change kSyncGatewayUrl:
#define kSyncGatewayUrl #"http://localhost:4984/todos". Notice the name of the database is necessary!
(Optionally) Access the administrator interface of the sync gateway by going to http://localhost:4985/_admin/db/sync_gateway/sync. You can set up the sync function here.
In case you're wondering where those port numbers came from, check out
ports Couchbase Server uses
ports Sync Gateway uses
4984 — SG API port
4985 — SG admin server
The default remote sync URL will be defined in different files depending on the version of the project you download (iOS, Android, PhoneGap, and Motion). To find the appropriate string to change simply search through your project for the URL "http://demo.mobile.couchbase.com/todolite" and replace it with the URL of your new sync gateway database.

Gitlab with non-standard SSH port (on VM with Iptable forwarding)

My gitlab is on a virtual machine on a host server. I reach the VM with a non-standard SSH port (i.e. 766) which an iptable rule then forward from host:766 to vm:22.
So when I create a new repo, the instruction to add a remote provide a mal-formed URL (as it doesn't use the 766 port. For instance, the web interface give me this:
Malformed
git remote add origin git#git.domain.com:group/project.git
Instead of an URL containing :766/ before the group.
Wellformed
git remote add origin git#git.domain.com:766/group/project.git
So it time I create a repo, I have to do the modification manually, same for my collaborator.
How can I fix that ?
In Omnibus-packaged versions you can modify that property in the /etc/gitlab/gitlab.rb file:
gitlab_rails['gitlab_shell_ssh_port'] = 766
Then, you'll need to reconfigure GitLab:
# gitlab-ctl reconfigure
Your URIs will then be correctly displayed as ssh://git#git.domain.com:766/group/project.git in the web interface.
if you configure the ssh_port correctly in config/gitlab.yml, the webpages will show the correct repo url.
## GitLab Shell settings
gitlab_shell:
...
# If you use non-standard ssh port you need to specify it
ssh_port: 766
ps.
the correct url is:
ssh://git#git.domain.com:766/group/project.git
edit: after the change you need to clear caches, etc:
bundle exec rake cache:clear assets:clean assets:precompile RAILS_ENV=production
N.B.: this was tested on an old Giltab version (v5-v6), and might not be suitable for modern instance.
You can achieve similar behavior in a 2 step process:
1. Edit: config/gitlab.yml
On the server, set the port to the one you use:
ssh_port: 766
2. Edit ~/.ssh/config
On your machine, add the following section corresponding to your gitlab:
Host sub.domain.com
Port 766
Limit
You will need to repeat this operation on each user's computer…
References
GitLab and a non-standard SSH port
Easy way to fix this issue:
ssh://git#my-server:4837/~/test.git
git clone -v ssh://git#my-server:4837/~/test.git
Reference URL

Configuration for using Mercurial with Bitbucket from behind a certificate rewriting proxy?

I'm trying to access BitBucket from work. The only access to the Internet is via an authenticating HTTP proxy which proxies http on port 8080 and SSL on port 8070. This proxy conducts a man-in-the-middle attack on SSL connections, browsers are able to create HTTPS connections to the Internet only due to the installation of a fake Websense certificate on all clients.
I am able to connect to BitBucket using Git but not using Mercurial. I'm using Mercurial version 2.0.2.
With Git I use the following config in .gitconfig
[user]
name = Firstname Lastname
email = firstname_lastname#domain.co.uk
[http]
proxy = http://name:password#nnn.nnn.nnn.nnn:8080
And can clone a repository with the following command
D:\MercurialTesting>git clone http://Firstname_Lastname#bitbucket.org/Firstname_Lastname/bb102repo.git test1
Cloning into 'test1'...
Password for 'bitbucket.org':
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
D:\MercurialTesting>
With the addition of this config setting
[http]
sslverify = false
I can also clone the repository via the https url https://Firstname_Lastname#bitbucket.org/Firstname_Lastname/bb102repo.git
Using Mercurial though it's a different story. Using the following config in mercurial.ini
[http_proxy]
host = nnn.nnn.nnn.nnn:8080
user = firstname_lastname#domain.co.uk
passwd = password
Mercurial will access my own Mercurial server at home no problem.
D:\MercurialTesting>hg --debug clone http://nnn.nnn.nnn.nnn/hg/Workspaces/Test1
using http://nnn.nnn.nnn.nnn/hg/Workspaces/Test1
proxying through http://nnn.nnn.nnn.nnn:8080
sending capabilities command
http authorization required
realm: Mercurial Repositories
user: username
password:
http auth: user username, password *******
destination directory: Test1
query 1; heads
sending batch command
http auth: user username, password *******
requesting all changes
sending getbundle command
http auth: user username, password *******
adding changesets
changesets: 1 chunks
add changeset 711ff2c6f5b2
changesets: 2 chunks
add changeset 9034b963b4c1
. . .
Using the exact same configuration and trying to access BitBucket through Mercurial just hangs.
D:\MercurialTesting>hg --debug clone http://bitbucket.org/Firstname_Lastname/bb101repo
using http://bitbucket.org/Firstname_Lastname/bb101repo
proxying through http://nnn.nnn.nnn.nnn:8080
sending capabilities command
abort: error: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
D:\MercurialTesting>
Using the same configuration with SSL via the url https://bitbucket.org/Firstname_Lastname/bb101repo Mercurial hangs in exactly the same way. During this process Wireshark detects no network activity at all.
Changing the settings in Mercurial.ini to match the port which the proxy serves SSL through has no effect. Setting the environment variable http_proxy makes no difference, but setting the environment variable https_proxy changes the output completely. Setting https_proxy and adding --insecure to the hg command invocation results in:
D:\MercurialTesting>hg --debug clone http://bitbucket.org/Firstname_Lastname/bb101repo --insecure
using http://bitbucket.org/Firstname_Lastname/bb101repo
proxying through http://nnn.nnn.nnn.nnn:8080
sending capabilities command
warning: bitbucket.org certificate with fingerprint 79:ce:0d:30:b0:17:29:6a:d1:9f:dd:d3:62:80:70:28:5e:9f:c2:e3 not verified (check hostfingerprints or web.cacerts config setting)
http authorization required
realm: Bitbucket.org HTTP
user: Firstname_Lastname
password:
http auth: user Firstname_Lastname, password ***
warning: bitbucket.org certificate with fingerprint 79:ce:0d:30:b0:17:29:6a:d1:9f:dd:d3:62:80:70:28:5e:9f:c2:e3 not verified (check hostfingerprints or web.cacerts config setting)
abort: HTTP Error 502: Success
D:\MercurialTesting>
And now Wireshark does detect an exchange taking place between my workstation and the proxy server. What I find most confusing though is that it doesn't make the slightest difference what I set https_proxy to, hg always uses the http proxy setting from Mercurial.ini and produces the same output above irrespective of whether I set https_proxy to the correct details for the SSL proxy or to complete garbage. The only difference is that if the environment variable https_proxy isn't set at all then hg just hangs as described above.
The formats for https_proxy I've tried include all variations of:
https_proxy=ip.ip.ip.ip:8070
https_proxy=ip.ip.ip.ip:8080
https_proxy=username:password#ip.ip.ip.ip:8070
https_proxy=username:password#ip.ip.ip.ip:8080
https_proxy=http://ip.ip.ip.ip:8070
https_proxy=http://ip.ip.ip.ip:8080
https_proxy=http://username:password#ip.ip.ip.ip:8070
https_proxy=http://username:password#ip.ip.ip.ip:8080
The results are the same no matter what I set it to.
So the questions I could really use some help with are:
How come I can access my Mercurial repositories at home but not at BitBucket?
How come I can access BitBucket with Git but not with Mercurial using the same configuration?
Does anyone have any ideas of how I can get this to work or what I can test next?
I am also connecting via proxy to bitbucket. As my settings didn't work as expected I found this SO entry.
I noticed that if I use command line parameters then everything works.
hg --config http_proxy.host=192.168.1.1:8080 --config http_proxy.user=Vad1mo --config http_proxy.passwd=secret clone https://bitbucket.org/Vadimo/test
On the other hand same entries in Mercurial.ini didn't work.
[http_proxy]
host = 192.168.1.1
port = 8080
user = Vad1mo
passwd = internet
By accident I found out the tiny difference between CMD and ini. In CMD the port is postfixed to the host. In ini file it is a new entry.
Changing mercurial.ini to postfix the port to host like on command line solved the problem.
[http_proxy]
host = 192.168.1.1:8080
;port = 8080
user = Vad1mo
passwd = internet
Maybe this also will help you.
btw. my hg version is 2.6.3
I ran into a similar problem with my work's proxy- actually, almost identical.
I've gotten around the problem so far by setting the http_proxy in mercurial.ini and then connecting to BitBucket via their HTTP address hg.io.
For example, my repository at https://bitbucket.org/mattgwagner/mattgwagner.com can be accessed via http://hg.io/mattgwagner/mattgwagner.com . Of course, this will send your password and connection in plaintext, but at least it let me connect.
This came in more use for me when pulling in open source projects hosted on BitBucket for my use.
Mercurial.ini
[http_proxy]
host = 192.168.1.155:8080
no =
user = domainUsername
passwd = pass
Are you able to ssh out? Bitbucket supports ssh access and your proxy won't muck w/ that if it's allowed.