acme.sh --renew-all --stateless seems to ignore the --stateless flag and run stand-alone. I've tried all the command-line finesse I can think of (--stateless ahead of --renew-all, --renew -d mydomain.com, etc.) It always wants to run stand-alone.
What am I missing something? A work-around? I really don't want to dive into script source.
Debian 11.1, acme.sh --upgrade telling me I have the latest, nginx (with /.well-known/ config verified via browser).
Related
What exactly does command sudo setsebool -P nis_enabled 1 ? It seems to fixed strange access denied errors when running rabbitmq on Centos 7. All I know is that it i somehow related to SELINUX (what is for me black magic and often the reason why various programs mysteriously does not run).
I Guess NIS=Network Information Service
at this point when I log into my CentOS machine, I get this:
groostav#mymachine:~$ ssh root#my.company.com
root#my.company.com's password:
Last login: Mon Aug 20 13:52:47 2018 from s12345.vs.shawcable.net
-bash: brew: command not found
-bash-4.2#
I've gotten to this state by very carelessly trying to get a nice git prompt --evidently I even managed to get some mac osx code on my bash configuration path somehow. I've also blown up my old prompt which was in the form user#host:pwd #, which I would prefer.
I've been greping around but I cant find where the problem configuration is. Both the /etc/bashrc and ~/.bashrc files look fine (the former seems like a default, and the latter has a number of commented-out lines in it).
Where is this brew command and how did it get there!?
How did my prompt get reverted from the usual form to this basic form?
for bonus points, anybody know a very simple git prompt configuration? I'm remoting into this machine from linux machines and WSL, so fancy colors and unicode are a bad idea.
Many thanks!
This is really frustrating me. I have a DO VPS with ubuntu 14.04 (64) installed.
I installed VestaCP as control panel on that and have hosted some PHP based personal project.
I also installed meteor on it but never used, now when I am trying to create a project and run it ('meteor create rt' then 'cd rt' then 'meteor')
It is giving the following error :
[[[[[ /home/admin/code/rt ]]]]]
=> Started proxy.
Unexpected mongo exit code 1. Restarting.
Unexpected mongo exit code 1. Restarting.
Unexpected mongo exit code 1. Restarting.
Can't start Mongo server.
root#RD:/home/admin/code/rt#
Could anyone please help? Please ask me for more informations if required.
**** EDIT ****
I created a fresh DigitalOcean server and it is giving the same error on that. Some issue with Digital Ocean? File System of Digital Ocean? I am confused. I am trying it on different flavours of Linux and same result. All are fresh linux installations.
I finally got the solution. Posting it here for others.
This was the problem as a few environment variables which mongodb looks for while starting was not set
Set the variables LC_ALL and LANG and it works fine (mostly setting LC_ALL will do)
first, type locale command and see the output, you will see that it will say something about LC_ALL not set.
Now, add these two lines in /etc/environment and it worked.
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8
This solution is for Ubuntu 12.04 +
Other variants may require similar work.
Unexpected mongo exit code 1 is still an uncaught exception as far as i think.
You can try by updating your c/c++ compilers uptodate. Have a look here.
It says :
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install gcc-4.6
sudo apt-get install g++-4.6
All the best!
So we have narrowed the issue down to meteor's mongo installation on your box (though I think we were pretty sure of this all along). Let's attempt to debug that a bit. The way I have done this in the past is to try to open meteor's mongo with the mongod provided by meteor. You will perform these procedures without running the meteor server. This should give you the warning that is causing Mongo to exit. First you need to find this. In my instance installed on Mint (which should be similar to Ubuntu) it is at:
~/.meteor/packages/meteor-tool/.1.1.3.4sddkj++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/mongodb/bin/mongod
You can look at that location on your Ubuntu box or you can run something like this to get the location:
find ~/.meteor/ -name mongod
Once you find the location then go to the directory of your meteor project you are attempting to run and in that directory you should find this location:
<your meteor project>/.meteor/local
cd into that directory and run the following command:
~/.meteor/packages/meteor-tool/.1.1.3.4sddkj++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/mongodb/bin/mongod --dbpath ./
From there you can analyze the output (or update the question so we can see the output) and this should show you the mongo error you are receiving on startup and allow you to fix it.
I've got the same issues trying to start a meteor app and exactly the mongodb server is being terminated in an unexpectly manner. Generally the virtual linux server from some dealers like the one you mentioned are coming without a swap partition (check in /etc/fstab file) so if you have not enough memory to allocate MongoDB server then meteor app can't be started. You can create a swap partition or instal swapspace
sudo apt-get install swapspace
After that I was able to start the meteor app... Just be patient as swap memory is not as faster as RAM.
Since due some "smart" StackExchange policy I cannot up-vote or comment to working solution...)
Quoted answer works also on Digital Ocean on CentOS 7 x64 vmlinuz-3.10.0-123.8.1.el7.x86_64
first, type locale command and see the output, you will see that it will say something about LC_ALL not set.
Now, add these two lines in /etc/environment and it worked.
I changed the locale setting to match my needs.
Fixed on my Debian 8 with the following bash command, (use sudo if needed)
localedef -i en_US -f UTF-8 en_US.UTF-8
We are running a high-traffic, load-balanced site on CentOS. When I installed haproxy, I used:
make TARGET=linux26 USE_OPENSSL=1 ADDLIB=-lz
make PREFIX=/usr/local/haproxy install
but now I need to add zlib support.
I know that the command for a fresh install would be:
make TARGET=linux26 USE_OPENSSL=1 USE_ZLIB=1 ADDLIB=-lz
make PREFIX=/usr/local/haproxy install
But how do I recompile it into an existing haproxy install without uninstalling first? The site is too high traffic to take it down for even a minute.
I spent 30 minutes Googling for the answer and while I found something that talks about using make clean to do a recompilation, as somewhat of a Linux noob, I thought I should ask the experts how it's supposed to be done and for the exact syntax.
make clean will indeed clean your compilation directory.
My advice would be to:
clean the compilation directory, NOT the install dir
recompile with zlib support
install in another dir
change the currently installed non zlib haproxy to another path
which translates in bash to
make clean
make TARGET=linux26 USE_OPENSSL=1 USE_ZLIB=1 ADDLIB=-lz
make PREFIX=/usr/local/haproxy-zlibed install
mv /usr/local/haproxy /usr/local/haproxy-not-zlibed
ln -s /usr/local/haproxy-not-zlibed /usr/local/haproxy
At this point you're in the exact same situation as you were before.
then use symbolic links to switch from your current haproxy to the other:
use the current haproxy (without zlib)
rm -fr /usr/local/haproxy
ln -s /usr/local/haproxy-not-zlibed /usr/local/haproxy
and restart haproxy your usual way
or, to use the haproxy with zlib support
rm -fr /usr/local/haproxy
ln -s /usr/local/haproxy-zlibed /usr/local/haproxy
and restart haproxy your usual way
That way you can test your new zlibd haproxy and rollback if necessary
On Linux there's no need to uninstall or even stop a service before you recompile and reinstall.
That's true because of how modern (and even not-so-modern) filesystems work: File contents are attached to inodes and inodes are attached to directory entries (having a 1:0..n relationship). Thus, you can delete the directory entry for a running program, but as long as its inode isn't deallocated (which will never happen so long as it continues running), it still has a file handle on its own executable, and can continue to work.
Now, with HAProxy in particular, there's support for seamless restarts -- where a new process starts up, tells the old process to drop its listen sockets but keep servicing the existing connection, grabs new listen sockets itself, tells the old process that this succeeded (or if it failed, in which case the old process regrabs its own listen sockets), and then allows the old process to shut down when done. See http://www.mgoff.in/2010/04/18/haproxy-reloading-your-config-with-minimal-service-impact/ for a writeup on the process.
MovableType 5.2 has builtin PSGI support (via a mt.psgi in the main directory) and I've been trying to take advantage of it using starman/plackup.
Starman w/ MT fires up, but I get odd Not Founds and a silent hang & fail when I run mt-upgrade.cgi.
How I am running starman:
cd /home/ec2-user/mysite/perl/components/movabletype
plackup -s Starman --port 8045 --error-log /home/ec2-user/mysite/perl/logs/starman.log --pid /home/ec2-user/mysite/perl/var/starman.pid -a mt.psgi
Mystery 1: My browser returns "Not Found" for index.html, but mt-static and mt.cgi is reachable.
X http://mysite:8045/mt/index.html ... Not Found
✓ http://mysite:8045/mt-static ... listing of static assets
✓ http://mysite:8045/mt/mt.cgi ... redirects to ...
X http://mysite:8045/mt/mt-upgrade.cgi?__mode=install ... fails
Mystery 2: Due to the redirect I believe that MT code is running. But it is mostly silent in the starman log even though I have tried different MT debug options. Worse, the mt-upgrade.cgi seems to be reached then fails with this lone message to the starman log:
[mypid] Bootstrap CGI script in non-buffering mode: /home/ec2-user/mysite/perl/components/movabletype/mt-upgrade.cgi
This non-buffering message seems informational and normal, and is coming from the MT codebase.
I have also run directly under starman and get the same result.
Any ideas or help would be appreciated!
System/Environment:
MT_HOME='/home/ec2-user/mysite/perl/components/movabletype'
linux AMI on an amazon ec2.
perl-5.16.0 under perlbrew.
CPAN modules:
cpanm starman
cpanm CGI::PSGI
cpanm CGI::Parse::PSGI
cpanm CGI::Compile
yum install expat-devel
cpanm XML::Parser
cpanm SOAP::Lite
cpanm SOAP::Transport::HTTP
cpanm XMLRPC::Transport::HTTP::Plack
cpanm DBI
sudo yum install postgresql9-devel
cpanm DBD::Pg
cpanm Task::Plack
MT config:
CGIPath http://mysite:8045/mt
StaticWebPath http://mysite:8045/mt-static
PIDFilePath /home/ec2-user/mysite/perl/var/starman.pid
DebugMode 1
ObjectDriver DBI::postgres
Database db
DBUser dbuser
DBPassword dbpass
DBHost dbhost.mysite
I'm Yuji Takayama, lead engineer of Movable Type. I did try to reproduce your steps but I was not able to reproduce this. (this means I got initial install screen)
So, Can you try with mysql? also can you try "tools/upgrade" script? I think you can get error messages when some errors occurs.
ex.)
cd MT_HOME; perl -Ilib -Iextlib tools/upgrade --username --password --nickname --email --preferred_language --site_name --site_url --site_path --site_theme --site_timezone
And, I have answer about "index.html was not found".
Reason: MT will never mount MT_HOME as static files directory like a mt_static, because we think that MT_HOME must not be possible to list.
If you are trying to run Movable Type under Starman, I would seriously recommend running the upgrade script that comes with Movable Type using the command-line equivalent of your choice. There is no good reason for mt-upgrade.cgi to become persistent in the manner that Starman and Plack permit.
Try to change your paths in mt-config.cgi to relative paths, not URLs. Like so:
CGIPath /mt/
StaticWebPath /mt-static/
Just curious: although it does work now, are you aware that PG isn't supported and that you're taking a risk that a future version of MT might break with it?
P.S. also don't forget the PIDFilePath directive mentioned in the documentation.
BTW, a 404 on http://mysite:8045/mt/index.html looks quite normal. You're not supposed to have your site index at the same level than MT (you could, but that's not the recommended setup and it won't work in a stock MT install that assumes that MT and the produced sites are clearly separated).