What is the difference between this two in NAPTR Record?
E2U+sip vs sip+E2U
"4.1.6.0.6.5.6.8.8.9.1 IN NAPTR 102 10 \"u\" \"E2U+sip\" \"!^44(.*)\$!sip:niraj\#userdomain.com!\" .",
"2.4.3.7.2.2.0.4.9.9.1 IN NAPTR 102 10 \"u\" \"E2U+sip\" \"!^44(.*)\$!sip:nidha\#userdomain.com!\" .",
Unfortunatly, "sip+E2U" was defined in the RFC2916
The order was bad and the newer RFC3824 has introduced an update to use "E2U+sip".
This is explained in Section 7. Compatibility with RFC 2916
The change was introduced in v3: diff between v2 and v3 draft for RFC3824
As explained in RFC3824, "sip+E2U" should still be supported:
For backwards compatibility with existing legacy records,
however, the 'sip+E2U' field SHOULD be supported by an ENUM
client that support SIP.
Related
I have a script that uses Net::SSH:Perl module. It is able to ssh to RHEL6.9 hosts but not RHEL7.4 hosts. I get the following error:
Protocol error: expected packet type 91, got 80 at /Net/SSH/Perl/Packet.pm line 221
How do I remedy this?
A simple search for the error message gives this post from 2016 and this bug report from 2016 which both indicate that the issue was fixed in version 2.01 of the module, released in 10/2016. Thus, you are probably using an older version and need to upgrade.
I am using FIWARE Orion (in a docker image) and I am facing with the possibility of losing some records. I looked in the log and came with a number of errors like the following:
time=Sunday 17 Dec 21:03:13 2017.743Z | lvl=ERROR | corr=N/A | trans=N/A | from=N/A | srv=N/A | subsrv=N/A | comp=Orion | op=safeMongo.cpp[287]:setStringVector | msg=Runtime Error (element 0 in array was supposed to be an string but type=3 from caller mongoSubCacheItemInsert:225)
According to http://fiware-orion.readthedocs.io/en/0.26.1/admin/logs/ these kind of errors (Runtime) "may cause the Context Broker to fail" and "should be reported to the Orion development team using the appropriate channel" and this is exactly what I am doing.
Any help, will be highly appreciated.
Thank you very much in advance.
EDIT: Orion version is 1.5.0-next
EDIT: It has been upgraded to 1.10.0
EDIT: After executing ps ax | grep contextBroker I receive the following results:
23470 ? Ssl 4:24 /usr/bin/contextBroker -fg -multiservice -dbhost mongodb
EDIT: The problem occurs periodically. Actually, it takes place exactly every minute:
time=Wednesday 20 Dec 20:50:27 2017.235Z
time=Wednesday 20 Dec 20:51:27 2017.237Z
etc.
Orion 1.5.0-next means some running version between 1.5.0 (released in October 2016) and 1.6.0 (released in December 2016). In the best case, your version is one year old, which is pretty much time.
Thus, I recommend you to upgrade to the newest available Orion version (in the moment of writting this, that version is 1.10.0, released in December 2017). We have solved some "overlogging" problems in the delta of changes between 1.6.0 and 1.10.0 and the one you mention could be one of them.
If the problem stills after upgrading, tell about it in a comment to the answer and we'll keep debuging.
Diagnosis
The 60 seconds periodicity is exactly the subscriptions cache refresh interval with default configuration (your CLI confirms your are not using different setting for subscriptions cache).
Looking in detail to the line refered by the log trace in Orion 1.10.0 source code:
setStringVectorF(sub, CSUB_CONDITIONS, &(cSubP->notifyConditionV));
The log error means that Orion expects an array of strings for the CSUB_CONDITIONS field in a document of the subscription collection at database, but some of the elements in the array (or all) aren't strings but a objects (type 3 means object, as BSON specification details).
CSUB_CONDITIONS constant corresponds to conditions field at DB. Note this field changed at Orion 1.3.0. Before 1.3.0, for instance 1.2.0, it was an array of objects:
"conditions" : [
{
"type" : "ONCHANGE",
"value" : [ "temperature " ]
}
]
From 1.3.0 on, it was simplified to an array of strings:
"conditions" : [ "temperature" ]
So my hypothesis is that in some moment in the past that Orion instance was updated crossing the 1.3.0 boundary but without applying the procedure to migrate data (or the procedure was applied but failed in some way).
Solution
Given that you are in a situtation in which your data at Orion database is probably inconsistent, the cleanest solution would be to remove your database. Or, at least, the csubscollection.
However, this is possible only in the case you can regenerate the data to be deleted in an easy way. If that is not feasible, you can try with the procedure to migrate data. In particular, the csub_merge_condvalues.py script should fix the problem although I'd recommend to apply the full procedure in order to fix other potential inconsistencies.
Take into account that the migration procedure was designed to be applied before start using the new Orion version. It seems you have been using post-1.3.0 Orion with pre-1.3.0 data for a time, so your data can have evolved in some unexpected way the procedure couldn't fix. Anyway, even in this case the procedure is better than nothing :)
Note that if you are using multiple services (it seems so for the -multiservice CLI parameter) you have to apply the clean/migration procedure to every per-service database.
I’m trying to use the Monitoring GE / Sextant tool called NGSI Adapter. I am trying to run the command line suggestion from https://github.com/telefonicaid/fiware-monitoring/blob/develop/README.rst#api-overview
I always get this response:
time=2016-03-16T11:06:18.794Z | lvl=INFO | trans=ciluqsqi1000077m2u9zwb8x5 | op=POST | msg=Request on resource /check_load with params id=host_1&type=host
time=2016-03-16T11:06:18.800Z | lvl=INFO | trans=ciluqsqi1000077m2u9zwb8x5 | op=POST | msg=Response status 200 OK
time=2016-03-16T11:05:07.004Z | lvl=INFO | trans=ciluqr73e0000umm2nir549ts | op=UpdateContext | msg=Request to ContextBroker at http://orion:1026...
time=2016-03-16T11:05:07.013Z | lvl=INFO | trans=ciluqr73e0000umm2nir549ts | op=UpdateContext | msg=Response status 415 Unsupported Media Type
From looking at the release notes to Orion 3.4.1, "Unsupported Media Type" indicates that the Content-Type in the request header is unacceptable. From browsing the code in lib/parsers/common/base.js it seems like NGSI Adapter only currently supports xml. I think that Orion now only supports JSON.
Am I correct that this incompatibility between NGSI Adapter and Orion exists?
When is a fix expected?
You're right.
Taking a look at the release notes, you’ll find that Orion 0.28.0 is the last version which includes XML support (deprecated since 0.23.0).
For that reason, a new NGSI Adapter v1.4.0 (included as part of FIWARE Monitoring 5.2.3) has been released. Please follow these instructions to install it and check documentation at ReadTheDocs.
Thank you for using FIWARE Monitoring.
I am writing an application (using .NET Framework 4.5.2 + SQL Server 2014 installed locally). The application needs to support both SQL Server 2014 and previous versions.
When reading data using the inbuilt SQLCLR-types (SqlGeometry, SqlGeography, SqlHierarchyID), the standard ADO.NET methods (e.g. DataReader.GetValues()) use the 10.0.0.0 assembly, and throw an exception due to a mismatch with the loaded (v11 or v12) version.
The reasoning is documented (though it takes a while to spot) in the Breaking Changes in SQL Server 2012 (for the 11.0.0.0 assembly). For SQL Server 2012, there are three workarounds listed:
Use Type System Version=SQL Server 2012 in the SQLConnection.ConnectionString
OR: Use app.config / runtime / assemblyBinding / dependentAssembly to re-map v10.0.0.0 to v11.0.0.0
OR (not a very "neat" way to handle it): rewrite your own code to manually deserialize from a SqlBytes instance...
When developing from a computer with SQL Server 2014 installed, the assembly version is v12.0.0.0, and similar issues arise:
System.InvalidCastException: Unable to cast object of type Microsoft.SqlServer.Types.SqlGeometry to type Microsoft.SqlServer.Types.SqlGeometry.
For SQL Server 2014 (other than the horrible manual deserialize approach), there only seems to be one workaround (not officially documented in the breaking-changes) - it would appear that the v4.5 SqlConnection hasn't yet caught up with the version of SQL Server:
Use app.config / runtime / assemblyBinding / dependentAssembly to re-map v10.0.0.0 to v12.0.0.0
Question: other than re-mapping v10.0.0.0 to v12.0.0.0 in app.config (which seems to work), is there any other (easier) approach that will use the referenced assembly version?
A quick code-example below shows the failure (without the assembly-remapping in place):
private static void DoStuff()
{
SqlGeography geog_val = SqlGeography.STGeomFromText(new SqlChars("POLYGON((-122.358 47.653, -122.348 47.649, -122.348 47.658, -122.358 47.658, -122.358 47.653))"), 4326);
SqlGeometry geom_val = SqlGeometry.Parse("LINESTRING(1 1,2 3,4 8, -6 3)");
prm_geog.Value = DBNull.Value; prm_geom.Value = geom_val; ReadReturnedSpatialColumns(cmd);
prm_geog.Value = geog_val; prm_geom.Value = DBNull.Value; ReadReturnedSpatialColumns(cmd);
}
private static void ReadReturnedSpatialColumns(SqlCommand cmd)
{
using (var dr = cmd.ExecuteReader(CommandBehavior.SingleRow))
{
dr.Read(); var items = new object[2]; dr.GetValues(items);
var geog_test = dr.IsDBNull(0) ? SqlGeography.Null : (SqlGeography)items[0];
var geom_test = dr.IsDBNull(1) ? SqlGeometry.Null : (SqlGeometry)items[1];
}
}
This issue still exists with Framework 4.6.1 and there appears to be no workaround apart from the 3 you've already discovered. So the short answer to your question is no.
However I would question if you really need version 12 of the spatial types, because (as far as I can tell) they don't add anything over the v11 types. If you'd prefer to use the v11 types so you can use the Type System Version=SQL Server 2012 workaround, you can install the Nuget package that incorporates all three versions (10, 11, 12) - it's specifically designed to allow you to deploy to servers where MSSQL may not be installed.
As a bonus, referencing that package directly and using Type System Version=SQL Server 2012 will ensure that your app will always be using the 2012 spatial types, so upgrading to SQL 2016 won't break anything if it decides to return a different version of them (e.g. 13, or 14, or whatever 2016 will use) by default.
I've been trying to get the Citrix XenApp client going - but as soon as it connects it crashes on Windows 7 64bit. Citrix support has 0 information on Windows 7, so I'm curious if others have gotten it to work, of it's just me.
thx.
CDViewer has stopped working
Description:
Stopped working
Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: cdviewer.exe
Problem Signature 02: 11.2.0.31560
Problem Signature 03: 4aac18be
Problem Signature 04: DesktopViewer
Problem Signature 05: 11.2.0.31560
Problem Signature 06: 4aac18ba
Problem Signature 07: 105
Problem Signature 08: 80
Problem Signature 09: System.IO.InvalidDataException
OS Version: 6.1.7600.2.0.0.256.48
Locale ID: 1033
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409
If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt
Found a workaround.
It has something to do with the version of Citrix that we're using on the server vs. the latest client version.
The workaround is rather simple, in Windows 7 you need to associate the ".ica" extension with C:\Program Files (x86)\Citrix\ICA Client\wfica32.exe program.
There's a hotfix for this, it has to do with the size of the Terminal Server public key, see
Citrix ICA clients may crash when they are connecting to a Windows Server 2008-based terminal server that has Citrix Presentation Server installed