Hi i am new logstash and as well as mongodb. I am not really sure if this is the right place to ask question or not, but i really need help. I have posted the same question in logstash-users google group as well, but i havent received and any answer. Further i have gone through all the posts at the google group but none of the solutions seem to be working.
i need to use mongodb for output so i ran the following command:
./plugin install contrib
After that i ran this command
./logstash agent --config logstash-shipper.conf
my logstash-shipper.conf is
input {
file {
path => "/var/log/alternatives.log"
type => "syslog"
}
}
output {
mongodb {
codec => "plain"
collection => "logstash"
database => "mydb"
generateId => true
isodate => true
uri => "mongodb://localhost:27017/"
} }
i get the error
Using milestone 2 input plugin 'file'. This plugin should be stable, but if you see strange behavior, please let us know! For more information on plugin milestones, see http://logstash.net/docs/1.4.0/plugin-milestones {:level=>:warn}
+---------------------------------------------------------+
| An unexpected error occurred. This is probably a bug. |
| You can find help with this problem in a few places: |
| |
| * chat: #logstash IRC channel on freenode irc. |
| IRC via the web: http://goo.gl/TI4Ro |
| * email: logstash-users#googlegroups.com |
| * bug system: https://logstash.jira.com/ |
| |
+---------------------------------------------------------+
The error reported is:
Couldn't find any output plugin named 'mongodb'. Are you sure this is correct? Trying to load the mongodb output plugin resulted in this error: no such file to load -- logstash/outputs/mongodb
As far as I can tell, the 1.4.2 distribution is slightly broken. The version name of the release is "1.4.2-modified" but the contrib version is still "1.4.2".
My workaround was to find ./lib/logstash/version.rb and change
LOGSTASH_VERSION = "1.4.2-modified"
to
LOGSTASH_VERSION = "1.4.2"
This allowed
./plugin install contrib
to work (i.e. my mongodb connection works now), and so far nothing else has broken. Interestingly enough, there's a note right in the version.rb file that says
# Note to authors: this should not include dashes because 'gem' barfs if
# you include a dash in the version string.
Oops.
Related
So what I am trying is converting a GRIB1 file to GRIB2 containing mostly wind data.
Usually you can just change the edition to 2 and the eccodes lib does everything else.
Now the issue is that my GRIB1 file has only paramId=0 and shortName=unknown messages.
What the hell am I supposed to do? When I load it into a viewer (e.g. PredictWind Offshore) it displays just fine. Any ides on how I can convert this to GRIB2 without knowing the messages? Am I missing something?
What I already tried:
❯ grib_set -s edition=2 e1.grib e2.grib
ECCODES ERROR : concept: no match for paramId=0
ECCODES ERROR : Please check the Parameter Database 'https://apps.ecmwf.int/codes/grib/param-db/?id=0'
ECCODES ERROR : concept: input handle edition=2
ECCODES ERROR : grib_set_values[0] edition (type=long) failed: Concept no match
What my GRIB1 (e1.grib) looks like:
❯ grib_dump e1.grib | egrep 'paramId|shortName'
...
shortName = unknown;
paramId = 0;
...
❯ grib_dump dsv1.grib | egrep 'paramId' | wc -l
679 # all unknown and 0
Edit:
For future readers:
I ended up not using eccodes at all. My solution now involves using PyNIO which worked great for me. It is able to read GRIB1.
For further info contact me directly.
Was setting up Airflow (2.1.4) in a virtual environment followed by an install of a third-party plugin "pip install simple-dag-editor"
Plugin installed successfully, however upon checking the plugin list, there were duplicated entries.
(venv) root#test-server:/opt/airflow$ airflow plugins
name | source | flask_blueprints | appbuilder_views
==================+============================================================+=======================================================+=============================================================
simple_dag_editor | simple-dag-editor==0.1.1: | <flask.blueprints.Blueprint object at 0x7f69e5e427b8> | {'category': 'Admin', 'name': 'Simple DAG editor', 'view':
| EntryPoint(name='simple_dag_editor', value='simple_dag_edi | | <simple_dag_editor.app_builder_view.AppBuilderDagEditorView
| tor.simple_dag_editor:SimpleDagEditor', | | object at 0x7f69e5dd1470>}
| group='airflow.plugins') | |
simple_dag_editor | simple-dag-editor==0.1.1: | <flask.blueprints.Blueprint object at 0x7f69e5e427b8> | {'category': 'Admin', 'name': 'Simple DAG editor', 'view':
| EntryPoint(name='simple_dag_editor', value='simple_dag_edi | | <simple_dag_editor.app_builder_view.AppBuilderDagEditorView
| tor.simple_dag_editor:SimpleDagEditor', | | object at 0x7f69e5dd1470>}
| group='airflow.plugins') | |
Airflow portal also resulted in 2 entries in the "Admin" section
Any idea what is happening? I tested the setup again both on a docker container and standalone on the server. Both instances did not result in the duplicated entries therefore I am suspecting it is related to running Airflow in a Python virtual environment. The server is running on CentOS 7.
I believe you might have plugin installed twice in two different places:
In "plugins" folder as simply a python package
Installed as python package
Aiflow Allows for both types of installations, and I think if you have both - it will install both.
If you change the airflow log level to verbose, you should be able to see two entries:
"Loading plugins from entrypoints"
"Loading plugins from directory: <DIRECTORY>"
They should be followed by attempts to import the plugins.
The solution would be to remove the plugings from the "plugins" directory.
It's also possible that you have two packages that have the same entrypoint - for example if you installed it with different package name before, it could also be discovered twice. Airflow checks all pacakges available and if they have appropriate entrypoint declared, it will load it as plugin. But if you enable DEBUG logging level, you should see details. You can easily set airflow logging level by config option (or environment variable):
https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#logging-level
Error I get:
error[E0433]: failed to resolve: could not find `openssl` in `backend`
--> ...\src\...\swagger-0.12.1\src\connector.rs:41:34
|
41 | native_tls::backend::openssl::TlsConnectorBuilderExt::from_openssl(ssl);
| ^^^^^^^ could not find `openssl` in `backend`
error[E0433]: failed to resolve: could not find `openssl` in `backend`
--> ...\swagger-0.12.1\src\connector.rs:85:34
|
85 | native_tls::backend::openssl::TlsConnectorBuilderExt::from_openssl(ssl);
| ^^^^^^^ could not find `openssl` in `backend`
Compiling hyper v0.2.1
error: expected identifier, found `"rustc-serialize"`
--> ...\hyper-0.2.1\src\lib.rs:129:14
|
129 | extern crate "rustc-serialize" as serialize;
| ^^^^^^^^^^^^^^^^^ expected identifier
Generated a server stub user swagger. Ran into issues where cargo couldn't find openssl, giving an error like 'custom build something openssl-sys 0.9.24'. This was a known issue and I overcame it by downloading vcpkg, and using vcpkg to download openssl. Then using environment variables to point to the download folder so cargo could use openssl. But now the error seems to be that openssl doesn't exist in backend?
It also seems to specific to windows, any ideas?
Tried changing the version of native-tls to the most up to date version but it doesn't seem to have an affect at all. It looks like swagger's dependencies need updating but I literally just generated this stub...
You've landed on a flaw from the Rust documentation tools; it picks up what is in a package, but doesn't show the limits.
The backend module definition is defined as:
#[cfg(any(target_os = "macos", target_os = "ios"))]
pub mod security_framework;
#[cfg(target_os = "windows")]
pub mod schannel;
#[cfg(not(any(target_os = "macos", target_os = "windows", target_os = "ios")))]
pub mod openssl;
In other words, the situation is the following:
If you are on linux (i.e. not macOS, not windows, not iOS), then openssl is available
If you are on windows, then schannel is available
If you are on MacOS or iOS security_framework is available
You should, however, not be trying to target a specific backend, as this defeats the purpose of the library. Instead of importing native_tls::backend::openssl::TlsConnectorBuilderExt, import native_tls::TlsConnectorBuilder and let it decide what backend you need.
This may be easier said than done, however, since by the looks of your error this is caused by a third-party library, which indicates that it was only tested on Linux.
the server that a magento install was on crashed for (currently reason unknown) and now the backend is inaccessible. I either get no error or I get access denied. I am able to preform the password reset.
I have tried:
clearing the browser cookies and cache
clearing the session, tmp and cache folders in magento
using the magento database repair tool - no errors were found
creating a new user manually in the admin_users table (this gets access denied)
rebooting the server again (last resort but still no)
The main admin user gets a redirect loop.
Any ideas are welcome, I am now stumped.
EDIT:I am really after any way to recover a magento admin login? or failing this any way to export the data (without exporting the bugged section)
I have employed a hack in one of the core magento files detailed here: http://blog.chapagain.com.np/magento-admin-login-problem/
I have had to comment out lines in "app/code/core/Mage/Core/Model/Session/Abstract/Varien.php":
(please note this is for 1.6 - check link posted for advice on 1.4)
$cookieParams = array(
'lifetime' => $cookie->getLifetime(),
'path' => $cookie->getPath()//,
//'domain' => $cookie->getConfigDomain(),
//'secure' => $cookie->isSecure(),
//'httponly' => $cookie->getHttponly()
);
also line 104 comment out :
//call_user_func_array('session_set_cookie_params', $cookieParams);
It seems to be when the server went down something happened to the session, as the new install also failed.
You can get your data by performing a database backup via cPanel or mysqldump via SSH access. Your hosting provider should be able to help you. Additionally, you can unzip the admin files from your Magento installed version. Download it to your computer and unzip the installation... then re-zip the folder for app/design/adminhtml ... upload and unpack this on your website in the proper place, and this will reinstall the PHP pages.
Double check the file app/etc/local.xml this usually has the database login stored in it.
Inside the mysql database for your magento installation, there is the table core_config_data and in it, some path values might interfere with using admin if intentionally set incorrectly:
mysql> select config_id, path, left(value,30) from core_config_data WHERE path LIKE '%admin%';
+-----------+-------------------------------------------+--------------------------------+
| config_id | path | left(value,30) |
+-----------+-------------------------------------------+--------------------------------+
| 50 | dev/translate_inline/active_admin | 0 |
| 220 | web/secure/use_in_adminhtml | 0 |
| 687 | admin/startup/page | catalog/products |
| 690 | admin/security/use_form_key | 0 |
| 691 | admin/security/use_case_sensitive_login | 1 |
| 692 | admin/security/session_cookie_lifetime | 36000 |
| 745 | admin/url/use_custom | 0 |
| 746 | admin/url/custom | |
+-----------+-------------------------------------------+--------------------------------+
I am new to Play and GWT and following the documentation given here. But I see the following errors:
bash-3.2$ play deps test-gwt
!! Error whileloading /opt/play-1.2.1/modules/gwt-1.0/commands.py: name 'play_command' is not defined
~
~ Resolving dependencies using /Users/Harit/Documents/personal/projects/test-gwt/conf/dependencies.yml,
~
~ play->gwt 1.0 (from playLocalModules)
~
~ Installing resolved dependencies,
~
~ modules/gwt-1.0 -> /opt/play-1.2.1/modules/gwt-1.0
~
~ Done!
I see that there is a corresponding bug here, and status is fix_commited, but I don't know what shall I do?
Isn't it just because play-gwt module is not compatible with play 1.2 ?
Apparently this module is quite old and not very active and command syntax has changed in version 1.1.x or something like that.
Before, you wrote commands.py like that:
...
if play_command.startswith('gwt:'):
...
and now, it is like that:
...
MODULE = "secure"
COMMANDS = ["secure:", "secure:ov", "secure:override"]
HELP = {
"secure:": "Show help for the secure module",
"secure:override": "Override the CSS, login or layout"
}
def execute(**kargs):
command = kargs.get("command")
app = kargs.get("app")
args = kargs.get("args")
env = kargs.get("env")
if command == 'secure:':
...
In my opinion, the modification is really light so you can either ask the module owner if he would accept to do it or even do it by yourself ;)
There is also a GWT2 module which seems much more active: http://www.playframework.org/modules/gwt2 (apparently no new version since last october but the github project shows very recent commits with play1.2 support)