My project use quickfixj to connect with my client in HongKong, config starttime and endtime in client is set: 08:01 – 21:30 HKT.
I config server is:(My timezone UTC +7)
StartTime=23:55:00
EndTime=14:35:00
In by default UTC +0 but connect failed.
My config is true?
I set CheckLatency=N. Here my configuation:
[default]
ConnectionType=acceptor
StartTime=04:05:00
EndTime=12:00:00
EncryptMethod=0
UseDataDictionary=Y
CheckLatency=N
CheckCompID=N
FileStorePath=.\fixacceptor
FileLogPath=.\logacceptor
FileLogHeartbeats=Y
FileIncludeMilliseconds=Y
FileIncludeTimeStampForMessages=Y
FileStoreMaxCachedMsgs=0
[session]
BeginString=FIX.4.2
SenderCompID=FixAcceptor
TargetCompID=FixClient8080
SocketAcceptPort=5001
ClosedResendInterval=Y
DataDictionary=.\FIX42.xml
ValidateFieldsOutOfOrder=N
ValidateFieldsHaveValues=N
ValidateUserDefinedFields=N
AllowUnknownMsgFields=Y
SendRedundantResendRequests=Y
Related
Im using rsyslog on server to collect logs from remote hosts.
Collect server config:
# timedatectl
Local time: Wed 2022-04-27 16:02:43 MSK
Universal time: Wed 2022-04-27 13:02:43 UTC
RTC time: n/a
Time zone: Europe/Moscow (MSK, +0300)
System clock synchronized: yes
NTP service: inactive
RTC in local TZ: no
# cat /etc/rsyslog.d/20_external.conf
$CreateDirs on
$PreserveFQDN on
# provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")
# provides TCP syslog reception
module(load="imtcp")
input(type="imtcp" port="514")
template(
name="external"
type="string"
string="/var/log/external/%HOSTNAME%/%syslogfacility-text%.%programname%.%syslogseverity-text%.log"
)
action(
type="omfile"
dirCreateMode="0775"
FileCreateMode="0644"
dynaFile="external"
)
On remote host
# timedatectl
Local time: Wed 2022-04-27 13:04:03 UTC
Universal time: Wed 2022-04-27 13:04:03 UTC
RTC time: n/a
Time zone: UTC (UTC, +0000)
System clock synchronized: yes
NTP service: inactive
RTC in local TZ: no
# cat /etc/rsyslog.d/10-external.conf
*.* #rserver
# logger "hello, local time $(date)"
And get on rsyslogserver:
cat /var/log/external/ruser.home.xmu/user.root.notice.log
2022-04-27T13:07:06+03:00 ruser.home.xmu root: hello, local time 2022-04-27T13:07:06 UTC
# date
2022-04-27T16:08:56 MSK
What i can do for change time zone settings for some remote hosts on collect-server?
When i reserch incedents from all servers the time does not match in logs. I want the time on the collector in the logs to be in his time zone.
2022-04-27T16:07:06+03:00 ruser.home.xmu root: hello, local time 2022-04-27T13:07:06 UTC
You can define the timezone in rsyslog on the client - which in my opinion is the cleaner solution.
In /etc/rsyslog.conf do the following:
Comment/remove the current template
# Use default timestamp format
#$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
Then add the timezone, as well as a custom log template:
timezone(id="MSK" offset="+03:00")
# Custom time format
$template myTemplate,"%timegenerated% %HOSTNAME% %syslogtag%%msg%\n"
$ActionFileDefaultTemplate myTemplate
However, if you can't access the remote client which is sending the logs, it's possible to use the timestamp when the log was received on the server.
$template myTemplate,"%timegenerated% %HOSTNAME% %syslogtag%%msg%\n"
ruleset(name="myRuleset"){
$ActionFileDefaultTemplate myTemplate
# Do some other stuff
}
module(load="imtcp")
input(type="imtcp" port="5000" ruleset="myRuleset")
module(load="imudp")
input(type="imudp" port="5000" ruleset="myRuleset")
NOTE: Don't forget to restart the rsyslog service after applying the changes.
sudo service rsyslog restart
EDIT:
Creating a template using the advanced syntax would look like the following:
template (name="myTemplate" type="string"
string="%timegenerated% %HOSTNAME% %syslogtag%%msg%\n")
The string is the actual template of the messages that should be logged, not the destination to which the messages should be logged.
I ran into a similar problem recently. I think the simplest way to synchronize data coming from multiple sources is to use UTC timestamps everywhere, this way you avoid any timezone and summer time/winter time problems.
I think the problem here (and the problem I had) is that the syslog ouput uses the rfc3164 format which does not include the timezone information:
<6>Feb 28 12:00:00 192.168.0.1 fluentd[11111]: [error] Hello!
There's no way of knowing at what time that message actually happened without the timezone information. Since rsyslog version 8.18.0 what you can do though is define custom rsyslog templates that print the timestamps in UTC. If you use UTC everywhere you don't need that timestamp information anymore.
I'm sending my logs to fluentd, I use the following configuration in my rsyslog.conf file on my hosts:
template(
name="UTCTraditionalForwardFormat"
type="string"
string="<%PRI%>%TIMESTAMP:::date-utc% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%"
)
*.* action(
type="omfwd"
Target="10.5.0.9"
Port="5145"
Protocol="udp"
Template="UTCTraditionalForwardFormat"
)
The UTCTraditionalForwardFormat here is the same as the default template RSYSLOG_TraditionalForwardFormat (rsyslog templates) but with an added :::date-utc to the TIMESTAMP property.
On your rsyslog that collects logs, looking at the input module's doc there an experimental parameter DefaultTZ which should let you define the source timezone, something like this should work (I haven't tested):
input(
type="imudp"
port="514"
DefaultTZ="+00:00"
)
Assuming this DefaultTZ parameter works, this should work regardless of your hosts timezone.
Little word about fluentd, the fluentd syslog module also accepts the rfc5424 message format which does encode timezone information. I decided not to go this way though because rsyslog default templates does not seem to have a real rfc5424 version (the RSYSLOG_SyslogProtocol23Format template is very close to the rfc5424, but I don't know how close).
summary = 0 in 00:00:00 = ******/s Avg: 0 Min: 9223372036854775807 Max: -9223372036854775808 Err: 0 (0.00%) Tidying up ... # Thu Nov 21 09:13:03 UTC 2019 (1574327583681) Error generating the report: org.apache.jmeter.report.core.SampleException: Could not read metadata ! ... end of run Finished: SUCCESS
As per your Summariser output:
summary = 0 in 00:00:0
it means that 0 Samplers were executed, to wit your there are no results to parse/plot. I would recommend checking jmeter.log file for any suspicious entries, in case of JMeter failure the root cause can be figured out from the log file.
If you have problems with interpreting the log - update your question with the log file contents.
Are you using transaction controller in your script?If that is the case then update following line to false in jmeter property file,it will resolve your issue
With value set to true :
With value set to false:
I've looked through the list of possible solutions, but I don't see this problem, here it is.
I had been using smtp for years for my crontab entry to provide status updates via email. Then it quit this week, and I was unable to fix it. Then I saw that it had become orphaned, and the suggestion was to move to msmtp. So I downloaded and installed it on my Ubuntu 18.10 system.
I'm trying to send email to my myaccount#gmail.com account.
It appears that I'm communicating properly with the gmail smtp server, as the debug below show. But it always gets a TLS Timeout.
I also don't understand why I have multiple EHLO entries. My system does not have a DNS domain name, so that I'm not sure what to put here; localhost seems to be working OK. Also, my Thunderbird emailer is working correctly with gmail.
Here's the debug output:
echo "Hello there" | msmtp --debug myaccount#gmail.com >/tmp/msmtpOut.txt
ignoring system configuration file /etc/msmtprc: No such file or directory
loaded user configuration file /home/myhome/.msmtprc
falling back to default account
using account default from /home/myhome/.msmtprc
host = smtp.gmail.com
port = 587
proxy host = (not set)
proxy port = 0
timeout = off
protocol = smtp
domain = localhost
auth = choose
user = myaccount
password = *
passwordeval = (not set)
ntlmdomain = (not set)
tls = on
tls_starttls = on
tls_trust_file = /etc/ssl/certs/ca-certificates.crt
tls_crl_file = (not set)
tls_fingerprint = (not set)
tls_key_file = (not set)
tls_cert_file = (not set)
tls_certcheck = on
tls_min_dh_prime_bits = (not set)
tls_priorities = (not set)
auto_from = off
maildomain = (not set)
from = myaccount#gmail.com
add_missing_from_header = on
dsn_notify = (not set)
dsn_return = (not set)
logfile = (not set)
syslog = (not set)
aliases = (not set)
reading recipients from the command line
<-- 220 smtp.gmail.com ESMTP 4sm116524ywc.22 - gsmtp
--> EHLO localhost
<-- 250-smtp.gmail.com at your service, [71.56.87.81]
<-- 250-SIZE 35882577
<-- 250-8BITMIME
<-- 250-STARTTLS
<-- 250-ENHANCEDSTATUSCODES
<-- 250-PIPELINING
<-- 250-CHUNKING
<-- 250 SMTPUTF8
--> STARTTLS
<-- 220 2.0.0 Ready to start TLS
TLS certificate information:
Owner:
Common Name: smtp.gmail.com
Organization: Google LLC
Locality: Mountain View
State or Province: California
Country: US
Issuer:
Common Name: Google Internet Authority G3
Organization: Google Trust Services
Country: US
Validity:
Activation time: Tue 21 May 2019 04:48:45 PM EDT
Expiration time: Tue 13 Aug 2019 04:32:00 PM EDT
Fingerprints:
SHA256: C7:78:B6:D6:4E:3E:2B:2F:08:6D:A4:84:E6:1D:87:8E:A1:DF:54:D2:AB:79:AC:A6:BB:50:E5:5D:EC:B4:20:4C
SHA1 (deprecated): 39:C5:E5:40:64:37:17:25:17:7F:E8:BA:20:F4:70:F4:FE:22:70:22
--> EHLO localhost
msmtp: cannot read from TLS connection: the operation timed out
msmtp: could not send mail (account default from /home/myhome/.msmtprc)
Build msmtp using --with-tls=openssl to solve the problem.
As regards as the EHLO command sent twice the RFC3207 states:
The server MUST discard any knowledge
obtained from the client, such as the argument to the EHLO command,
which was not obtained from the TLS negotiation itself. The client
MUST discard any knowledge obtained from the server, such as the list
of SMTP service extensions, which was not obtained from the TLS
negotiation itself. The client SHOULD send an EHLO command as the
first command after a successful TLS negotiation.
So that is the normal behaviour.
I have developed an application which is very (JodaTime) DateTime centric (calendar and so on). Locally at my computer all works fine. I have deployed my app at cloudfoundry and there no dates are visible in the calendar.
I guess that this has something to do with the timezone of cloudfoundry. I have connected my locally running application to the mongodb database in the coud and everything works find.
My question now would be how to change timezone at cloudfoundry to CEST (MEZ)?
Thanks a lot!
Your Java application is going to run in a Linux container, so you can use any Linux or Java method of setting the timezone.
The easy ones that come to mind...
cf set-env <app-name> TZ 'America/Los_Angeles'
cf restage <app-name>
or
cf set-env <app-name> JAVA_OPTS '-Duser.timezone=Europe/Sofia'
cf restage <app-name>
The first should be generic to any application that respects the TZ environment variable. The second is specific to Java.
If you don't want to use cf set-env you could alternatively set the environment variables via your manifest.yml file.
To expand on #DanielMikusa. (Great Answer)
SAMPLE MANIFEST:
applications:
- path: .
buildpack: nodejs_buildpack
memory: 128M
instances: 1
name: sampleCronJobService
health-check-type: process
disk_quota: 1024M
env:
TZ: Etc/Greenwich
CF_STAGING_TIMEOUT: 15
CF_STARTUP_TIMEOUT: 15
TIMEOUT: 180
SuperSecret: passwordToTheWorld
WHY I KNOW IT WORKS:
var date = new Date();
var utc_hour = date.getUTCHours();
var local_hour = date.getHours();
console.log('(Timezone) Local Hour: ' + local_hour + ' UTC Hour: ' + utc_hour);
Prints: (Timezone) Local Hour: 23 UTC Hour: 23
If I set the manifest to have TZ: America/Los_Angeles
It Prints: (Timezone) Local Hour: 16 UTC Hour: 23
I am attempting to port REDHAWK 1.9.0 to Fedora 20. I have been (so far as I can tell) successful at coercing everything into compiling. However, I am unable to get a domain to instantiate properly. After selecting a domain and device manager, I receive the message:
Failed to connect to domain: REDHAWK_DEV
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No
OmniNames and OmniEvents are running happily, but REDHAWK isn't interfacing properly.
The console provides a little more info:
Jan 08, 2014 6:01:30 PM com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl <init>
WARNING: "IOP00410201: (COMM_FAILURE) Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: 192.168.118.129; port: 900"
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No
at com.sun.corba.se.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2200)
at com.sun.corba.se.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2221)
at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:223)
...and so forth
Since the error message concerns port 900, there seems to be some issue with the Java bootstrapping function.
My cfg file is simple:
InitRef = NameService=corbaname::127.0.0.1:2809
InitRef = EventService=corbaloc::127.0.0.1:11169/omniEvents
endPoint = giop:tcp:127.0.0.1:
endPoint = giop:unix:
endPointPublish = all(addr)
supportBootstrapAgent=1
I have tried various permutations of bootstrapAgentHostname and
bootstrapAgentPort in the config file, and have disabled IPv6, but without luck.
Any suggestions on what I might be doing wrong, or what configuration options I may be missing in the configuration file?