Planet Collab

🔒
❌ About FreshRSS
There are new available articles, click to refresh the page.
Today — June 18th 2019Your RSS feeds

GIMP – How to cut out an object in GIMP and use as a Visio Stencil

By italchemy

1, Open image file

2. Layer >> Transparency >> Add Alpha Channel

3. Free Select tool (looks like knot) or Wizard wand tool

4. Drag and select the portion you want to cut

5. Select >> Invert

6. Use “Ctrl + X” to cut the background

7. Save As (Export As) .png file type to save. Export!

Yesterday — June 17th 2019Your RSS feeds

Rev.io Tackles SaaS Billing

By Dave Gilbert

For providers of software “fill in the blank” as a Service, accounting for monthly recurring charges becomes their lifeblood.  But these subscription services may actually reduce the overall profit margin, due to increased bookkeeping, oversight for customer retention (not to mention staying atop of late charges), and the sheer bulk of producing accurate bills every month.  One might even say, as Michael Cromwell as put it, “billing is the one thing I've seen be the bane of some customers existence.”

GIMP – How to cut out an object in GIMP and use as a Visio Stencil

By italchemy

1, Open image file

2. Layer >> Transparency >> Add Alpha Channel

3. Free Select tool (looks like knot) or Wizard wand tool

4. Drag and select the portion you want to cut

5. Select >> Invert

6. Use “Ctrl + X” to cut the background

7. Save As (Export As) .png file type to save. Export!

Before yesterdayYour RSS feeds

Postman Error Messages

By Keyboard Banger

Continuing on my previous post logging to Cisco APIC using Postman, you may encounter a couple of error messages. Postman could not get any response You may encounter a connectivity issue between Postman and Cisco APIC where you see the following error message: could not get any response Then there was an error connecting to https://172.16.77.1/api/aaaLogin.json. ...

The post Postman Error Messages appeared first on Keyboard Banger.

Using Postman to login to Cisco APIC

By Keyboard Banger

In my previous post I briefly described the initial usage of Postman. In this post I clarify how we can use Postman to login to the Cisco APIC. I’ve collected here a couple of nice blog posts about the theme. They are good illustrated so I won’t rewrite the same thing: Using Postman to send ...

The post Using Postman to login to Cisco APIC appeared first on Keyboard Banger.

Postman Tutorial

By Keyboard Banger

This is a quick tutorial to make you install and run Postman. Postman Chrome Postman was popular with its extension for Google Chrome. So the first thing you probably did is navigating to Google Chrome Webstore and downloading Postman extension. Then to access the Postman extension, type on the following URL on Google Chrome: chrome://apps/ ...

The post Postman Tutorial appeared first on Keyboard Banger.

RFC 8610: Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures

By Stéphane Bortzmeyer

Le format de données binaire CBOR, normalisé dans le RFC 7049, commence à avoir un certain succès. Il lui manquait juste un langage de schéma, permettant de décrire les données acceptables (comme Relax NG ou XML Schema pour XML, ou comme le projet - abandonné - JCR (« JSON Content Rules ») pour JSON). C'est désormais fait dans ce RFC, qui normalise le langage CDDL, « Concise Data Definition Language ».

