I have already installed rstudio server and shiny-server on my ubuntu machine (ec2 aws). I usually code in rstudio server, drop the scripts of my shiny applications in /srv/shiny-server and go to the url of the application to see it and everything works.
Since a few days I want to go through gitlab ci/cd for versioning and to automate my work, however when I run my gitlab-ci.yml I get this error :
Being new to CI/CD, I'm having a really hard time and I'd like your help if possible. Thanks
Related
I am running Invoke-webrequest to upload files to Nexus repository from both linux and windows machines. Things were working fine till few days ago it started failing in Linux with the following error message. Unable to write data to the transport connection: Connection reset by peer. If I run Curl command I get the following error message "curl: (56) OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104". Any ideas what's going on? I tried working with our security team but not catching anything suspicious.
FYI, source is Azure and Destination is AWS. Running Invoke-Webrequest from Windows machine in Azure to Windows machine in AWS is working fine.
OS: Ubuntu 16.04
Hypervisor: VirtualBox
Network configuration: Nat Network with port forwarding to access the vms through the host ip. I can also ping a VM from another VM.
I try to connect my Jenkins app hosted on a VM to my BitBucket server also on a VM. I followed a tutorial on internet but when i enter the address of my git repository i'm getting this:
Failed to connect to repository : Command "usr/bin/git ls-remote -h http://admin#192.168.6.102:8005/scm/tes/repository-test.git HEAD" returned status code 128:
stdout:
stderr: fatal: unable to access 'http://admin#192.168.6.102:8005/scm/tes/repository-test.git/': The requested URL returned error: 403
So, to be sure I tried to exectute the command on the terminal... and on the terminal it seems to work.. I can also push, clone, pull etc..
On this image you can see that it's true
Do you have an explanation?
EDIT:
I try some others things like use or not sudo to see if the permissions problem came from that and it seems that it's not the case.
But I see that there is no result when we use the "HEAD" argument.
Do you think that because "HEAD" give no result, git in jenkins interprets it like no answer and returns the damn** error 403?
EDIT 2:
I found that on the web: http: // jenkins-ci.361315.n4.nabble.com/Jenkins-GIT-ls-remote-error-td4646903.html
The guy has the same problem but in a different way, I will try to allocate more RAM to see if it does the trick.
There could be many possible problems, but you are getting 403 - Access Forbidden, which indicates some problem with permissions. I would suggest first common mistakes:
a) trying https instead http - my scm only uses https,
b) check if admin is correct - scm by default uses scmadmin.
Here I run the exact same command twice.
The first time I used the proxy configuration wich I need to access internet, and the second time I set the mandatory server on "none".
So there is a problem with the damn proxy.
I was thinking that the proxy was not used in NAT connection with VirtualBox...
I found the solution.
I had to reinstall jenkins to have a user named "jenkins" with his own home directory.
I don't know if it is linked or not, but I configured my bitbucket server to use only HTTPS with a self signed certificate (I work in lan)
My troubleshoot was linked with my proxy settings.
I disabled all my proxy settings in Linux so I was able to launch the command that did'nt worked in jenkins with terminal.
I logged with sudo su jenkins the commands also worked.
I found out that in the home directory of the jenkins user there was a "proxy.xml" file. I opened it and saw my old proxy settings.
I deleted all the content with vim, saved and restarted and the error was gone.
there can be git version miss match.....
I would suggest you update git once. maybe it will resolve your issues.
I have a python script which use rest-api to communicate with my server.
I am using python-requests to handle rest-api.
The script has a loop and try-except for handling errors to keep it running.
On centos, I accidentally mis-configured the dns and started my script.
Here is the error:
HTTPConnectionPool(host='host.com', port=80): Max retries exceeded with url: //rest/url (Caused by NewConnectionError(': Failed to establish a new connection: [Errno -2] Name or service not known',))
Then I reconfigured the dns properly without restarting the script, but the script still didn't work unless restart it. Same error.
Programs started after dns reconfiguration like ping, web browsers were working fine.
Same problem happens for ping if it is started before dns reconfiguration, but not for firefox.
It seems that firefox took a while to adapt new dns configuration.
On debian, this problem does't exist.
When I reconfigured the dns properly, the script or other programs started to work almost immediately.
Is there anything special with dns on centos?
Can my script adapt new dns configuration without restarting?
==========================
python-requests version I tested:
2.11.1, 2.12.4, 2.13.0 On centos
2.11.1, 2.12.4 on debian
centos version tested:
6.2, 7.3-1611
debian version tested:
debian-sid latest update
python version:
2.7.13rc1 on debian
2.7.5 on centos 7.3-1611
2.6.6 on centos 6.2
problem solved by calling __res_init in glibc.
More details see Python not getting IP if cable connected after script has started and http://bugs.sugarlabs.org/attachment/ticket/1940/network.py.patch
I am trying to install Gitlab on my newly bought VPS(DigitalOcean, Ubuntu), but after the install and reconfigure, I can't get to the setup page of Gitlab. It's just showing the standard apache not found page. I have changed external_url to -> 'http://myip/gitlab'.
The errors I received after changing the url and reconfigure are below:
Error executing action run on resource 'execute[clear the gitlab-rails cache]'
Error executing action run on resource 'execute[create gitlab database user]'
Error executing action run on resource 'bash[generate assets]'
Error executing action restart on resource 'service[unicorn]'
Error executing action restart on resource 'service[sidekiq]'
Error executing action run on resource 'execute[clear the gitlab-rails cache]'
The Lamp stack is installed, and some basic ufw firewall.
I have used the official Gitlab install/download guide:
https://about.gitlab.com/downloads/#ubuntu1604
Using /gitlab is actually not supported from a omnibus installation. You would need to host it on a (sub)domain.
There is however a way to enable this but it will require quite a significant amount of work to enable GitLab to work like you want. There is quite a extensive tutorial in the GitLab Documentation so I recommend you check that out.
After 5 years, there happened a similar issue. since this one has no accepted answer besides being old, I have given an answer to it that seemingly solved the problem.
If someone finds this post, please check if that solves the issue: installed gitlab on ubuntu shows apache default page
I have a fresh, text-only installation of openSuSe 13.1 (physical server, old Samsung netbook), and I'm trying to get OTRS up and running. I've installed OTRS using the below commands. I don't think they're all necessary, but someone in the OtterHub forums had a successful installation with the software versions I'm targeting using this sequence, so I was trying to piggyback on that success.
zypper in otrs-3.3.4-01.noarch.rpm gcc make mysql-community-server perl-Crypt-SSLeay perl-JSON-XS perl-YAML-LibYAML
zypper in perl-Text-CSV_XS perl-PDF-API2 perl-GDGraph perl-Encode-HanExtra postfix perl-DBD-mysql
cd ~otrs && bin/otrs.SetPermissions.pl --otrs-user=otrs --web-user=wwwrun --otrs-group=www --web-group=www /opt/otrs
rcmysql start
systemctl start apache2.service
mysqladmin --user=root password password
All of that works fine. I'm able to get to the OTRS web installer, but that's where I get hung up. I get to the part of the web installer that creates the database, and it times out. The script successfully creates the database and updates Config.pm with the new password. I can't tell from installer.pl what it tries to do next.
Here's the error from /var/log/apache2/error_log:
[Tue Jan 28 20:53:23.136306 2014] [cgi:warn] [pid 6856] [client 192.168.1.10:52732] AH01220: Timeout waiting for output from CGI script /opt/otrs/bin/cgi-bin/installer.pl, referer: http://svr-clptest/otrs/installer.pl
[Tue Jan 28 20:53:23.136470 2014] [cgi:error] [pid 6856] [client 192.168.1.10:52732] Script timed out before returning headers: installer.pl, referer: http://svr-clptest/otrs/installer.pl
The browser displays the following:
The gateway did not receive a timely response from the upstream server or application.
This is on a local network at home. I'm accessing the Linux server using PuTTY from a Windows 8 machine. I'm using a wireless connection from the Windows 8 machine, but the server has a hard line connection to the router, if that makes any difference. I don't have any trouble executing anything from PuTTY or accessing the index page through the browser (Firefox 26). I've tried connecting from a computer on my network, and one off of my network. In both cases, I'm able to get to my domain and the web installer. But I can't make a PuTTY connection to the server from outside my network.
I've spent a couple of hours researching the error, and I can't figure out what the next step should be.
Right now, a text-only version of openSUSE and OTRS are the only things running on the machine. I haven't done anything else with it. I'm open to starting the installation from scratch again--OS and all. I'm thinking that the timeout error has something to do with my firewall settings, but I'm not a network guy. Really have no idea how to diagnose this.
UPDATE
I tried reinstalling everything fresh tonight, but then added KDE so I could walk through the web installer on the host. I get exactly the same errors. It's not a problem between server and client. Something's wrong with OTRS... Or maybe with apache?
I eventually just had to follow the steps for manual installation instead of using the web installer. Not sure where the problem was exactly, but no matter what I tried, I couldn't get the database setup to work through the web installer. If you're having a similar problem, once you get to the part of the instructions that tell you to move to the web installer, you can switch over to the instructions to install from source and pick it up from manual installation of the database.