I have set up my outbound emails on phabricator by following this guide.
However, my emails don't arrive. All the emails are queued. When I went to the daemons in Phabricator UI, I see that several tasks are failing. They all look like this.
Task 448: PhabricatorMetaMTAWorker
Task 448
Task StatusQueuedTask ClassPhabricatorMetaMTAWorkerLease StatusLeasedLease Owner13195:1624502950:mail.icicbcoin.com:11Lease Expires1 h, 59 mDurationNot Completed
Data phabricator/ $ ./bin/mail show-outbound --id 154
Retries
Failure Count5Maximum Retries250Retries After1 m, 2 m, 4 m, 6 m, 8 m, 11 m, 14 m, 17 m, 20 m, 23 m, 27 m, ...
I'm curious of this data part. To me it sounds like phabricator fails running this command which is weir because if I run ./bin/mail show-outbound --id 154 manually I get this:
ID: 154
Status: queued
Related PHID:
Message: fputs(): send of 28 bytes failed with errno=32 Broken pipe
PARAMETERS
sensitive: 1
mustEncrypt:
subject: [Phabricator] Welcome to Phabricator
to: ["PHID-USER-qezqlvc7rxton2lshjue"]
force: 1
HEADERS
TEXT BODY
Welcome to Phabricator!
admin (John Doe) has created an account for you.
Username: some.person
To log in to Phabricator, follow this link and set a password:
http://phabricator.innolabsolutions.rs/login/once/welcome/9/b2jf7j6mg5xomwjhmcfcxbigs7474jyq/10/
After you have set a password, you can log in to Phabricator in the future by going here:
http://phabricator.innolabsolutions.rs/
Love,
Phabricator
HTML BODY
(This message has no HTML body.)
Actually, the problem was the SMTP server configuration, even though this error didn't tell me that. I changed the SMTP port from 465 to 587, restarted the daemons and it worked.
I had the same problem twice.
The second time, it was because I could not resolve the smtp server name:
$ ping gandi.net
ping: gandi.net: Temporary failure in name resolution
Then I added a dns server in /etc/resolv.conf
nameserver 127.0.0.1
nameserver 8.8.8.8 # <--- added
search home
and restarted the service
sudo service systemd-resolved restart
Right after, Phabricator automatically sent all the queued emails.
Related
i'm using Syslog-NG 3.8 as a syslog server receiving messages from many different sources, about 400 servers (& filtering them and relaying to a splunk server eventually).
however, it looks like many messages are "dropped" even before they are filtered and forwarded to the splunk instance.
i have a configuration where i'm keeping track of "incoming" messages before filtering in a flat file and i can't see some messages in there (see example below), while i can see the tcp trace successfully when running a tcpdump, meaning that Syslog-NG "drops" messages during the "source" mecanism.
i suspect this is due to the large mount of messages incoming on its interface, and i need to do some tuning with buffers & specific options.
here is a concrete example of the bug :
from the source machine, if i do a little loop sending messages every second with an ID that increments (so 20,21,22,23,24 & so on) :
root#sm1u1050vmo /var/log: for ((i=20;i<100;i++)); do logger -p auth.notice "test auth notice $i" ; sleep 1 ; done
if i tail the "incoming.log" flat file on Syslog-NG (receiver), i can see many missing messages :
[root#xm1p1034vmo 20]# tail -f incoming.log | grep sm1u1050vmo
Sep 20 12:27:32 sm1u1050vmo root: [ID 702911 auth.notice] test auth notice 28
Sep 20 12:27:34 sm1u1050vmo root: [ID 702911 auth.notice] test auth notice 30
Sep 20 12:27:37 sm1u1050vmo root: [ID 702911 auth.notice] test auth notice 33
Sep 20 12:27:42 sm1u1050vmo root: [ID 702911 auth.notice] test auth notice 38
Sep 20 12:27:43 sm1u1050vmo root: [ID 702911 auth.notice] test auth notice 39
Sep 20 12:27:52 sm1u1050vmo root: [ID 702911 auth.notice] test auth notice 48
we can clearly see many messages missing.
here is a small part of my config, with options & sources :
options {
chain_hostnames(no);
log_msg_size(8192);
time_reopen(2);
create_dirs(yes);
use_dns(yes);
keep_hostname(yes);
stats_freq(3600);
flush_lines(1);
log_fifo_size(1000);
};
the source being used :
source s_EXTERNAL {
network(transport("udp") log-fetch-limit(500));
};
the "local copy" destination being used to track these incoming messages before they are filtered :
destination d_INCOMING_ALL
{
file("/app/syslog-ng/logs/${YEAR}/${MONTH}/${DAY}/incoming.log" create-dirs(yes));
};
note, i am currently trying to play with options such as so-rcvbuf() in the source (& adapting the kernel parameter rmem_max at the same time). it was 16Mb and i increased it to 64M but it didn't change anything for now. i can still see RcvbufErrors & packet receive errors increasing when running a netstat -us
any hints please ?
thanks
I'd tell you a UDP joke, but you probably wouldn't get it. Seriously, UDP is not guaranteed to arrive. Change the protocol to TCP on each end, and you should be set. Protocol aside, if your system is dropping messages at the rate of 1 per second, you likely have configuration issues on your network or it's simply overloaded.
Emails are not being deliver to a particular email IDs.
We are using Sentora panel and Postfix mail server.
Error message:
Command died with signal 6: "/usr/libexec/dovecot/deliver"
Mail log:
Feb 14 09:50:27 host postfix/pipe[24913]: CBD7D2010A5: to=,
relay=dovecot, delay=13047, delays=13045/0/0/1.3, dsn=4.3.0,
status=SOFTBOUNCE (Command died with signal 6:
"/usr/libexec/dovecot/deliver")
Please help.
Signal 6 is SIGABRT, which is typically sent when there is an internal problem with the code of Dovecot's deliver binary. There are a number of reasons this could happen.
You can turn on LDA logging within your Dovecot config to get more insight on what's actually happening:
protocol lda {
...
# remember to give proper permissions for these files as well
log_path = /var/log/dovecot-lda-errors.log
info_log_path = /var/log/dovecot-lda.log
}
this can also happen when mail_temp_dir (default: /tmp) does not have enough space to extract attachments. it was fixed in https://github.com/dovecot/core/commit/43d7f354c44b358f45ddd10deb3742ec1cc94889 but is not yet available in some linux distributions (such as debian bullseye).
I want to SSH to a machine (call it A). It's sshd config file looks like below:
AllowGroups wheel
AllowTcpForwarding no
AuthorizedKeysFile .ssh/authorized_keys
Banner /etc/issue
ChallengeResponseAuthentication no
Ciphers aes256-ctr,aes128-ctr
Compression delayed
GatewayPorts no
MACs hmac-sha1
MaxSessions 1
PasswordAuthentication yes
PermitRootLogin yes
PermitTunnel no
PermitUserEnvironment no
Protocol 2
RhostsRSAAuthentication no
StrictModes yes
Subsystem sftp /usr/lib64/ssh/sftp-server
UsePAM yes
UsePrivilegeSeparation yes
X11Forwarding no
I have another machine (call it B - ssh client)
Now, if I try to ssh to machineA as below, it works perfect:
ssh root#machineA
and then interactively provide password. Works perfect!
Now, I try passing password via a script using sshpass utility as below:
sshpass -p PASSWORD ssh -vvv -o=StrictHostKeyChecking=no root#machineA
This fails.
Last few lines from debug of -vvv gives below:
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
debug3: packet_send2: adding 64 (len 51 padlen 13 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
/var/log/auth.log on machine A says below:
Connection from machineB port 44408
Failed password for root from machineB port 44408 ssh2
Connection closed by machineB port 44408 [preauth]
lastb command gives below:
root ssh:notty machineB Sun Jul 3 04:20 - 04:20 (00:00)
root ssh:notty machineB Sun Jul 3 04:19 - 04:19 (00:00)
I have been reading around for it. But, not something that I can stop at. Do you have any pointers? What could be the problem?
Anything related to sshpass or something?
I would try to narrow the problem:
Try with a simpler password, without special characters.
Try with a user different than root.
Try using certificates instead of password.
That is explained here: https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key , https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2 etc.
Have a look at the server logs as well, check /var/log/secure or alike.
Does it possible to check which DNS server used for resolving domain name (in intraned network)? We have many steps: proxy, BigIP, domain controllers, etc.
I have a complicated networks with many DNS server. Sometimes when in browser I use:
http://mysitedomainalias.mydomain.com
I receive web page,
sometime after near 15 minutes I receive error about timeout.
But when I use IP address instead of domain alias I always reach my web page.
So I have decided that it could be a problem with DNS server. I would like to know common way how to resolve similar problems.
On *NIX systems, dig is a standard tool to test and debug DNS servers:
deceze$ dig google.com
...
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 5 IN A 173.194.35.168
google.com. 5 IN A 173.194.35.161
google.com. 5 IN A 173.194.35.169
...
;; Query time: 84 msec
;; SERVER: 192.168.10.1#53(192.168.10.1)
;; WHEN: Mon Jul 14 15:59:05 2014
;; MSG SIZE rcvd: 204
In the last part, SERVER signifies which DNS server answered our request.
Some more things you can then do with dig:
query a specific DNS server instead of the system's default:
$ dig #mydns.example.com google.com
trace each step of the resolution chain to see any problems in the canonical name servers:
$ dig google.com +trace
query specific record types:
$ dig google.com NS
$ dig google.com MX
$ dig google.com ANY
See the manual: http://linux.die.net/man/1/dig
I'm trying to get the hang of hydra.
When I do this to test against my ftp site, it works. I'm hitting my own ftp site (ex. www.mysite.com) with the correct username and password (ex. username1 and password1):
./hydra -l username1 -p password1 -vV -f www.mysite.com ftp
Hydra v7.4.1 (c)2012 by van Hauser/THC & David Maciejak - for legal purposes only
Hydra (http://www.thc.org/thc-hydra) starting at 2012-12-29 21:06:20
[VERBOSE] More tasks defined than login/pass pairs exist. Tasks reduced to 1.
[DATA] 1 task, 1 server, 1 login try (l:1/p:1), ~1 try per task
[DATA] attacking service ftp on port 21
[VERBOSE] Resolving addresses ... done
[ATTEMPT] target www.mysite.com - login "username1" - pass "password1" - 1 of 1 [child 0]
[21][ftp] host: 200.200.240.240 login: username1 password: password1
[STATUS] attack finished for www.mysite.com (valid pair found)
1 of 1 target successfully completed, 1 valid password found
Hydra (http://www.thc.org/thc-hydra) finished at 2012-12-29 21:06:21
However, when I do this to test a public basic authentication test page (http://browserspy.dk/password-ok.php) with the correct username and password (test and test), hydra just stops with a 'Resolving address ... done' message.
./hydra -l test -p test -vV -f browserspy.dk http-get /password-ok.php
Hydra v7.4.1 (c)2012 by van Hauser/THC & David Maciejak - for legal purposes only
Hydra (http://www.thc.org/thc-hydra) starting at 2012-12-29 21:02:58
[VERBOSE] More tasks defined than login/pass pairs exist. Tasks reduced to 1.
[DATA] 1 task, 1 server, 1 login try (l:1/p:1), ~1 try per task
[DATA] attacking service http-get on port 80
[VERBOSE] Resolving addresses ... done
The hydra process just seems to die here and I'm returned to the command prompt.
What am I doing wrong?
You are not doing anything wrong, its a bug in hydra which affects the modes http-get, http-head and irc. Downgrade to v7.3 or wait for v7.5 which will fix this issue.