La section 1 de notre RFC résume le cahier des charges : CDDL doit permettre de décrire sans ambiguïté un fichier CBOR acceptable pour un usage donné, il doit être lisible et rédigeable par un humain, tout en étant analysable par un programme, et doit permettre la validation automatique d'un fichier CBOR. Autrement dit, étant donné une description en CDDL en schema.cddl et un fichier CBOR en data.cbor, il faut qu'on puisse développer un outil validator qui permettra de lancer la commande validator data.cbor schema.cddl et qui dira si le fichier CBOR est conforme au schéma ou pas. (Un tel outil existe effectivement, il est présenté à la fin de cet article.) Comme CBOR utilise un modèle de données très proche de celui de JSON, CDDL peut (même si ce n'est pas son but principal) être utilisé pour décrire des fichiers JSON, ce que détaille l'annexe E du RFC, consacrée à l'utilisation de CDDL avec JSON (il y a quelques subtilités à respecter).

(Attention, il ne faut pas confondre notre CDDL avec la licence ayant le même acronyme.)

La section 2 de notre RFC explique les éléments de base d'un schéma CDDL. On y trouve les classiques nombres, booléens, chaînes de caractères, correspondant aux éléments identiques en CBOR. Pour les structures plus compliquées (tableaux et maps, c'est-à-dire dictionnaires, ce qu'on nomme objets en JSON), CDDL ne fournit qu'un seul mécanisme, le groupe. Un groupe est une liste de doublets {nom, valeur}, le nom pouvant être omis si on décrit un tableau. Avec ce concept de groupe, CDDL permet également de décrire ce que dans d'autres langages, on appelerait struct ou enregistrement.

La liste est encadrée par des parenthèses. Chaque donnée décrite en CDDL a un type, par exemple bool pour un booléen, uint pour un entier non signé ou tstr pour une chaîne de caractères. La définition indique également quel type majeur CBOR (RFC 7049, section 2.1) va être utilisé pour ce type CDDL. uint est évidemment le type majeur 0, bool est le type majeur 7, etc. (D'ailleurs, vous pouvez aussi créer des types en indiquant le type majeur CBOR, ce qui donne une grande liberté, et la possibilité d'influencer la sérialisation.) Une liste des types et valeurs prédéfinies (comme false et true) figure dans l'annexe D de notre RFC.

Voici un groupe à qui on donne le nom pii :

pii = (
       age: uint,
       name: tstr,
       employer: tstr
)
  
Et ici une donnée person est définie avec ce groupe :
person = {
        pii
}    
  
Comme person est défini avec des accolades, ce sera un dictionnaire (map). Le même groupe pii aurait pu être utilisé pour définir un tableau, en mettant entre crochets (et, dans ce cas, les noms seraient ignorés, seule la position compte).

On peut définir une donnée en utilisant un groupe et d'autres informations, ici, person et dog ont les attributs de identity et quelques uns en plus :

person = {
     identity,
     employer: tstr
}

dog = {
     identity,
     leash-length: float
}

identity = (
    age: 0..120, ; Ou "uint" mais, ici, on utilise les intervalles
    name: tstr
)
  
La syntaxe nom: valeur est en fait un cas particulier. La notation la plus générale est clé => valeur. Comme CBOR (contrairement à JSON) permet d'avoir des clés qui ne sont pas des chaînes de caractères, la notation avec le deux-points est là pour ce cas particulier, mais courant, où la clé est une chaîne de caractères. (age: int et "age" => int sont donc équivalents.)

Un autre exemple permet d'illustrer le fait que l'encodage CBOR en tableau ou en dictionnaire va dépendre de la syntaxe utilisée en CDDL (avec en prime les commentaires, précédés d'un point-virgule) :

Geography = [
           city           : tstr,
           gpsCoordinates : GpsCoordinates,
]

GpsCoordinates = {
           longitude      : uint,            ; multiplied by 10^7
           latitude       : uint,            ; multiplied by 10^7
}    
  
Dans le fichier CBOR, GpsCoordinates sera un dictionnaire (map) en raison de l'utilisation des accolades, et Geography sera un tableau (les noms city et gpsCoordinates seront donc ignorés).

Un champ d'un groupe peut être facultatif, en le faisant précéder d'un point d'interrogation, ou bien répété (avec une astérisque ou un plus) :

apartment = {
     kitchen: size,
     + bedroom: size,
     ? bathroom: size
   }  

size = float
  
Dans cet appartement, il y a exactement une cuisine, au moins une chambre et peut-être une salle de bains. Notez que l'outil cddl, présenté plus loin, ne créera pas d'appartements avec plusieurs chambres. C'est parce que CBOR, contrairement à JSON (mais pas à I-JSON, cf. RFC 7493, section 2.3), ne permet pas de clés répétées dans une map. On a ici un exemple du fait que CDDL peut décrire des cas qui ne pourront pas être sérialisés dans un format cible donné.

Revenons aux types. On a également le droit aux énumérations, les valeurs étant séparées par une barre oblique :

attire = "bow tie" / "necktie" / "Internet attire"

protocol = 6 / 17
  
C'est d'ailleurs ainsi qu'est défini le type booléen (c'est prédéfini, vous n'avez pas à taper cela) :
bool = false / true 
  
On peut aussi choisir entre groupes (et pas seulement entre types), avec deux barres obliques.

Et l'élement racine, on le reconnait comment ? C'est simplement le premier défini dans le schéma. À part cette règle, CDDL n'impose pas d'ordre aux définitions. Le RFC préfère partir des structures de plus haut niveau pour les détailler ensuite, mais on peut faire différemment, selon ses goûts personnels.

Pour les gens qui travaillent avec des protocoles réseau, il est souvent nécessaire de pouvoir fixer exactement la représentation des données. CDDL a la notion de contrôle, un contrôle étant une directive donnée à CDDL. Elle commence par un point. Ainsi, le contrôle .size indique la taille que doit prendre la donnée. Par exemple (bstr étant une chaîne d'octets) :

ip4 = bstr .size 4                                                                           
ip6 = bstr .size 16         
    
Un autre contrôle, .bits, permet de placer les bits exactement, ici pour l'en-tête TCP :

tcpflagbytes = bstr .bits flags
                      flags = &(
                        fin: 8,
                        syn: 9,
                        rst: 10,
                        psh: 11,
                        ack: 12,
                        urg: 13,
                        ece: 14,
                        cwr: 15,
                        ns: 0,
) / (4..7) ; data offset bits

    
Les contrôles existants figurent dans un registre IANA, et d'autres pourront y être ajoutés, en échange d'une spécification écrite (cf. RFC 8126).

La section 3 du RFC décrit la syntaxe formelle de CDDL. L'ABNF (RFC 5234) complet est en annexe B. CDDL lui-même ressemble à ABNF, d'ailleurs, avec quelques changements comme l'autorisation du point dans les noms. Une originalité plus fondamentale, documentée dans l'annexe A, est que la grammaire utilise les PEG et pas le formalisme traditionnel des grammaires génératives.

La section 4 de notre RFC couvre les différents usages de CDDL. Il peut être utilisé essentiellement pour les humains, une sorte de documentation formelle de ce que doit contenir un fichier CBOR. Il peut aussi servir pour écrire des logiciels qui vont permettre une édition du fichier CBOR guidée par le schéma (empêchant de mettre des mauvaises valeurs, par exemple, mais je ne connais pas de tels outils, à l'heure actuelle). CDDL peut aussi servir à la validation automatique de fichiers CBOR. (Des exemples sont donnés plus loin, avec l'outil cddl.) Enfin, CDDL pourrait être utilisé pour automatiser une partie de la génération d'outils d'analyse de fichiers CBOR, si ce format continue à se répandre.

Un exemple réaliste d'utilisation de CDDL est donné dans l'annexe H, qui met en œuvre les « reputons » du RFC 7071. Voici le schéma CDDL. Un autre exemple en annexe H est de réécrire des règles de l'ancien projet JCR (cf. Internet draft draft-newton-json-content-rules) en CDDL.

Quels sont les RFC et futurs RFC qui se servent de CDDL ? CDDL est utilisé par le RFC 8007 (son annexe A), le RFC 8152 et le RFC 8428. Il est également utilisé dans des travaux en cours comme le format C-DNS , sur lequel j'avais eu l'occasion de travailler lors d'un hackathon. Autre travail en cours, le système GRASP et dans OSCORE. En dehors du monde IETF, CDDL est utilisé dans Web Authentication.

Un outil, décrit dans l'annexe F du RFC, a été développé pour générer des fichiers CBOR d'exemple suivant une définition CDDL, et pour vérifier des fichiers CBOR existants. Comme beaucoup d'outils modernes, il faut l'installer en utilisant les logiciels spécifiques d'un langage de programmation, ici Ruby :

% gem install cddl
    
Voici un exemple, pour valider un fichier JSON (il peut évidemment aussi valider du CBOR, rappelez-vous que c'est presque le même modèle de données, et que CDDL peut être utilisé pour les deux) :
% cddl person.cddl validate person.json 
%
    
Ici, c'est bon. Quand le fichier de données ne correspond pas au schéma (ici, le membre foo n'est pas prévu) :
    
% cat person.json
{"age": 1198, "foo": "bar", "name": "tic", "employer": "tac"}

% cddl person.cddl validate person.json 
CDDL validation failure (nil for {"age"=>1198, "foo"=>"bar", "name"=>"tic", "employer"=>"tac"}):
["tac", [:prim, 3], nil]
C'est surtout quand le schéma lui-même a une erreur que les messages d'erreur de l'outil cddl sont particulièrement mauvais. Ici, pour un peu d'espace en trop :
% cddl person.cddl generate
*** Look for syntax problems around the %%% markers:
%%%person = {
       age: int,
       name: tstr,
       employer: tstr,%%%											            }
*** Parse error at 0 upto 69 of 93 (1439).

Et pour générer des fichiers de données d'exemple ?

% cat person.cddl
person = {
       "age" => uint, ; Or 'age: uint'
       name: tstr,
       employer: tstr
       }

% cddl person.cddl generate
{"age": 3413, "name": "tic", "employer": "tac"}
    
Ce format est du JSON mais c'est en fait le profil « diagnostic » de CBOR, décrit dans la section 6 du RFC 7049. (cddl person.cddl json-generate fabriquerait du JSON classique.) On peut avoir du CBOR binaire après une conversion avec les outils d'accompagnement :
% json2cbor.rb person.json > person.cbor
    
CBOR étant un format binaire, on ne peut pas le regarder directement, donc on se sert d'un outil spécialisé (même dépôt que le précédent) :
    
% cbor2pretty.rb person.cbor 
a3                     # map(3)
   63                  # text(3)
      616765           # "age"
   19 0d55             # unsigned(3413)
   64                  # text(4)
      6e616d65         # "name"
   63                  # text(3)
      746963           # "tic"
   68                  # text(8)
      656d706c6f796572 # "employer"
   63                  # text(3)
      746163           # "tac"
Et voilà, tout s'est bien passé, et le fichier CBOR est valide :
%  cddl person.cddl validate person.cbor
% 
  • June 13th 2019 at 02:00

[GIVEAWAY] Get Ready for National Take Your Dog to Work Day!

By Mac McCarver

Dogs (and pets in general) are a cherished part of life of many people’s lives. In fact, 98% of pet owners consider their pet a member of their family. They

The post [GIVEAWAY] Get Ready for National Take Your Dog to Work Day! appeared first on Inside the Asterisk.

Scheduled Call Routing for Pros

Schedule call routing is a useful service that will prohibit calls from going to places such as hunt groups and call centers when there is predictably nobody staffing them. With scheduled call routing you can avoid those after hours calls heading to an empty group. Within the service you should know where you want the calls to go if they're not going to the business hours service.

Cisco PCD Cluster Discovery Internal Error

By Administrator

Cisco PCD Cluster Discovery Internal Error

Have you ever used Cisco Prime Collaboration Deployment Tool to migrate Unified Communications from Legacy to New Cluster? If yes, then there are times when you may encounter an error “Internal Error” while discovering the machines. If you encounter such issues, follow ensure that you perform below checks.

  1. Verify if the License is Valid on Unified Communications. If you see any license issue, you need to re-host the licenses.
  2. For the Publisher or Subscriber where you are seeing “Internal Error“, Login to that Publisher/Subscriber via CLI and type “show version active” and verify if “ciscocm.ucmap_platformconfig.cop” file is present. If this file is not present, PCD will not be able to discover the Machines.

How to add “ciscocm.ucmap_platformconfig.cop” file manually?

  • Download WinSCP application and install in a system
  • Download SFTP application and install in the same system
  • Launch WinSCP and Enter PCD IP Address, Username as “adminsftp” and Password for PCD.
  • Go to COP folder and download ciscocm.ucmap_platformconfig.cop.sgn from PCD Server to your Desktop.
  • Login to the Cisco Unified Operating System Administration node in which COP file is missing >  “https://X.X.X.X/cmplatform”
  • Navigate Software Upgrades > Install/Upgrade
  • Source > Remote Filesystem
  • Directory > Enter the Directory where the cop file is placed
  • Server > Enter the SFTP IP Address of the Server in which cop file is copied
  • Username > Enter the SFTP Username you created on SFTP Application
  • Password > Enter the SFTP Password you created on SFTP Application
  • Click on Next
  • Select the COP file from the drop down menu and Install the file
  • Verify if the file is successfully installed
  • Reboot the Publisher/Subscriber in which you installed the COP file
  • Try to discover the machines again and see if the machine is discovered now. If the machine is not yet discovered, reboot the entire CUCM Cluster and then try to discover it again.

I hope this will help you to resolve your issue.

Cheers!!

Published by Team UC Collabing

The post Cisco PCD Cluster Discovery Internal Error appeared first on UC Collabing.

Find CUCM users that are LDAP inactive

By Web Maxtor
Note: status of 2 is inactive, 1 is active, and 0 is local run sql select count(*) from enduser where status=2 run sql select userid, firstname, lastname from enduser where status=2
  • June 11th 2019 at 12:35

Why Companies Still Use DECT Phones

By Jim Machi

The acronym DECT stands for Digital Enhanced Cordless Telecommunications. A DECT Phone is a cordless phone that connects to a phone network essentially via a radio frequency that to goes

The post Why Companies Still Use DECT Phones appeared first on Inside the Asterisk.

The Intelligent Next Step for Intent-Based Networking

By Scott Harrell

We, and our customers, have long understood that networks are most valuable when they do more than support their own weight. They become assets only when they enable the growth of business strategies. To get networks to work at this level, we have to get a higher level of performance and agility from them.

That’s why we launched a series of products and services based on intent-based networking two years ago. Our goal was to reinvent access networking to serve business needs. Intent-based networking turns intent into network policy, and it lets businesses innovate faster than ever.

Since we started working on intent-based networking, we’ve been focused on making it simple. As the technicalities of networking are complex, this focus is not something we’ll ever be fully done with. Simplifying advanced IT requires continuous refinement.

One big leap we’re making now is using the power of artificial intelligence (AI). It lets us simplify the experience that IT teams have with networking tools, and provides personalized and targeted insights into their operational environments.

We are also simplifying what it takes to manage multiple networking domains – by linking them together to provide key outcomes that network managers care about, like end to end segmentation with application SLAs (service-level agreements).

Artificial Intelligence Powers the Next Level of Intent-Based Networking

We can use the artificial intelligence  to make IT more efficient and proactive. With AI, we can deliver a network that operates at its peak performance. At the same time, we make it easier to manage.

For example, we address the fact that the number of devices attaching to networks is increasing quickly. From end-user devices to IoT equipment, many networks are seeing exponential growth. This increase in network complexity is leading to an increase in alerts from management consoles. But IT teams, with their limited resources, are only able to pay attention to the highest-priority incidents. They end up ignoring the less urgent, but still important, indicators of network under-performance.

Having networks send their operators only the right alerts, though, isn’t something that can be done just by setting coarse threshold bands. Every network is different.  Every building in campus network is different. Each floor within a building is different. And these networks are constantly changing. We need to apply AI to optimize network management, to surface the alerts that are truly important for each unique environment.  With AI, we can customize alerts for every building, every floor and every room – with actionable insights that allow teams to quickly and proactively mitigate problems.

In early field trials of Cisco AI Network Analytics, we have seen the number of flagged incidents reduced by up to 75%. One of our customers, with a three-person network management team, tells us they call Cisco AI technology the “fourth member of the team.”

Having an AI tool to prioritize — and increasingly, remediate — network alerts means IT staff can spend more of their time and resources on strategic projects that make their business better, more efficient, and more competitive.

AI Network Analytics Reduces Noise for Greater IT Efficiency

AI can effectively filter and prioritize alerts.

The quality of the AI-driven improvement depends, of course, on the quality of the data. The more devices you collect data from – end user smartphones, switches, WAN routers, cloud servers, and everything connecting them – the better. That’s why we build telemetry into all the products we make. And we have 35 years of experience across all the domains of networking – experience that goes beyond raw data. We are combining that pattern-matching human knowledge of how networks work, with real-time telemetry, to move into a new field of AI, machine reasoning, to create even more intelligent network management.

Network teams can also use the network telemetry as a raw business resource. Networks are sensors, not just wires. A network can know how employees and customers use resources – increasingly, physical resources like buildings and equipment – and that data can be an invaluable resource in creating competitive advantage.

Integrating Network Policies

It’s also time to start unifying network management across domains. No network is an island, and yet they have been traditionally managed as if they were. Even inside a single enterprise, there are multiple networking domains, each supporting a unique role — from the campus and IoT networks that identify and onboard devices and authorize access, to the WAN network responsible for securely connecting to a hybrid cloud environment with a great application experience, to the data center and cloud networks where workloads are distributed and where protecting against data breaches is utterly critical.

Operating policies that govern network actions are defined in each of the domains. But the needs of a business are not fulfilled by one domain alone. All need to work together so that, for example, a doctor in a clinic can securely run a diagnostic application in the data center with adequate quality of experience over the WAN that connects them to it – a task that touches at least three traditionally separately-controlled networks.

To meet this business intent, domains must exchange relevant policies, so that the entire network works in concert.

In our example, the access network that onboards and authorizes the doctor must let the data center network know of their privileges to run the medical diagnostic application. Similarly, the data center network must tell the WAN of the critical nature of the application and how its traffic must be prioritized. When the doctor moves to a different clinic, the policies that govern their usage should follow.

Applying policies across domains can also be simplified.

Without such integrations, IT teams for each domain need to coordinate and then manually implement different policies. With the rapid pace of change, that may not even be possible.

Multidomain integration means that policy applied in one place (like the access network) will get applied to the other networks (like SD-WAN and data center) that are involved in delivering the desired result. Each domain continues to support its primary role, but as changes occur, it will dynamically update across other domains.

Improving the Human Element

AI tools and automation for multiple domains will get us closer to the IBN vision and will dramatically free up IT teams so skilled network operators can work on strategic projects – projects that may appear out of reach today due to the fire-fighting nature of network management. Based on talks I have with customers, I know that there is no end to the number of interesting and lucrative projects our users could be working on. And we want to help.

We recognize that network engineers and IT teams will need new skills and practices to take advantage of these tools. Our own Cisco DevNet can help lead the way: Resources are available now to help build network automation across domains with the new DevNet Automation Exchange. New DevNet certifications will help engineers build critical software skills and infrastructure expertise to keep on top of the latest IT developments.

Smart software will soon be able to do more for our networks than ever. But to keep a business ahead of the game, IT teams need to know how to use it to its best advantage. There’s so much still to do when it comes to leveraging the power of interconnected systems. We want to help networks get smarter, and we want to be sure they all have the best-informed people available to manage them.

Get the latest news from Cisco Live 2019, happening June 9 to 13 in San Diego, California. 

 

How to Differentiate in a Crowded Field

The UCaaS market is rich in opportunity, which leads to many providers entering the fray.  How can you stand out in a field that is already crowded, and looks to be more so in the coming years?

❌