I am trying to create some Vagrant VM's, but whenever I use vagrant box add, it says my box doesn't have the metadata.json file. This is also sometimes caused when the metadata.json file exists but does not have the provider line required by Vagrant. However, all the boxes I have tried have had this file with the required text, in correct JSON format. Usually I have the file say:
{
"provider": "virtualbox"
}
I don't believe white space matters, you could probably have hundreds of blank lines & tabs & spaces. The fact that it doesn't throw a different error (usually Could not resolve host) means it is finding the VM's.
The funny thing is, my system has the precise32 sample VM, and Vagrant didn't complain when I vagrant uped that. I even copied the metadata.json file from there to one of my VM's and tarred it again, but it still didn't work.
I'm not sure if it's related, but when I tried adding the --provider flag (as in vagrant add box /box/path --provider), it threw the error,
c:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.3.5/lib/vagrant/plugin/v2/comm
and.rb:51:in `parse_options': missing argument: --provider (OptionParser::Missin
gArgument)
from c:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.3.5/plugins/comma
nds/box/command/add.rb:29:in `execute'
from c:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.3.5/plugins/comma
nds/box/command/root.rb:47:in `execute'
from c:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.3.5/lib/vagrant/c
li.rb:38:in `execute'
from c:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.3.5/lib/vagrant/e
nvironment.rb:478:in `cli'
from c:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.3.5/bin/vagrant:9
6:in `<top (required)>'
from c:/HashiCorp/Vagrant/bin/../embedded/gems/bin/vagrant:23:in `load'
from c:/HashiCorp/Vagrant/bin/../embedded/gems/bin/vagrant:23:in `<main>
'
Not sure, if you are still looking for an answer. Just in case, if some one else is looking for
metadata.json should be at the root of the structure when you are
creating the tar
Try this tar -czf server-image.box ./*
instead of tar -czf server-image.box server-image-folder
Related
I'm working on a Perl6 project, but having difficulty connecting to MySQL. Even when using the DBIish (or perl6.org tutorial) example code, the connection fails. Any suggestions or advice is appreciated! User credentials have been confirmed accurate too.
I'm running this on Windows 10 with MySQL Server 8.0 and standard Perl6 with Rakudo Star. I have tried modifying the connection string in numerous ways like :$password :password<> :password() etc. but can't get a connection established. Also should note that I have the ODBC, C, C++, and.Net connectors installed.
#!/usr/bin/perl6
use v6.c;
use lib 'lib';
use DBIish;
use Register::User;
# Windows support
%*ENV<DBIISH_MYSQL_LIB> = "C:/Program Files/MySQL/MySQL Server 8.0/liblibmysql.dll"
if $*DISTRO.is-win;
my $dbh = DBIish.connect('mysql', :host<localhost>, :port(3306), :database<dbNameHere>, :user<usernameHere>, :password<pwdIsHere>) or die "couldn't connect to database";
my $sth = $dbh.prepare(q:to/STATEMENT/);
SELECT *
FROM users
STATEMENT
$sth.execute();
my #rows = $sth.allrows();
for #rows { .print }
say #rows.elems;
$sth.finish;
$dbh.dispose;
This should be connecting to the DB. Then the app runs a query, followed by printing out each resulting row. What actually happens is the application hits the 'die' message every time.
This is more of a work around, but being unable to use use a DB is crippling. So even when trying to use the NativeLibs I couldn't get a connection via DBIish. Instead I have opted to using DB::MySQL which is proving to be quite helpful. With a few lines of code this module has your DB needs covered:
use DB::MySQL;
my $mysql = DB::MySQL.new(:database<databaseName>, :user<userName>, :password<passwordHere>);
my #users = $mysql.query('select * from users').arrays;
for #users { say "user #$_[0]: $_[1] $_[2]"; }
#Results would be:
#user #1: FirstName LastName
#user #2: FirstName LastName
#etc...
This will print out a line for each user formatted as shown above. It's not as familiar as DBIish, but this module gets the job done as needed. There's plenty more you can do with it to, so I highly recommend reading the docs.
According to this github DBIish issue 127
The environmental variable DBIISH_MYSQL_LIB was removed. I don't know if anyone brought it back.
However if you add the library's path, and the file is named mysql.dll, it will work. Not a good result for the scientific method.
So more testing is needed - and perhaps
C:\Program Files\MySQL\MySQL Server 8.0\lib>mklink mysql.dll .\libmysql.dll
Oviously you can create your own lib directory and add that to your path and then add this symlink to that directory.
Hope this helps. I've spent hours..
EDIT: Still spending time - accounting later.
Something very transitory is going on. I reset the machine (perhaps always do this from now on), and still got the missing mysql.dll errors. Tried going into the MySQL lib directory to execute raku from there.. worked. changed directories.. didn't work.
Launched administrator cmd - from home directory, tried the raku command. Worked. Ok - not good, but perhaps consistent. Launched non admin cmd, tried it from the MySQL lib directory, worked. And just for giggles, tried it outside of that directory.. worked.
Now I can't get it not to work. Will explore NativeLibs::Searcher as Valle Lukas suggested!
Maybe the example in the dbiish repository is not valid anymore.
The DBIISH_MYSQL_LIB Env seems to be replaced by NativeLibs::Searcher with commit 9bc4191
Looking at NativeLibs::Searcher may help to find the root cause of the problem.
(I have Centos 7 with samba-client.x86_64 4.6.2-8.el7 against windows server 2008 that is in a AD Domain controlled by separate windows server 2008 AD domain controller)
Started with this:
smbclient -W my.domain -U myuser //svr.my.domain/fred mypassword -c list
... which worked great, then decided to move domain,user and password into a file and use -A as described in the smbclient manpage. File windows-credentials, content:
username=myuser
domain=my.domain
password=mypassword
... with command line:
smbclient -A windows-credentials //svr.my.domain/fred -c list
.... did not work, gave error:
SPNEGO(gse_krb5) NEG_TOKEN_INIT failed: NT_STATUS_NO_MEMORY
session setup failed: NT_STATUS_NO_MEMORY
... an hour on the internet suggested lots of people had this trouble and just about each had a different ticked answer, and none of them worked for me. Tried various combinations of their answers - in particular, https://askubuntu.com/questions/1008992/ubuntu-17-10-to-access-windows-files-shares-within-workplace-it, and ended up with...
Created a separate my.smb.conf with just:
[global]
# seems to get rid of
# SPNEGO(gse_krb5) NEG_TOKEN_INIT failed: NT_STATUS_NO_MEMORY
client use spnego = no
# seems to get rid of
# session setup failed: NT_STATUS_NO_MEMORY
client ntlmv2 auth = no
... and used:
smbclient -s my.smb.conf -A windows-credentials //svr.my.domain/fred -c list
... and it looks like it works, but I'm not really sure as there seems to be credentials caching and a complete lack of information on how this stuff works or is supposed to work.
Can anyone actually explain any of this? Even if not, perhaps yet another answer to this problem will help someone somewhere.
This appears to be specific to Windows 2008. Attaching to Windows Server 2016 works without the modified smb.conf file. I have been unable to locate any real details.
In case of problems with smbclient
you can mount smb folder and use it like local folder
mount -t cifs //<ip>/<share folder>$ /mnt -o user=<user>,pass=<password>,domain=<workdomain>
I managed to set up artifactory using our existing tomcat. I have set to ARTIFACTORY_HOME=/opt/artifactory, that part works well. There is, however, also the jfrog access.war file, which needs to be running as well. I didn't figure out which variable to use to specify its home, therefore it defaults to ~/.jfrog_access, which is not at all what I like.
I moved the content over to my $ARTIFACTORY_HOME/access and symlinked it, but that's not the way to go for sure. Any help appreciated.
In case someone is stumbling over this thread and struggles with the same problem:
Solution for me was to also extract the Context files (access.xml and artifactory.xml which are available in the zip file under <zip extract>/misc/tomcat) to the Tomcat configuration folder, e.g. $CATALINA_HOME/conf/Catalina/localhost/. After that the $ARTIFACTORY_HOME env will be recognized on Access startup.
A previous answer finally put me on the right track for solving this problem on Amazon Linux.
In addition to copying access.xml and artifactory.xml to ${catalina.home}/host/MY_HOSTNAME, I found that some other changes were needed.
I modified the docBase attributes in the XML context files because my server has multiple hostnames:
/usr/share/tomcat8/conf/Catalina/repo.mydomain.org/access.xml
<Context path="/access" docBase="${catalina.home}/host/repo.mydomain.org/access.war">
<Parameter name="jfrog.access.bundled" value="true" override="true"/>
<!-- enable annotations scanning of access jar files -->
<JarScanner scanClassPath="false">
<JarScanFilter defaultPluggabilityScan="false" pluggabilityScan="access*" defaultTldScan="false"/>
</JarScanner>
</Context>
/usr/share/tomcat8/conf/Catalina/repo.mydomain.org/artifactory.xml
<Context crossContext="true" path="/artifactory" docBase="${catalina.home}/host/repo.mydomain.org/artifactory.war">
</Context>
Important Note: In order to prevent the above two XML files from being deleted by Tomcat Manager during upgrades via Undeploy/Deploy WAR, make sure they are owned by root and not writable by the tomcat user:
chown root.root access.xml artifactory.xml
chmod 644 access.xml artifactory.xml
If you forget to do the above, you will likely end up missing these files, which will break the communication between the access and artifactory web applications, resulting in login failures ("Username or Password Are Incorrect"). In this case, these errors result from the lack of communication between the web applications, not a problem with the credentials themselves.
/usr/share/tomcat8/conf/Catalina/repo.mydomain.org/manager.xml
This gives me the ability to upload new versions of access.war and artifactory.war via https://repo.mydomain.org:8443/manager/html:
<Context docBase="${catalina.home}/webapps/manager" privileged="true" antiResourceLocking="false">
</Context>
Additionally, I created the following folder to serve as the artifactory.home:
sudo mkdir /usr/share/artifactory
sudo chown tomcat.tomcat /usr/share/artifactory
tomcat8.conf
Add (or modify) the following line:
JAVA_OPTS="-Dartifactory.home=/usr/share/artifactory -Djfrog.access.home=/usr/share/artifactory/access -Dartifactory.access.client.serverUrl.override=http://localhost:8080/access"
Note: The Access Client URL specified above must use localhost in order to avoid the Server HTTP parameter from being overwritten by Apache and its modules. For instance, if I use:
https://repo.mydomain.org/access/api/v1/system/ping
The Server HTTP header value in the response is:
Server: Apache/2.4.33 (Amazon) OpenSSL/1.0.2k-fips mod_jk/1.2.43
And the Access Client produces the following exception:
[ERROR] (o.j.a.c.AccessClientImpl:154) - Access client/server version mismatch. Client version: 4.1.5, Server version: 2.4.33 (Amazon) OpenSSL
Which means the Access Client is depending on the first string matching #.#.# in the server header. This seems like a really fragile part of the Access Client. They should have used X-JFrog-Access-Server or something instead of trying to control a value that is set by the web server. So, to reiterate, use http://localhost:8080/access to connect directly to the tomcat server.
Artifactory 6.2.0 depends on Apache Derby (the specific version can be found in jfrog-artifactory-oss-6.2.0.zip\artifactory-oss-6.2.0\tomcat\lib). This should be added as a shared library to Tomcat:
mkdir /usr/share/tomcat8/shared
cd /usr/share/tomcat8/shared
wget http://central.maven.org/maven2/org/apache/derby/derby/10.11.1.1/derby-10.11.1.1.jar
Add or modify the following line in catalina.properties:
shared.loader=${catalina.home}/shared/*.jar
Since we want https://repo.mydomain.org to go to the Artifactory webapp:
mkdir /usr/share/tomcat8/host/repo.mydomain.org/ROOT
echo '<html><head><meta http-equiv="refresh" content="0;URL=/artifactory"></meta></head><body></body></html>' > /usr/share/tomcat8/host/repo.mydomain.org/ROOT/index.html
And make sure the services automatically start on reboot:
sudo chkconfig httpd on
sudo chkconfig tomcat8 on
Artifactory will then be available at the url:
https://repo.mydomain.org/artifactory/webapp/
I am designing an application in Python and trying to write to a CSV file, but I am getting this error:
DatabaseError: 1 (HY000): Can't create/write to file '2015-04-06 20:48:33.418000'.csv (Errcode: 13 - Permission denied)
The Code:
def generate_report(self):
conn=mysql.connector.connect(user='root',password='',host='localhost',database='mydatabase')
exe2 = conn.cursor()
exe2.execute("""SELECT tbl_site.Site_name, State_Code, Country_Code,Street_Address, instrum_start_date, instrum_end_date, Comment INTO OUTFILE %s FIELDS TERMINATED BY '|' OPTIONALLY ENCLOSED BY '"' ESCAPED BY '\\\\' LINES TERMINATED BY '\\n'FROM tbl_site JOIN tbl_site_monit_invent ON site_id = tbl_Site_site_id """, (str(datetime.datetime.now()),))
I can run this code without any errors on a Mac, but I need it to work on Windows.
How can I resolve this error?
Simple really. A colon character is not a valid character in a filename on Windows. It's not allowed.
Reference: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx
The colon character is in the list of "reserved characters", along with several others. (NOTE: One use of the colon character is as a separator for an Alternate Data Stream on NTFS. Ref: http://blogs.technet.com/b/askcore/archive/2013/03/24/alternate-data-streams-in-ntfs.aspx
Followup
The question has been significantly edited since my previous answer was provided. Some notes:
I'm not very familiar with running MySQL on Windows OS. Most of my work with MySQL server is on Linux.
The SELECT ... INTO OUTFILE statement will cause the MySQL server to attempt to write a file on the server host.
The MySQL user (the user logged in to MySQL) must have the FILE privilege in order to use the SELECT ... INTO OUTFILE statement.
Also, the OS account that is running MySQL server must have OS permissions to write a file to the specified directory, and the file to be written must not already exist. Also, the filename must conform to the naming rules for filenames on OS filesystem.
Ref: https://dev.mysql.com/doc/refman/5.5/en/select-into.html
For debugging this type of issue, I strongly recommend you echo out the actual SQL text that is going to be sent to the MySQL server. And then take that SQL text and run it from a different client, like the mysql command line client.
For debugging a privileges issues, you can use a much simpler statement. Test writing a file to a directory that is known to exist, that is known the mysql server has permissions to write files to, and with a filename that does not exist and that conforms to the rules for the OS and filesystem.
For example, on a normal Linux box, we could test with something like this:
mysql> SELECT 'bar' AS foo INTO OUTFILE '/tmp/mysql_foo.csv'
Before we run that, we can easily verify that the /tmp directory exists, that it is writable by the OS account that is running the mysql server, and that the filename conforms to the rules for the filesystem, and that the filename doesn't exist, e.g.
$ su - mysql
$ ls -l /tmp/mysql_foo.csv
$ echo "foo" >/tmp/mysql_foo.csv
$ cat /tmp/mysql_foo.csv
$ rm /tmp/mysql_foo.csv
$ ls -l /tmp/mysql_foo.csv
Once we get over that hurdle, we can move on to testing writing a file to a different directory, a file with a more more complex filename. Once we get that plumbing working, we can work on getting actual data, into a usable csv format.
The original question seems to indicate that the MySQL server is running on Windows OS, and it seems to indicate that the filename attempting to be written contains semicolon characters. Windows does not allow semicolon as part a filename.
It was simply permission error.
I am getting the following error when (re)starting my Yesod app on openshift:
server: InvalidYaml (Just (YamlException "Yaml file not found: xxx.xxx.xxx.xxx"))
Where xxx.xxx.xxx.xxx is an IP address. I did find a link to a Heroku+Yesod issue saying something about "removing an argument" but it didn't say from where, and of course the scripts/settings are going to be different in the case of OpenShift. Any ideas what this error is and how to get past it?
I'm assuming based on the question that you're using the standard scaffolding. If you look in the code, you'll find that uses loadAppSettingsArgs, which is described as:
Same as loadAppSettings, but get the list of runtime config files from the command line arguments.
If you don't want to pay attention to command line arguments, just replace the call to loadAppSettingsArgs with loadAppSettings [].