I download Redis-x64-3.2.100.zip from Here, when i extract it i see two files redis.windows.conf and redis.windows-service.conf, i compare these two files they really similar, except in logfile and syslog-enabled and syslog-ident redis, and when i want install the Redis i should change configuration on redis.windows-service.conf, not redis.windows.conf.
so what is the diff between redis.windows.conf and redis.windows-service.conf?
redis.windows-service.conf is meant to be run as a service/daemon. This means that it is meant to be run in the background and managed by the OS (started on reboot, restarted if it crashes, etc).
And redis.windows.conf is meant to be run from the command line or a script and managed in user space.
The only substantive difference between the two, as you have pointed out, is that the service hooks into the windows syslog, which is a really good idea for services, but usually unnecessary for normal processes.
Whichever one you choose, you'll probably need to tweak it for your own purposes. They are just around as samples.
Related
I build my runner and it works fine. However, when it initializes, it first clones the project to /home/user/builds/xxxx... I never, ever, ever want GitLab to use /home. Never. Not for anything. I was told that it is impossible to change it to a different location. I find it hard to believe.
See in the image below, it gives me a warning about templates not found in some made up directory, then clones the entire project under the user's home directory. I don't give it that command - so it must be a default. Is there a way to choose ANY other mount point? The project is several hundred gigabytes and the /home directory is 50k. I cannot control that. So to a different mount point it must go.
I can provide the yml etc, but this is about core behavior of the runner itself - not anything I created. I'm hoping it is a simple variable I can send when initializing the runner.
Thank you in advance.
I have a few clojure applications that load the sensitive info off of .properties file in /etc/ and this has worked well so far.
Recently, I have had to deal with a few windows machines added into our server collection and I need to run the clojure applications on there as well. Windows doesn't obviously have or understand /etc/ path and I got around that fact by looking at /etc/ and if that's missing then looking at d:\configs.
But I don't quite like this way of doing it, because, if there is another windows developer looking into it and he doesn't have d:\ or prefers elsewhere for configs it would get messy.
Is there any way I can load a file from clojure, no matter what operating system it is? My initial thoughts were of saving a key-path in the Environment variable and accessing it from clojure.
I am just wondering if there is a better way of doing it.
Thanks.
Have a look at environ. It offers some flexibility when it comes to configuring your Clojure app, letting you choose between a number of options:
environment variables: This seems to be the way to go in Clojureland, so I'd say your initial thought wasn't the worst;
in ~/.lein/profiles.clj: You can store them in the :user profile as Clojure data - that sounds quite nice, I guess;
Java CLI properties: Finally, you can pass them to the java executable directly via the command line.
environ will collect data from all these places.
Is it possible to schedule a custom action after a reboot? Here's my predicament.
I have a product to uninstall and reinstall but some of the files are in use by another application at the time of reinstall. This causes problems for the uninstall because the files are in use so I use a custom action which runs a batch file to rename the files in use. This is a bit of a hack but makes the uninstall and reinstall not complain about the files being in use and replaces the files I want.
The reason for doing this is that I'm not allowed to force a reboot on the machine during the installation process but I need to make sure that the files get replaced. So far so good.
This has the side effect of a bunch of files hanging around that I've renamed with a prefix toDelete_fileX.dll along with the new fileX.dll in the folder.
I have another custom action to delete these files which works fine but I can't run it at the end of the installation because the other application still has a handle to these renamed "toDelete_" prefixed files.
At some point in the future the system will be rebooted and this is where I would like the custom action to run to delete the "toDelete_" prefixed files.
Thanks. Neil
Take a look at this property MSIRESTARTMANAGERCONTROL, you can use this to prevent the files in use dialog, combining this with /qn for msiexec will allow you to do it silently.
When it comes to installers, if you start running batch files during the install transaction you are really on your own as Windows Installer cannot track this. Unless there's a really good reason to roll your own CA I would steer clear.
I think in your case Windows Installer will be able to take care of the renames, when you do eventually reboot. If I've understood correctly you don't mind the reboot, its just you would like to schedule this at a later date/time.
You can schedule actions after a reboot by using RunOnce registry key:
http://msdn.microsoft.com/en-us/library/aa376977(VS.85).aspx?ppud=4
http://support.microsoft.com/kb/137367
However, I think your going the wrong way with this. If you can offer more details about what you need to do (the design or concept), perhaps I can suggest a better alternative.
I installed Ruby on Rails 3 using bash on OSX Lion.
When I wanted to use zsh and do a "rails -v" command I had "Rails is not currently installed on this system".
I just do not understand why. To me it's like "you can access all the files you want with bash not with zsh".
If I want to switch to zsh, will I have to install one more time Rails? delete the old one?
Is it secure and clever to use two shells when developing Rails applications?
What are your best practices?
Thanks in advance.
PS: I am new to programming and my installation is working fine. I even created one app.
EDIT: If you encounter the same problem I would encourage you to read the second answer first to get the rationale then the first one. Thanks to both of them.
While you are running bash, type at the command line echo $PATH.
Now start up your zsh command line, and type echo $PATH.
I bet the Rails path is not included in your zsh, right?
Look in your $HOME dir for .bash* files. See which one has the Rails PATH added.
Find your zsh .* env files and copy/paste the line you found above into the approriate file.
When I say .bash* and .* files, I mean hidden files in your home dir that you'll only find by doing ls -la. If you find a .profile file, that would be a good place to insert this.
I hope this helps.
P.S. as you appear to be a new user, if you get an answer that helps you please remember to mark it as accepted, and/or give it a + (or -) as a useful answer.
I just do not understand why. To me it's like "you can access all the
files you want with bash not with zsh".
As shellter said, you must have directories added to your path in order to run commands from the command line. For more information on PATHs take a look at the Intro to Linux guide. I know you are not using Linux but that section (and lots of others) is very much applicable.
If I want to switch to zsh, will I have to install one more time
Rails? delete the old one?
No, see note on paths above and take a look at the guide.
Is it secure and clever to use two shells when developing Rails
applications? What are your best practices?
It's not really something special to use two shells at once. It depends what you do in each. I often have 6 and 7 shells open, not all for the same thing. That is really up to you and how you work. The number of shells you use is more of a workflow thing than a "best-practices" issue.
I normally have 3 shells open when I do RoR work. One running autotest in the background, one running rails -server, and one where I actually edit files and run emacs. But again, this is not best practice as it is workflow. Do whatever makes you effective.
The only trouble you could get into occasionally running two shells is say, for example, you open a file in one and delete it in another. However, when you do this it is typically very obvious.
PS: I am new to programming and my installation is working fine. I
even created one app.
For Rails, I found this tutorial very helpful.
Also, you said you were new to programming. I don't know if this is the case, but I would suggest starting with basic Ruby, before jumping into Perl. Although the tutorial I linked above covers Rails-flavored Ruby.
I'm trying to configure Apache 2.2 from ports (in FreeBSD). I've written my own makefile with my desired compile options and as far as I can tell, everything seems to check out. I.e.:
make -V <env_var> __MAKE_CONF=~/mk/make.apache22.conf
returns what I expect except for PERL5 and USE_PERL5. I've tried setting both variables in make.apache22.conf as well as setting the environment in every combination there is:
export PERL5=/usr/local/bin/perl
export USE_PERL5=5.12+
and yet
make -e -V USE_PERL5 -V PERL5
returns
yes
/usr/local/bin/perl5.10.1
(i've also tried overriding with -E.) The other thing is that I only have Perl 5.12.1 installed, so the version is clearly coming from either the Perl port and/or bsd.perl.mk, but the way I'm grokking bsd.perl.mk and the make utility itself I don't understand why my methods aren't working.
What am I missing?
So, in short, the answer lies within the ports system. From /usr/ports/Mk/bsd.port.mk:
Note: the distinction between the USE_* and WANT_* variables, and the
WITH_* and WITHOUT_* variables, are that the former are restricted to
usage inside the ports framework, and the latter are reserved for user-
settable options. (Setting USE_* in /etc/make.conf is always wrong).
Usually, when installing from a port, the Makefile will recursively include a chain of files which at some point brings in:
/usr/ports/Mk/bsd.perl.mk
and this file evaluates all the USE_PERL* and PERL* variables defined the port's Makefile. In particular, bsd.perl.mk hard-codes the required Perl version and will install the Perl port if it isn't already on the system.
The ports system is pretty cool, but I find this sort of thing frustrating as there doesn't appear to be any straightforward way to configure a port to build and/or run using pre-existing software.
UPDATE Aug 8, 2010:
The bottom line is you either use ports or you don't. If you don't, you have to manually configure and track everything yourself but you also get the latest and (hopefully) greatest. The ports system is good, especially since each port can be configured as necessary and you get the advantages of easy upgrading and package management. (For, say, making custom compiled packages to install into jails--especially using a tool like ezjail.) The downside is that sometimes you have to wait a bit before a port is updated to the latest version. This isn't a big deal for common software, but you might be waiting a little while for more obscure items.
Ultimately, the solution here is to install the Perl 5.12 port and go from there.