I am trying to update the content with Integer 0. File resource below,
file { ['/sys/block/sda/queue/read_ahead_kb']:
content => 0,
}
Error : Failed to apply catalog: Parameter content failed on File[/sys/block/sda/queue/read_ahead_kb]: Munging failed for value 0 in class content: no implicit conversion of Fixnum into String at /test/puppet/environments/mytest/modules/test/manifests/testdb/settings.pp:4
All i i need is to just have 0 in there ? I tried to have zero between quotes as string ,but it do not update the file and threw below errors.
Error 1:
Error: Could not back up /sys/block/sda/queue/read_ahead_kb: Got passed new contents for sum {md5}102e7bda3ff4572145809d25da2bbe11
I deleted /var/lib/puppet/clientbucket and re-ran the puppet.
Error 2:
Error:/Stage[main]/testdb::Settings/File[/sys/block/sda/queue/read_ahead_kb]/content: change from {md5}102e7bda3ff4572145809d25da2bbe11 to {md5}cfcd208495d565ef66e7dff9f98764da failed: Operation not permitted # dir_s_mkdir - /sys/block/sda/queue/read_ahead_kb20200315-47213-5b01k6.lock
Can anybody help with this?
Thanks
I strongly suspect you can't use a file resource to manage the special files in /sys. /sys may look like a directory of files, but it really isn't.
There are Puppet modules available to manage /sys settings. For example, https://forge.puppet.com/danfoster/sysfs, which would allow you to use something like
include sysfs
sysfs::setting { 'class/block/sda/queue/read_ahead_kb':
value => 0
}
Related
I am unable to write to the file which I create. In windows it's working fine. In centos it says file already exists and does not write anything.
File tempFile= new File("temp/tempfile.parquet");
tempFile.createNewFile();
parquetDataSet.write().parquet(tempFile.getAbsolutePath());
Following is the error: file already exists
2020-02-29 07:01:18.007 ERROR 1 --- [nio-8090-exec-1] c.gehc.odp.util.JsonToParquetConverter : Stack Trace: {}org.apache.spark.sql.AnalysisException: path file:/temp/myfile.parquet already exists.;
2020-02-29 07:01:18.007 ERROR 1 --- [nio-8090-exec-1] c.gehc.odp.util.JsonToParquetConverter : sparkcontext close
The default savemode in spark is ErrorIfExists. This means that if the file with the same filename you intend to write already exists, it will give an exception similar to the one you got above. This is happening in your case because you are creating the file yourself rather than leaving that task to spark. There are 2 ways in which you can resolve the situation:
1) You can either mention savemode as "overwrite" or "append" in the write command:
parquetDataSet.write.mode("overwrite").parquet(tempFile.getAbsolutePath());
2) Or, you can simply remove the create new file command and straightaway pass the destination path in your spark write command as follows:
parquetDataSet.write.parquet("temp/tempfile.parquet");
I've been searching for awhile and found posts on the Terraform errors "Unknown root level key" but nothing seems to quite match my scenario. So my first question is what does this error message mean? It sounded to me like maybe a variable was undefined in the root module but that does not appear to be the case.
command and results:
terraform init
"Error: Unknown root level key"
code:
#variables.tf file in the root module
variable "rds_sg"{}
#adding the line below leads to the error above
rds_sg = "${module.network.hcs-rds-sg-id}"
I confirmed that this output does exist in the network module. I think maybe I am missing something on how to properly refer to a module output from the root module but after a few hours of investigation I am not sure what it is.
Update 2
I think #faré is right, it's an output translation problem.
So I declared the evironment variable ASDF_OUTPUT_TRANSLATIONS and set it to E:/. Now (asdf:require-system "my-system") yields a different error: Uneven number of components in source to destination mapping: "E:/" which led me to this SO-topic.
Unfortunately, his solution doesn't work for me. So I tried the other answer and set ASDF_OUTPUT_TRANSLATIONS to (:output-translations (t "E:/")). Now I get yet another error:
Invalid source registry (:OUTPUT-TRANSLATIONS (T "E:/")).
One and only one of
:INHERIT-CONFIGURATION or
:IGNORE-INHERITED-CONFIGURATION
is required.
(will be skipped)
Original Posting
I have a simple system definition but can't get ASDF to load it.
(asdf-version 3.1.5, sbcl 1.3.12 (upgraded to 1.3.18 AMD64), slime 2.19, Windows 10)
What I have tried so far
Following the ASDF manual: "4.1 Configuring ASDF to find your systems"
There it says:
For Windows users, and starting with ASDF 3.1.5, start from your
%LOCALAPPDATA%, which is usually ~/AppData/Local/ (but you can ask in
a CMD.EXE terminal echo %LOCALAPPDATA% to make sure) and underneath
create a subpath config/common-lisp/source-registry.conf.d/
That's exactly what I did:
Echoing %LOCALAPPDATA% which evaluates to C:\Users\my-username\AppData\Local
Underneath I created the subfolders config\common-lisp\source-registry.conf.d\ (In total: C:\Users\my-username\AppData\Local\config\common-lisp\source-registry.conf.d\
The manual continues:
there create a file with any name of your choice but with the type conf, for instance 50-luser-lisp.conf; in this file, add the following line to tell ASDF to recursively scan all the subdirectories under /home/luser/lisp/ for .asd files: (:tree "/home/luser/lisp/")
That’s enough. You may replace /home/luser/lisp/ by wherever you want to install your source code.
In the source-registry.conf.d folder I created the file my.conf and put in it (:tree "C:/Users/my-username/my-systems/"). This folder contains a my-system.asd.
And here comes the weird part:
If I now type (asdf:require-system "my-system") in the REPL I get the following error:
Can't create directory C:\Users\my-username\AppData\Local\common-lisp\sbcl-1.3.12-win-x86\C\Users\my-username\my-systems\C:\
So the problem is not that ASDF doesn't find the file, it does -- but (whatever the reason) it tries to create a really weird subfolder hierarchy which ultimately fails because at the end it tries to create the folder C: but Windows doesn't allow foldernames containing a colon.
Another approach: (push path asdf:*central-registry*)
If I try
> (push #P"C:/Users/my-username/my-systems/" asdf:*central-registry*)
(#P"C:/Users/my-username/my-systems/"
#P"C:/Users/my-username/AppData/Roaming/quicklisp/quicklisp/")
> (asdf:require-system "my-system")
I get the exact same error.
I don't know what to do.
Update
Because of the nature of the weird path ASDF was trying to create I thought maybe I could bypass the problem by specifying a relative path instead of an absolute one.
So I tried
(:tree "\\Users\\my-username\\my-systems")
in my conf file. Still the same error.
Ahem. It looks like an output-translations problem.
I don't have a Windows machine right now, but this all used to work last time I tried.
Can you setup some ad hoc output-translations for now that will make it work?
I'd like to be able to create files based on the contents of an array. Here is what I have tried:
class make_files (
$servers = ['server-1','server-2','server-3'],
) {
file { $servers :
path => '/tmp',
content => $servers,
}
}
... but when I execute this like so ...
# puppet apply --modulepath=/root/modules -e 'include make_files'
... I get this output:
Notice: Compiled catalog for host-001 in environment production in 0.13 seconds
Error: Cannot alias File[server-2] to ["/tmp"] at /root/modules/make_files/manifests/init.pp:9; resource ["File", "/tmp"] already declared at /root/modules/make_files/manifests/init.pp:9
I was hoping to have three files ...
# ls /tmp/server-?
/tmp/server-1 /tmp/server-2 /tmp/server-3
# cat /tmp/server-?
server-1
server-2
server-3
It would really be cool if someone could tell me how to get the files to be named: server-1.cfg, server-2.cfg and server-3.cfg.
Any help is appreciated thanks!
First of all you already defined resource File['/tmp'], in init.pp file.
This is the main cause of the problem you got:
Error: Cannot alias File[server-2] to ["/tmp"] at /root/modules/make_files/manifests/init.pp:9; resource ["File", "/tmp"] already declared at /root/modules/make_files/manifests/init.pp:9
Please check the meaning of the path attribute. Maybe this will clarify the problem.
Create
$files_to_create = ['/path/server-1','/path/server-2','/path/server-3']
and then use it:
file { $files_to_create :
content => $servers,
}
Please also be sure that /path directory already exist in the filesystem. So far puppet is not able to create intermediate directories.
I'm trying to send a file to the browser to download, and not having a luck using $this->response->send_file($file_path); in the controller.
I get the following error:
ErrorException [ Warning ]: finfo::file() [<a href='finfo.file'>finfo.file</a>]: Empty filename or path
$file_path can be either absolute or relative path, but I still get the same error. After looking at the Kohana code for this implementation I just can't figure out how this should work.
The following code will shows how a base filename (eg, filename.ext) is passed into File::mime() - which is wrong
https://github.com/kohana/core/blob/3.2/develop/classes/kohana/response.php#L434-453
// Get the complete file path
$filename = realpath($filename);
if (empty($download))
{
// Use the file name as the download file name
$download = pathinfo($filename, PATHINFO_BASENAME);
}
// Get the file size
$size = filesize($filename);
if ( ! isset($mime))
{
// Get the mime type
// HERE'S THE ISSUE!!!
$mime = File::mime($download);
}
File::mime expects the filepath to be absolute or relative path on the filesystem, but $download will only ever be a base filename (eg filename.ext);
The only solution that works for me right now is to change the code in the send_file() method 'classes/kohana/response.php'
from File::mime($download);
to $mime = File::mime($filename);.
Kohana 3.3 has changed this implementation to:
$mime = File::mime_by_ext(pathinfo($download, PATHINFO_EXTENSION));
Essentially send_file does not work in 3.2 without this fix. Is this a bug, or what am I missing here?
I was using and linking to the 3.2 develop branch. This issue does not exist in the 3.2 master branch.
For those interested, follow discussion on this pull request to view the eventual fix: https://github.com/kohana/core/pull/183