I faced with problem that ttserver in LSP config suggests me certain the same suggestions depended on different servers. Here is an example below
example - https://i.stack.imgur.com/5K31A.png
Here is my lsp config too
lsp-config - https://i.stack.imgur.com/5ig5j.png
Related
With LGTM.com being shut down I am looking to enable code analysis in Github to run the same analysis that lgtm.com does. At the first glance on Github's workflow, it seems to me it is only running a subset of scanning rules that are security related. I have found lgtm's default rules very useful (those that alerts unused imports etc.) How can I configure Github's code scanning to run the same rules as lgtm does?
By default CodeQL code scanning only runs security queries, but you can enable more queries as described here in the documentation:
- name: Initialize CodeQL
uses: github/codeql-action/init#v2
with:
# Run more security queries, and maintainability and reliability queries
queries: security-and-quality
(though I am not sure if they are exactly the same queries which are used by LGTM.com; which queries are selected seems to be defined here and here)
As I am new to coredns configurations in kubernetes and I'm trying to explore plugins provided by coredns in kubernetes. I see a plugin named local which will respond with a reply to local requests. But I could not understand a use-case where this plugin will be exactly useful for. Can someone explain with an example how it can be make use of? Also in unbound configuration man page, I see an option called local-zone: .
local-zone:
Configure a local zone. The type determines the answer to give if there is no match from local-data. The types are deny, refuse, static, transparent, redirect, nodefault, typetransparent, and are explained below. After that the default settings are listed. Use local-data: to enter data into the local zone. Answers for local zones are authoritative DNS answers. By default the zones are class IN.
nodefault:
Used to turn off default contents for AS112 zones. The other types also turn off default contents for the zone. The 'nodefault' option has no other effect than turning off default contents for the given zone.
Is this local plugin behaves similar to this unbound local-zone option? If not, Is there any plugin which act similar to local-zone in unbound ? I am expecting a coredns plugin to behave similar to local-data in unbound particularly for nodefault type in local-data. eg: local-zone: nodefault. It would be really helpful if someone helps me to clear out this. Thanks in advance!!!
As the author of the local plugin for CoreDNS explains, localhost.<searchpath> queries are hitting coredns, which is wrong. So, he wrote this plugin to intercept localhost.<'domain'> queries and return the correct response.
From the official CoreDNS github web page:
local will respond with a basic reply to a "local request". Local request are defined to be names in the following zones: localhost, 0.in-addr.arpa, 127.in-addr.arpa and 255.in-addr.arpa and any query asking for localhost.<domain>.
With local enabled any query falling under these zones will get a reply. This prevents the query from "escaping" to the internet and putting strain on external infrastructure.
You can check the code of the local plugin here. I don't see similar to the unbound local-zone nodefault functionality there.
See all in-tree plugins for CoreDNS here.
The Salt docs are full of this kind of pattern:
apache:
pkg:
- installed
service:
- running
- require:
- pkg: apache
This repetition ("install apache, now check whether apache was installed") seems to be a violation of don't-repeat-yourself (DRY). So is it necessary?
From "Understanding State Ordering":
To accomplish something similar to how classical imperative systems function all requisites can be omitted and the failhard option then set to True in the master configuration, this will stop all state runs at the first instance of a failure.
This seems to imply that the use of requisites everywhere is actually optional (assuming that the declaration order is correct) - but I'd like to know for sure.
It is a remnant of the pre 0.15 days when states weren't executed top down.
Ordering is now sufficient.
States are now executed in the order they are declared in your sls files. Where you will still want to use "require" is if you want to ensure a certain state executes successfully before another.
For example, you may want to ensure a software package is installed correctly before attempting to lay down a config file.
apache:
pkg:
- installed
file:
- managed
- name: /etc/apache/httpd.conf
- source: salt://apache/httpd.conf
- require:
- pkg: apache
Without the "require" in the above example, the config file would be laid down even if the apache pkg failed to install.
In Eclipse+Counterclockwise, when I want to connect to REPL, the dialog tells me I can use nREPL over HTTP:
How to set this up? Is this somehow connected to drawbridge? I haven't been able to make these work together, although lein repl :connect http://my.url/repl worked for me.
For clarity, why this is useful compared to classic REPL: classic REPL works for localhost only. You can bridge it through SSH port tunnelling, but this - REPL over HTTP - is a viable alternative for remote, "live" servers.
Just for completeness, the server side:
drawbridge - the HTTP transport - https://github.com/cemerick/drawbridge
how to use it - https://devcenter.heroku.com/articles/debugging-clojure
example app - https://github.com/technomancy/chortles
I've just installed CCW and tried against https://github.com/technomancy/chortles: I did "lein run" after exporting the environment variables suggested there and it connects to http://flynn:reindeerflotilla#localhost:5000/repl like a charm. I tried to evaluate simple expressions and I had no problems at all while the server was up&running. I'm using Leiningen 2.4.3 to run it.
Chortle's sources https://github.com/technomancy/chortles/blob/master/src/chortles/web.clj seem to be quite simple, the main handler is wrapped in drawbridge middleware including session and parameters support too. Does that work for you? Is it feasible to use the same approach for your own application?
If I have a greenfield project, what is the best practice Perl based configuration module to use?
There will be a Catalyst app and some command line scripts. They should share the same configuration.
Some features I think I want ...
Hierarchical Configurations to cleanly maintain different development and live settings.
I'd like to define "global" configurations once (eg, results_per_page => 20), have those inherited but override-able by my dev/live configs.
Global:
results_per_page: 20
db_dsn: DBI:mysql;
db_name: my_app
Dev:
inherit_from: Global
db_user: dev
db_pass: dev
Dev_New_Feature_Branch:
inherit_from: Dev
db_name: my_app_new_feature
Live:
inherit_from: Global
db_user: live
db_pass: secure
When I deploy a project to a new server, or branch/fork/copy it somewhere new (eg, a new development instance), I want to (one time only) set which configuration set/file to use, and then all future updates are automatic.
I'd envisage this could be achieved with a symlink:
git clone example.com:/var/git/my_project . # or any equiv vcs
cd my_project/etc
ln -s live.config to_use.config
Then in the future
git pull # or any equiv vcs
I'd also like something that akin to FindBin, so that my configs can either use absolute paths, or relative to the current deployment. Given
/home/me/development/project/
bin
lib
etc/config
where /home/me/development/project/etc/config contains:
tmpl_dir: templates/
when my perl code looks up the tmpl_dir configuration it'll get:
/home/me/development/project/templates/
But on the live deployment:
/var/www/project/
bin
lib
etc/config
The same code would magically return
/var/www/project/templates/
Absolute values in the config should be honoured, so that:
apache_config: /etc/apache2/httpd.conf
would return "/etc/apache2/httpd.conf" in all cases.
Rather than a FindBin style approach, an alternative might be to allow configuration values to be defined in terms of other configuration values?
tmpl_dir: $base_dir/templates
I'd also like a pony ;)
Catalyst::Plugin::ConfigLoader supports multiple overriding config files. If your Catalyst app is called MyApp, then it has three levels of override: 1) MyApp.pm can have a __PACKAGE__->config(...) directive, 2) it next looks for MyApp.yml in the main directory of the app, 3) it looks for MyApp_local.yml. Each level may override settings in each other level.
In a Catalyst app I built, I put all of my immutable settings in MyApp.pm, my debug settings in MyApp.yml, and my production settings in MyApp_<servertype>.yml and then symlinked MyApp_local.yml to point at MyApp_<servertype>.yml on each deployed server (they were all a little different...).
That way, all of my config was in SVN and I just needed one ln -s step to manually config a server.
Perl Best Practices warns against exactly what you want. It states that config files should be simple and avoid the sort of baroque features you desire. It goes on to recommend three modules (none of which are Core Perl): Config::General, Config::Std, and Config::Tiny.
The general rational behind this is that the editing of config files tends to be done by non-programmers and the more complicated you make your config files, the more likely they will screw them up.
All of that said, you might take a look at YAML. It provides a full featured, human readable*, serialization format. I believe the currently recommend parser in Perl is YAML::XS. If you do go this route I would suggest writing a configuration tool for end users to use instead of having them edit the files directly.
ETA: Based on Chris Dolan's answer it sounds like YAML is the way to go for you since Catalyst is already using it (.yml is the de facto extension for YAML files).
* I have heard complaints that blind people may have difficulty with it
YAML is hateful for config - it's not non-programmer friendly partly because yaml in pod is by definition broken as they're both white-space dependent in different ways. This addresses the main problem with Config::General. I've written some quite complicated config files with C::G in the past and it really keeps out of your way in terms of syntax requirements etc. Other than that, Chris' advice seems on the money.