I have noticed this command running "sustes" and I'm having a hard time finding information about it.
It seems to be a mining hack using servers to mine cryptocurrencies.
wc.conf in the /var/tmp directory
(and this conf references cryptonight algo and pools of IPs for mining)
Has anyone else had this issue and if so what is the best way to remove and stop this hack?
This was a remote hack taking advantage of a vulnerability in solr. To fix this upgrade your solr to a newer patched version.
Related
I'd like to upgrade to the newest version of Perl6,
rakudobrew build moar
Update git reference: rakudo
Cloning into 'rakudo'...
fatal: unable to connect to github.com:
github.com[0: 140.82.114.4]: errno=Connection timed out
Failed running git clone git://github.com/rakudo/rakudo.git rakudo at /home/con/.rakudobrew/bin/rakudobrew line 57.
main::run("git clone git://github.com/rakudo/rakudo.git rakudo") called at /home/con/.rakudobrew/bin/rakudobrew line 397
main::update_git_reference("rakudo") called at /home/con/.rakudobrew/bin/rakudobrew line 368
main::build_impl("moar", undef, "") called at /home/con/.rakudobrew/bin/rakudobrew line 115
this is just a simple connection failure, but how do I fix this?
Your connection problem is not really anything to do with any P6 related software, or in fact any software you're using. It is, as you say, "just a simple connection failure". And most such failures are transient and "fix themselves". As JJ notes, in such scenarios you just wait and then things start working again.
So by the time you read this it'll probably be working for you again without you having fixed anything. But I'm writing an answer anyway with these sections:
Consider not using rakudobrew
Connection problems that "fix themselves"
Connection problems you investigate or fix yourself
Getting around single points of failure
Consider not using rakudobrew
The main purpose of rakudobrew is to support installation of many versions of Rakudo simultaneously and the main audience for the tool is folk hacking on the Rakudo compiler, not those merely using it.
If you're just a regular user, not someone developing the Rakudo compiler and/or don't need to have multiple versions of Rakudo, with complete source code, installed simultaneously, then consider just downloading and installing Rakudo files directly, eg. via rakudo.org/files, rather than via rakudobrew.
Connection problems that "fix themselves"
rakudobrew failed because a git clone ... command failed because the connection with the github.com server timed out.
A server timing out when doing something that usually works using a connection that usually works is likely a transient problem, aka a "please try later" problem.
Transient problems typically "fix themselves" a few seconds, minutes or hours later.
If there's still a problem when you try again, and you want to spend time trying to find out what's going on officially, then look for a status page for that server.
Here are two status pages I know of for github.com:
https://www.githubstatus.com/
https://twitter.com/githubstatus?lang=en-gb.
And for unofficial scuttlebutt I suggest reading the twitter feed.
For me, right now, github.com is working fine and the status page says all systems are go.
So it should now be working for you too.
If it's not, then you can wait longer, or investigate. It you want to investigate, start by looking at the status pages above.
Connection problems you investigate or fix yourself
If github claims it's working fine then there's presumably a problem with your local internet "on-ramp" (your system or your internet service provider's) or somewhere further afield between your on-ramp and the server you're failing to connect to. (You can only know approximately where the server is based on which region of the world administers the IP address the server is associated with at any given moment.)
The next place to look will be places like the internet traffic report; this indicates traffic jams and the like across the planet. (Ignore the visual display, which is broken on some browsers, and click on the links in the table to drill down.)
If it's all green between you and the region that administers the IP address of the server you're failing to connect to, then the next place to turn would be your system's administrator and/or ISP.
Failing that, then perhaps you can ask a question at a sister stackexchange site like serverfault.com or superuser.com.
Getting around single points of failure
Perhaps you were thinking there might be some system redundancy and/or you're interested in that aspect.
P5's ecosystem and its tools are generally mature and limit spofs. This is unlike the ecosystems and tools of most of the other languages out there; so if you've gotten used to the remarkable reliability/availability of CPAN due to its avoidance of spofs, and by extension perlbrew, well, you've been spoiled by P5.
The P6 ecosystem/tool combinations are evolving in the P5 tradition.
For example, the zef package manager automatically connects to CPAN alongside github, and is built to be able to connect to other repos. The ecosystem is partway there to take advantage of this zef capability in that many modules are redundantly hosted on both CPAN and github.
rakudobrew ignores CPAN and assumes use of git repos. It is impressively configurable via its Variables.pm file which includes a %git_repos variable, which could be re-targeted to an alternative git repo site like gitlab. But no one has, to my knowledge, arranged to redundantly copy and update the relevant rakudo files to another git repo site, so this spof-avoidance ability apparently inherent in rakudobrew's code is, afaik, moot for now.
When trying to setup automated backup under Ubuntu 17.10 using Deja-Dup I realized that one can not backup the root directory since a normal user starting the deja-dup application does not have all rights to access all files in /.
(german discussion about rather similar situation can be found here: https://forum.ubuntuusers.de/topic/wie-sichert-an-mit-deja-dup-ein-systemverzeich/)
The usual workaround to gksu the deja-dup application does no longer work on Ubuntu 17.10. It seams that a decision has been made to prevent users from starting graphical applications as root on purpose for it is often a bad/risky think to do.
However to create regular backups of a Systems / directory with deja-dup the application has to be configured and later on started as root.
Since the typical ideas like gksu, gksudo, sudo -H do not work unter Ubuntu 17.10 I would highly appreciate any advice on a secure practice to get to run deja-dup as root. Can someone help with advice?
It seems prudent to first mention this issue and then this aptly-named edit which seems related and has made hh_server refuse to run on NFS file systems. I am not very familar with file systems and have never touched OCaml before, so in trying to accomplish the question title, I have tried editing what I know: /etc/hh.conf and /etc/hhvm/{php, server}.ini, adding hhvm.[server.]enable_on_nfs = true by pure guesswork. No dice.
As I understand it from the issue, the change stems from the hh_server daemon being unable to register changes to the files via inotify on NFS drives, which is totally understandable. However, my VirtualBox is purely a test server for me familiarizing myself with Hack (i.e. only running the typechecker), and I've successfully run hh_client on sshfs-mounted (osxfuse) drives before. Is there another problem I'm not aware of that makes this a bad idea? If not, how might I enable hh_server --check to run on my VBox NFS shared folder?
The main issue is the lack of inotify support for NFS, so hh_server may respond with stale data.
If you accept the risk, you can add enable_on_nfs = true to /etc/hh.conf, which will enable hh_server to check folders on NFS.
I am on Mac OSX Lion using Nginx 1.4.1. I am using nginx in conjunction with Tornado.
In the process of installing the Nginx upload module (v. 2.2.0) I encountered some compatibility issues. See this reference for more info. Apparently, there is no great fix for this as of yet. My specific error is rooted in: error: no member
named 'to_write' in 'ngx_http_request_body_t'
Is there a way to make the two of these reliably compatible without jumping through hoops?
Or, is there a suitable alternative to using this upload module that will work with Nginx 1.4.1?
If not, should I considering using Nginx 1.3.8? And if so, where can I download this version? I do not see it available for download on their website here.
Thank you for the help. Regards.
1) No, it doesn't seem like there is as the maintainer of nginx-file-upload has implied he doesn't want to maintain it any more.
2) I found this article which lists some alternatives. One of which is nginx-big-upload I've not tried it yet.
3) Well you could consider it but then you're tied in to a package that isn't maintained. What happens if there's a security vulnerability for 1.3.8? You can't upgrade without either patching or changing your file upload strategy. If you want to, you can find all of the older Nginx versions here
The situation is pretty frustrating at the moment but there are options, just none of them are tried and true. When dealing with production systems stability and security are key.
1) Yes, this module dose not support for nginx 1.4+.
2) The reason is that nginx support chunked of thansfer-encode, and improve its code design. that it remove the field to_write of ngx_http_request_body_t struct.
3) https://github.com/hongzhidao/nginx-upload-module. This is an alter module. It support the latest nginx, and the feature is equal.
I have an application with some cacheing backend and I want to clear the cacheing whenever the webserver is been restarted.
Is there a apache configuration directive or any other way to execute a shell script upon webserver (re)start?
Thanks,
Phil
Adding some more information, as asked by some answers already:
Base system is ofc linux based, in this exact situation: CentOs
Modifying the startup script is unfortunately no option as pointed out by one of the comments already, due to it beeing not configuration file within the respective RPM packages and therefor beeing replaced by updates. Also I think modifying the startup script would be a bad thing in general
I see, that actually linking both "restarting the webserver" and "clearing my app cache" is not exactly what should be tied together. I will consider other alternatives
My situation is as follows: I can define how the virtual host config looks like, but I can not define how the rest of the servers configuration looks like.
The application is actually PHP based (and runs on the symfony framework). Symfony pre-compiles alot of stuff into dynamic php files from what it finds in the static configuration files. We deploy our apps via RPM and after deployment, an webserver restart is actually initiated already, so I thought it might make sense to tie the cache-cleanup to it. But I think after getting all your feedback, it looks like it is better to put the cache cleanup process into the installation process itself.
You haven't provided a lot of detail here, so it's hard to give a concrete answer, but I would suggest that your best option is to write a script which handles restarting apache, and clearing your cache. It would look something like this:
#!/bin/sh
# restart apache
/etc/init.d/httpd graceful
# whatever needs to be done to clear cache
rm -rf /my/cache/dir
Ramy suggests modifying the system startup script for Apache -- this is a bad idea! If and when you update Apache on your server, there is a good chance that your change will be lost.
Dirk suggests that what you are trying to do is probably misguided, and I think he's right. You haven't told us what platform you are running, but I can think of few situations where restarting your webserver and clearing a cache actually need to happen together.
You can modify Startup script for the Apache Web Server in /etc/init.d/httpd and write your own syntax inside it.
chattr +i /etc/init.d/httpd
If you have (root) access to the server you could do this by shell scripts but I would consider if it is the best way of cache management to rely on apache restarts.