Is there a YAML config fix for `Failed to fetch http://deb.debian.org/debian/dists/jessie-updates/InRelease` - yaml

I've seen a lot around this issue but so far nothing that works in my circumstance. I have a Hexo blog deployed over CircleCI that had no issues, and without making any changes to my YAML config the build began failing when I pushed updates. Of the existing issue reports and fixes I've seen nothing has worked when applying to my circle.yml file, and I'm not sure where to go from here.
Many solutions recommend adding some script to update the URL, but I think that's taking me in the wrong direction, and frankly beyond my current knowledge.
During CircleCI's build when it gets to the AWS CLI build:
name: Install AWS CLI
command: |
apt-get update
apt-get install -y awscli
it completes 6 successful gets but then I see:
Fetched 10.1 MB in 1s (6749 kB/s)
W: Failed to fetch http://deb.debian.org/debian/dists/jessie-updates/InRelease Unable to find expected entry 'main/binary-amd64/Packages' in Release file (Wrong sources.list entry or malformed file)
E: Some index files failed to download. They have been ignored, or old ones used instead.
Exited with code 100
That step previously gave me:
Get:7 http://deb.debian.org jessie/main amd64 Packages [9098 kB]
So despite this being well documented, I've struggled to find a solution that works in my Hexo, Node-based setup. If you can teach me something new I'd be much appreciative!

Related

Metasploit Framework .go module can't be loaded

This is my first post, so I might get the format wrong.. Anyway, after searching for a solution online (which I could not find), I resorted to asking here.
Upon launching my msfconsole a few days ago, I started getting all of these warnings/errors which were not showing before.
$ sudo msfconsole
[!] The following modules could not be loaded!..\
[!] /usr/share/metasploit-framework/modules/auxiliary/scanner/msmail/host_id.go
[!] /usr/share/metasploit-framework/modules/auxiliary/scanner/msmail/exchange_enum.go
[!] /usr/share/metasploit-framework/modules/auxiliary/scanner/msmail/onprem_enum.go
[!] Please see /root/.msf4/logs/framework.log for details.
metasploit v6.0.31-dev
I could not find any solution to this .go module loading issue. I might have screwed something over some time ago, but my last VM snapshot is just too far away.
Thank you all for your help!
just install go in your kali:
sudo apt install gccgo-go
I also got the same problem.
But, since the error message clearly ask me to check error log file, actually there is clear solution too.
[!] Please see /root/.msf4/logs/framework.log for details.
[09/05/2021 22:29:56] [e(0)] core: /usr/share/metasploit-framework/modules/auxiliary/scanner/msmail/onprem_enum.go failed to load - LoadError Failed to execute external Go module. Please ensure you have Go installed on your environment.
And after the Go installation, the problem is solved.
Therefore, the solutions is that you just need to install Go on your machine.

Yarn: How to link acorn using boltpkg - symlink error

My team has a monorepo where we are using bolt to manage dependencies and linking. I was trying to get the dev environment up and running on my local Windows machine but had issues install/link acorn. What I did was clone the repo, then $ bolt to install dependencies. As you can see, it showed error linking dependencies and complained about acorn.ps1 not being a symlink. I've done some research but none of the solutions I found, such as including --non-bin-links or running as admin, worked for me. I'd appreciate if you could provide some insights on this.
Windows: 10;
Yarn: 1.13.0;
Bolt: 0.22.6 - tried 0.22.4 as well but did not work;
Ok I found the solution to this issue.
acorn is not a dependency for my project, but it is one for yarn itself, as I searched for it and it only appears in yarn.lock. Meaning there's definitely something weird with my current version of Yarn, 1.13.0. So I downgraded it to 1.12.3 and according to the official documentation, installed bolt as a local package instead of a global one. It solved this issue.

Debian Packagemanager won't install vagrant.deb package on alpine-linux, while building docker image

I am new to docker but managed to build myself some dev-environment images ( which is awesome! ). But i wasn't quite satisfied with the filesize of the resulting image, so i tried to migrate the image from node-argon image ( based on debian-wheezy ) to alpine image. Problem is that the installation of vagrant.deb package isn't working correctly. I installed the alpine dpkg package, but get these errors:
dpkg: error: failed to open package info file '/var/lib/dpkg/status' for reading: No such file or directory
I found some threats about this topic, but were not related to alpine installation and wouldn't fix my issues. Relevant docker lines are:
FROM gliderlabs/alpine:3.3
RUN apk add --update dpkg
ENV VAGRANT_VERSION 1.8.1
ADD https://releases.hashicorp.com/vagrant/${VAGRANT_VERSION}/vagrant_${VAGRANT_VERSION}_x86_64.deb .
RUN dpkg -i vagrant_${VAGRANT_VERSION}_x86_64.deb
RUN rm vagrant_*.deb
Someone else got this working - my guess was that there maybe some build/install dependencies missing, but couldn't get it any further. Any advice would be much appriciated.
All the best, florian
In comments below the question we found out, that it is indeed possible to install the vagrant.deb using dpkg on Alpine Linux. However, it was really hackish(!) and at the end the advantage in size of the Alpine Linux didn't matter since the resulting image had a size of 2.5G =).
That's why my answer is (I said that before): Make your life easy and use a Debian or Ubuntu image if you want to install deb packages :)
For all potential Alpine-container users, please think twice if you really need a base image that is a couple of MB smaller than common GNU/Linux base images. You'll pay the price for that few MBs with having a poor shell environment (Welcome to the 80s!) and a significantly smaller amount of available packages.
If you want a minimal container then don't put a distribution into a container, put a process into a container!

