For specifying the preferenced order of encryption algorithms in GPG I use
gpgme_set_engine_info(GPGME_PROTOCOL_OpenPGP, NULL, CONFIG_DIR);
to set a custom config file. However how can I check if this operation was successful? home_dir is set to the given value, but this also happens if I pass a directory without a config file. I can't see any function or call in the documentation to evaluate if the config file was loaded OR what the current preference order is.
The function returns an error value if a problem occured. From the documentation:
This function returns the error code GPG_ERR_NO_ERROR if successful, or an eror code on failure.
You observed unexpected behavior with setting a home directory without a configuration file:
home_dir is set to the given value, but this also happens if I pass a directory without a config file.
This is expected behavior in GnuPG. An empty configuration file is not an error, but simply means no other configuration but the defaults is in place. Similar things happen if you pass --homedir to GnuPG with a reference to an empty folder: GnuPG will try to initialize this folder as a home directory, but print an information message:
$ LANG=C gpg --homedir /tmp
gpg: keyring `/tmp/secring.gpg' created
gpg: keyring `/tmp/pubring.gpg' created
gpg: Go ahead and type your message ...
If you want to verify the folder is already set up, I'd propose to verify some options you'd expect, or test for a configuration file (or whatever you expect to be available) on your own.
Related
I'm trying to insert Maxmind Data into a Clickhouse Dictionary but defining it source as a local file where I can running my Client from.
so to define my dictionary I use the query:
CREATE DICTIONARY usage_analytics.city_locations(
geoname_id UInt64 DEFAULT 0,
...
...
...
...
)
PRIMARY KEY geoname_id
SOURCE(File(path '/home/ubuntu/maxmind_csv/GeoLite2-City-Locations-en.csv' format 'CSVWithNames'))
SETTINGS(format_csv_allow_single_quotes = 0)
LAYOUT(HASHED())
LIFETIME(300);
yet I keep getting hit with the error of:
Failed to load dictionary 'usage_analytics.city_locations': std::exception. Code: 1001, type: std::__1::__fs::filesystem::filesystem_error, e.what() = filesystem error: in canonical: No such file or directory [\home/ubuntu/maxmind_csv/GeoLite2-City-Locations-en.csv] [/],
According to the documentation, I have to use its absolute path, which I did by using readlink, and still it cannot detect my file. I am running a clickhouse client from a remote machine and have the files on the remote machine. Am I suppose to have my files else where or what?
It looks like this file is not available, to fix it need to to set right ownership for file:
chown clickhouse:clickhouse /home/ubuntu/maxmind_csv/GeoLite2-City-Locations-en.csv
# chown -R clickhouse:clickhouse /home/ubuntu/maxmind_csv
.XML dictionary allows to read files from any folder.
SQL dictionary does not.
https://clickhouse.tech/docs/en/sql-reference/dictionaries/external-dictionaries/external-dicts-dict-sources/#dicts-external_dicts_dict_sources-local_file
When dictionary with source FILE is created via DDL command (CREATE DICTIONARY ...), the source file needs to be located in user_files directory, to prevent DB users accessing arbitrary file on ClickHouse node.
/etc/clickhouse-server/config.xml
<!-- Directory with user provided files that are accessible by 'file' table function. -->
<user_files_path>/var/lib/clickhouse/user_files/</user_files_path>
I have a new computer and I'm trying to set up my AWS CLI environment so that I can run a management console I've created.
This is the code I'm running:
def create_bucket(bucket_args)
AWS_S3 = Aws::S3::Client.new(signature_version: 'v4')
AWS_S3.create_bucket(bucket_args)
end
Which raises this error:
Aws::S3::Errors::SignatureDoesNotMatch - The request signature we calculated does not match the signature you provided. Check your key and signing method.:
This was working properly on my other computer, which I no longer have access to. I remember debugging this same error on the other computer, and I thought I had resolved it by adding signature_version = s3v4 to my ~/.aws/config file. But this fix is not working on my new computer, and I'm not sure why.
To give some more context: I am using aws-sdk (2.5.5) and these aws cli specs: aws-cli/1.11.2 Python/2.7.12 Linux/4.4.0-38-generic botocore/1.4.60
In this case the issue was that my aws credentials (in ~/.aws/credentials) - specifically my secret token - were invalid.
The original had a slash in it:
xx/xxxxxxxxxxxxxxxxxxxxxxxxxx
which I didn't notice at first, so when I double clicked the token to select the word, it didn't include the first three characters. I then pasted this into the terminal when running aws configure.
To fix this, I found the correct, original secret acceess token and set the correct value in ~/.aws/credentials.
I am following the tutorial at
https://cloud.google.com/appengine/docs/java/endpoints/calling-from-ios
and when I get to step 5 and Open a new Terminal window to invoke ServiceGenerator. I get the error message in my terminal saying..
Barrys-MacBook-Pro:~ barrymadej$ /Users/barrymadej/Library/Developer/Xcode/DerivedData/ServiceGenerator-avaeguyitgyhxpcnaejpgzvxezei/Build/Products/Debug/ServiceGenerator \
/Users/barrymadej/Documents/AndroidStudioProjects/StudentProgressTrackerDatabaseAndCloud/backend/build/discovery-docs/myApi-v2-rpc.discovery /
ERROR: An output directory is required.
Usage: ServiceGenerator [FLAGS] [ARGS]
Required Flags:
--outputDir PATH
The destination directory for writing the generated files.
Optional Flags:
--discoveryService URL
Instead of discovery's default URL, use the specified URL as the
location to send the JSON-RPC requests. This is useful for running
against a custom or prerelease server.
--gtlFrameworkName NAME
Will generate sources that include GTL's headers as if they are in a
framework with the given name. If you are using GTL via CocoaPods,
you'll likely want to pass "GoogleAPIClient" as the value for this.
--apiLogDir DIR
Write out a file into DIR for each JSON API description processed. These
can be useful for reporting bugs if generation fails with an error.
--httpLogDir PATH
Turn on the HTTP fetcher logging and set it to write to PATH. This can
be useful for diagnosing errors on discovery fetches.
--generatePreferred
Causes the list of services to be collected, and all preferred services
to be generated.
--httpHeader NAME:VALUE
Causes the given NAME/VALUE pair to be added as an HTTP header on *all*
HTTP requests made by the generator. Can be used repeatedly to provide
additional header pairs.
--formattedName SERVICE:VERSION=NAME
Causes the given SERVICE:VERSION pair to override its service name in
files, classes, etc. with NAME. If :VERSION is omitted the override is
for any version of the service. Can be used repeatedly to provide
several maps when generating a few things in a single run.
--addServiceNameDir yes|no Default: no
Causes the generator to add a directory with the service name in the
outputDir for the files. This is useful for generating multiple
services.
--generatedDir yes|no Default: no
Causes a directory in outputDir called "Generated" to be created and
used to contain the generated files.
--removeUnknownFiles yes|no Default: no
By default, the generator will report unknown files in the output
directory, as commonly happens when classes go away in a new API
version. This option causes the generator to also remove the unknown
files.
--rootURLOverrides yes|no Default: yes
Causes any API root URL for a Google sandbox server to be replaced with
the googleapis.com root instead.
--verbose
Generate more verbose output. Can be used more than once.
Arguments:
Multiple arguments can be given on the command line.
service:version
The description of the given [service]/[version] pair is fetched and the
files for it are generated. When using --generatePreferred version can
be '-' to skip generating the name service.
http[s]://url/to/rpc_description_json
A URL to download containing the description of a service to generate.
path/to/rpc_description.json
The path to a text file containing the description of a service to
generate.
ServiceGenerator path:
/Users/barrymadej/Library/Developer/Xcode/DerivedData/ServiceGenerator-avaeguyitgyhxpcnaejpgzvxezei/Build/Products/Debug/ServiceGenerator
ERROR: There was one or more errors; check the full output for details.
Barrys-MacBook-Pro:~ barrymadej$ --outputDir
-bash: --outputDir: command not found
Barrys-MacBook-Pro:~ barrymadej$ /Users/barrymadej/Documents/AndroidStudioProjects/StudentProgressTrackerDatabaseAndCloud/API
You should generate a REST discovery document and use the new Objective C client instead. The client library you're trying to use is deprecated anyway. It looks like it didn't work because you specified the flag without the rest of the command, though.
How do I create a new keystore file with wsadmin tool in websphere.
I tried this command
AdminTask.createKeyStore('-keyStoreName <someName>
-keyStoreType PKCS12
-keyStoreLocation <some file location.p12>
-keyStorePassword <pwd>
-keyStorePasswordVerify <pwd>'
)
but looks like it just loads the keystore in the given location. but i want to create a new keystore and store it in the given location.
What command should I use for that?
Thanks.
What do you mean it 'loads keystore'?
I've used the following command:
AdminTask.createKeyStore('[-keyStoreName testKS -keyStoreType PKCS12
-keyStoreLocation c:/testKeyFile.p12 -keyStorePassword testpwd
-keyStorePasswordVerify testpwd -keyStoreIsFileBased true
-keyStoreInitAtStartup true -keyStoreReadOnly false]')
and I see keystore correctly created in the file system, and also visible via admin console.
Remember to call AdminConfig.save() afterwards to save changes.
See details here KeyStoreCommands command group for the AdminTask object
i get this error while using Phpass 0.3 on my CI Controller
Message: is_readable() [function.is-readable]: open_basedir restriction in effect. File(/dev/urandom) is not within the allowed path(s): (/home/:/usr/lib/php:/usr/local/lib/php:/tmp)
Filename: phpass-0.3/PasswordHash.php
can someone tell me the problem is?
open_basedir is a directive defined in your php.ini file.
It is set to the lowest directory that you are allowed to access from a PHP script, usually your webroot.
Trying to access a file/directory further down the tree such as in /dev/ will then be dissallowed and you will get the message you have.
You will have to edit your php.ini and set open_basedir to your server root, which is generally a bad thing security-wise as if anyone managed to inject malicious code into your script they would have access to the entire system.
It would be safer to exececute a script (Perl, Python, etc) that lives in your web folder to read /dev/urandom if you really need to.
$output = `/scripts/get_urandom.pl`;
// Process output
Version 1.8 of phpass resolves this issue by suppressing the error:
Changes since revision 1.7: +2 -2 lines:
Prefixed is_readable() with "#" to suppress warning when open_basedir
restriction is in effect.