xrdp is defacto the default RDP server for Linux systems sharing with VNC the remote access solution olympus. I personally found it more resource friendly and feature rich compared to VNC solutions I tried.

The only problem I found with xrdp is that current Ubuntu LTS release Xenial 16.04 has a way outdated 0.6.1-2 version of xrdp in the packages repo. This version has no shared clipboard support, which makes remote support/remote access a tedious task.

xrdp currently in its 0.9.3 version and it would be really nice to have a more recent package, rather than installing it from sources, like many solutions propose.

Well, no need to compile xrdp from sources (unless you want to), because you can leverage a ppa from hermlnx that has xrdp 0.9.1-7 already built for amd64 and i386 systems

# all you need is
sudo add-apt-repository ppa:hermlnx/xrdp
sudo apt-get update
sudo apt-get install xrdp

You can also try a deb package of xrdp 0.9.2https://github.com/suminona/xrdp-ru-audio


Continue reading

While Amazon Linux AMI has yum as a package manager, it is not that all compatible with any RHEL or CentOS distributive. A lot of changes that AWS team brought into this image made it a separate distro, so no eyebrows should be given when battle-tested procedure to install python3 will fail on Amazon Linux. (Yeah, python3 does not come included yet in Amazon Linux)


Continue reading

Hugo gets a lot of attention these days, it is basically snapping at the Jekyll’ heels which is still the king of the hill! I don’t know if Hugo’ popularity coupled with the fastest static-site-generator statement, but for me “speed” is not the issue at all. A personal blog normally has few hundreds posts, not even close to thousands to be worried about slowness.

Then if it is not for speed then why did I choose Hugo? Because it became a solid product with a crowded community and all the common features available. (To be honest I also got an illusion that one day I might start sharpen my Go skills through Hugo as well).

As you already noticed, this blog is powered by Hugo, is running on GitLab pages, with SSL certificate from CloudFlare and costs me $0. And I would like to write down the key pieces that’ll probably be of help on your path to a zero-cost personal blog/cv/landing/etc.
Continue reading

I started to play with Go aka Golang. Yeah, leaving the comfort zone, all that buzz. And for quite some time I’ve been engaged with VS Code whenever/wherever I did dev activities.

VS Code has a solid Go support via its official extension:

This extension adds rich language support for the Go language to VS Code, including:

  • Completion Lists (using gocode)
  • Signature Help (using gogetdoc or godef+godoc)
  • Quick Info (using gogetdoc or godef+godoc)
  • Goto Definition (using gogetdoc or godef+godoc)
  • Find References (using guru)
  • File outline (using go-outline)
  • Workspace symbol search (using go-symbols)
  • Rename (using gorename)
  • Build-on-save (using go build and go test)
  • Lint-on-save (using golint or gometalinter)
  • Format (using goreturns or goimports or gofmt)
  • Generate unit tests skeleton (using gotests)
  • Add Imports (using gopkgs)
  • Add/Remove Tags on struct fields (using gomodifytags)
  • Semantic/Syntactic error reporting as you type (using gotype-live)

Mark that gotools in the brackets, these ones are powering all that extra functionality and got installed into your GOPATH once you install them via VS Code.

And here you might face an issue if you want to use Go + VS Code both on Mac and Linux using the Dropbox folder (or any other syncing service). The issue is that binaries for Mac and Linux will overwrite themselves once you decide to install the extension on your second platform. Indeed, by default VS Code will fetch the source code of the tools and build them, placing binaries in the $GOPATH/bin.

Lucky we, the Go Extension developers have a special setting to put extension dependencies to a different $GOPATH:

Tools this extension depends on

This extension uses a host of Go tools to provide the various rich features. These tools are installed in your GOPATH by default. If you wish to have the extension use a separate GOPATH for its tools, provide the desired location in the setting go.toolsGopath. Read more about this and the tools at Go tools that the Go extension depends on

And thats it, open your settings.json, put something like

"go.toolsGopath": "~/.gotools"

and thats it, next time you hit “install” of Go Extension dependencies, they will be stored outside your Dropbox-powered $GOPATH and won’t interfere with each other.


Continue reading

Nothing bad in knowing how many lines of code or text out there in your repo. You don’t even need your VCS to convey this analytics. All you need is git, grep and wc.

# count lines in .py and .robot files in /nuage-cats dir of the repo
$ git ls-files nuage-cats/ | grep -E ".*(py|robot)" | xargs wc -l
       0 nuage-cats/robot_lib/__init__.py
     817 nuage-cats/robot_lib/lib/NuageQoS.py
     409 nuage-cats/robot_lib/lib/NuageVCIN.py
    1841 nuage-cats/robot_lib/lib/NuageVNS.py
    2964 nuage-cats/robot_lib/lib/NuageVSD.py
    # OMITTED
      26 nuage-cats/test_suites/0910_fail_bridges_kvm_vms/0910_fail_bridges_kvm_vms.robot
   13636 total


Continue reading

Cloud-native revolution pointed out the fact that the microservice is the new building block and your best friends now are Containers, AWS, GCE, Openshift, Kubernetes, you-name-it. But suddenly micro became not that granular enough and people started talking about serverless functions!

Brian Christner, Docker & Serverless: https://www.slideshare.net/BrianChristner/docker-serverless Brian Christner, Docker & Serverless: https://www.slideshare.net/BrianChristner/docker-serverless

When I decided to step in the serverless property I chose AWS Lambda as my instrument of choice. As for experimental subject, I picked up one of my existing projects - a script that tracks new documentation releases for Nokia IP/SDN products (which I aggregate at nokdoc.github.io).

Given that not so many posts are going deeper than onboarding a simplest function, I decided to write down the key pieces I needed to uncover to push a real code to the Lambda.

Buckle up, our agenda is fascinating:

  • testing basic Lambda onboarding process powered by Serverless framework
  • accessing files in AWS S3 from within our Lambda with boto3 package and custom AWS IAM role
  • packaging non-standard python modules for our Lambda
  • exploring ways to provision shared code for Lambdas
  • and using path variables to branch out the code in Lambda


Continue reading

Author's picture

Roman Dodin

Eagerness to learn & passion to share

Netdevops @ Nuage Networks

Russia