OSX Play Framework Auto-Reload

I've been scouring the internet for hours now, there is lots of "helpful" advice...that cause nothing but problems.
This is me, almost exactly:
Play framework auto-loading in docker container
I'm running the latest (I think, don't know how to check but downloaded < a week ago) version of the Play! Framework inside a ubuntu docker container with Java 8, built with the following dockerfile:
FROM ubuntu:latest
MAINTAINER [REDACTED]
RUN sudo apt-get update
RUN sudo apt-get -y install software-properties-common
RUN sudo apt-add-repository ppa:webupd8team/java
RUN sudo apt-get update
RUN echo oracle-java8-installer shared/accepted-oracle-license-v1-1 select true | sudo /usr/bin/debconf-set-selections
RUN sudo apt-get -y install oracle-java8-installer
RUN java -version
Multiple sources across the internet show the same or similar issues, and more or less arrive at the same conclusion. I'm starting my play application as follows:
I'm not going to repeat what's linked above, it's basically an identical situation. (The file changes are detected, it's showing a compile, though webpage doesn't reflect changes.) Further, I'm verifying a correct compile by decompiling the generated .class files, it's showing the correct code.
Now, when I say the magic words: Adding the following line to my build.sbt file
PlayKeys.playWatchService := play.sbtplugin.run.PlayWatchService.sbt(pollInterval.value)
I get an overall build.sbt of:
name := """cms-work"""
version := "1.0-SNAPSHOT"
retrieveManaged := true
lazy val root = (project in file(".")).enablePlugins(PlayJava)
scalaVersion := "2.11.6"
libraryDependencies ++= Seq(
javaJdbc,
cache,
javaWs
)
// Play provides two styles of routers, one expects its actions to be injected, the
// other, legacy style, accesses its actions statically.
routesGenerator := InjectedRoutesGenerator
// Polling for auto-reload, because networked filesystem.
PlayKeys.playWatchService := play.sbtplugin.run.PlayWatchService.sbt(pollInterval.value)
Running ./activator in my project directory causes it to reevaluate my build file and generate the following:
/root/cms-work/build.sbt:23: error: value playWatchService is not a member of object play.sbt.Play.autoImport.PlayKeys
PlayKeys.playWatchService := play.sbtplugin.run.PlayWatchService.sbt(pollInterval.value)
^
[error] Type error in expression
As is apparent, the one-size-fits-all solution is no longer applicable. I've been stumped since. I've found absolutely no notice of any changes since 2.3.x that would make this command invalid. Instead, I see things mentioning "works after 2.3.2", which I am.
PS:
Can anyone explain the odd Ctrl-D behavior described at the end of the linked post. I'm experiencing the same, seems very odd considering the fact that Ctrl-D is supposed to exit...
Ok, more internet scouring, and I finally broke down and dug through the Play! Framework github to find their test built.sbt, which happened to be using the new option.
Apparently, buried deep in the migration guide this was noted. (Took me a while to retrospectively find it.)
My mistake, apparently, lied in the assumption that 2.4.0 was included in 2.3.2+, without checking the well-hidden (in my humble opinion) documentation. For anyone else who comes stumbling along with a similar situation, look no further:
PlayKeys.fileWatchService := play.sbtplugin.run.PlayWatchService.sbt(pollInterval.value)
This is the new syntax for the play polling, as of 2.4.0. Check the migration reports up to the version you are using if this causes another error to see if they've changed it again.
Just wondering, am I crazy to have expected some sort of This is Deprecated message to be spit out instead of just blind condemnation of all that I've done? That seems like something that would be good to add for the future.
error: value playWatchService is not a member of object play.sbt.Play.autoImport.PlayKeys
error: object sbtplugin is not a member of package play
In the Playframework 2.4.X, the SBT setting key playWatchService has been renamed to fileWatchService.
Also the corresponding class has changed. To set the FileWatchService to poll every two seconds, use it like this:
scala PlayKeys.fileWatchService := play.runsupport.FileWatchService.sbt(2000)
Extracted from: https://www.playframework.com/documentation/2.4.x/Migration24#playWatchService-renamed

Unable to install Git using Homebrew

I have been trying to install Git using Homebrew on OSX Lion for over a week now, with no luck. Other installs have been fine, what am I doing wrong please?
MacBookPro:Rails pingu$ brew install git
==> Downloading http://kernel.org/pub/software/scm/git/git-1.7.6.1.tar.bz2
curl: (22) The requested URL returned error: 503
Error: Failure while executing: /usr/bin/curl -f#LA Homebrew\ 0.8\ (Ruby\ 1.8.7-249;\ Mac\ OS\ X\ 10.7) http://kernel.org/pub/software/scm/git/git-1.7.6.1.tar.bz2 -o /Users/pingu/Library/Caches/Homebrew/git-1.7.6.1.tar.bz2
If you follow the link that 'brew install git' spits out - you will find that the website is "Down for maintenance". That's why it is not working!
A clever SO'er found the solution to this problem by using a mirror for the tar. You can read his instructions in this answer
If you go to the URL yourself you will notice the huge Maintenance warning. This is probably connected with the recent security breach on kernel.org.
Just try again later when the kernel.org admins are sure that the systems are save.
It is worth keeping a chart of the major status codes, handy. A good source is https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
404's are well known enough, but the 500 series, as indicated, reflect a server problem. Good web developers should also be looking at their logs, and if, for example, they are getting regular hits from a link to a location that they now no longer use, they should return a '301' (Moved Permanently), which may trigger the referring linker to update their link (or not).

Resources