I'm behind a firewall and I have the fzf.tar.gz package which has the content of the git repo. How can I install fzf offline?
The install command ~/.fzf/install is reaching out to github.com. I'm on Redhat with no internet connection.
https://github.com/junegunn/fzf
This is just what I observed, I can't guarantee I didn't miss anything:
First, clone fzf to FZF_DIR on an online PC, then,
I'd suggest you to execute 'install' on an online PC to get necessary files
~/.fzf/bin/fzf this one is downloaded by install script
~/.fzf.bash this one is generated by install script
cp ~/.fzf/bin/fzf $FZF_DIR/bin
copy $FZF_DIR (with fzf binary in it) and .fzf.bash into your offline PC
ln -s $FZF_DIR ~/.fzf
source .fzf.bash in your .bashrc
Entire FZF_DIR is needed because it includes some other useful scripts sourced by .fzf.bash.
Related
Is there a way to use the VSCode Remote SSH extension to interact with a remote host that does not allow outbound internet connections?
Is it possible to download the vscode-server files from another system and copy to host?
I read this but I can't connect the server to internet.
When you connect to a host it executes a bash script that wgets or curls a tarball and extracts it in a directory in your home directory. Here's an offline workaround.
Attempt to connect, let it fail
On server, get the commit id
$ ls ~/.vscode-server/bin
553cfb2c2205db5f15f3ee8395bbd5cf066d357d
Download tarball replacing $COMMIT_ID with the the commit number from the previous step
For Stable Version
https://update.code.visualstudio.com/commit:$COMMIT_ID/server-linux-x64/stable
For Insider Version
https://update.code.visualstudio.com/commit:$COMMIT_ID/server-linux-x64/insider
Move tarball to ~/.vscode-server/bin/$COMMIT_ID/vscode-server-linux-x64.tar.gz
Extract tarball in this directory
$ cd ~/.vscode-server/bin/$COMMIT_ID
$ tar -xvzf vscode-server-linux-x64.tar.gz --strip-components 1
Connect again
You'll still need to install any extensions manually. There's a download button next to all the extensions in the marketplace. Once you have the .vsix file you can install them through the GUI with the Install from VSIX option in the extensions manager.
This is kind of a pain and hopefully they improve this process, but if you have a network-based home directory, you only have to do this once.
open vscode -> about
Version: 1.46.1
Commit: cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
Date: 2020-06-17T21:17:14.222Z
Electron: 7.3.1
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 17.7.0
$COMMIT_ID = cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
A new feature is being added to support offline install
However, you can now solve this issue by a new user setting in the Remote - SSH extension. If you enable the setting remote.SSH.allowLocalServerDownload, the extension will install the VS Code Server on the client first and then copy it over to the server via SCP.
Note: This is currently an experimental feature but will be turned on by default in the next release
https://code.visualstudio.com/blogs/2019/10/03/remote-ssh-tips-and-tricks
A a work around I have done the following:
Desktop ~/.ssh/config
...
Host *
RemoteForward 54321
...
Remote: ~/bin/wget in which ~/bin is added to PATH via .bashrc
#!/bin/bash
export LD_LIBRARY_PATH=$HOME/opt/lib/tsocks/
export TSOCKS_CONF_FILE=$HOME/opt/tsocks/tsocks.conf
$HOME/bin/tsocks /usr/bin/wget $#
Remote: ~/opt/tsocks/tsocks.conf
server = 127.0.0.1
server_port = 54321
server_type = 5
note tsocks binary has been scp-ed to ~/bin/tsocks and ~/opt/tsocks/ has been created with libtsocks.so which is normally stored in /usr/lib64/libtsocks.so
This is a work around that allows me to have wget functionality with out messing with anything outside my profile to get it to work (eg: no root required ... even though I have it).
Current Version of VS Code: 1.48.2
I just kill the wget process on the server end, and let the client download the archive and transfer it to the server end. That's quite easy as below.
make sure that you set in settings.json
"remote.SSH.allowLocalServerDownload": true,
execute the shell scrpits below.
# to find the <pid>
ps aux | grep wget | grep vscode-server
# kill the process
kill -9 <pid>
# then wait for the client downloading and transferring
# optional: If you want to know the progress, just
cd ~/.vscode-server/bin/<commit-id>/
watch -n 1 -d ls -rthl
Is it possible to generate a .hex file with MicroPython and my own python program code at a Linux command line, rather than in one of the editors?
Looking at the tag in your question, it looks like you want to use MicroPython on the BBC micro:bit, correct?
If that's the case then youu can use this Python command line tool: https://github.com/ntoll/uflash/
Instructions on how to install it and use it can be found in the README at that link.
This works with Python 2 and 3, and your Linux distribution is very likely to have at least one Python version available out-of-the-box.
If you have pip installed you can easily install it with: pip install uflash
But you can also download the source code, using git or downloading a zip file from GitHub (https://github.com/ntoll/uflash/archive/master.zip), and run it without installing anything. In this case you can execute the uFlash script with Python:
python uflash.py path_to_your_code.py
And the current version of uFlash includes the latest version of MicroPython for the micro:bit.
You can write the micropython code for the microbit in any text editor, such as vscode or vim. Save it as a .py file.
To create the .hex file, use the py2exe tool that is installed along with uflash when you install uflash using the command:
pip install uflash
To create a .hex file for a microbit micropython file called hello.py:
py2hex hello.py
This creates a file called hello.hex. This can be dragged and dropped onto your connected microbit through the file explorer. I use Nautilus and the microbit appears as 'MICROBIT'.
You can automate the creation and loading of the .hex file to the microbit using uflash, e.g.
uflash hello.py
This will create the .hex file and then load it onto an attached microbit. The .hex file will not be left on your file system though. The microbit has a habit of no longer being attached to the file system after loading a .hex file and needs to be re-attached in between builds.
Working Ubuntu 22.04 host CLI setup with Carlos Atencio's Docker to build your own firmware
After trying to setup the toolchain for a while, I finally decided to Google for a Docker image with the toolchain, and found https://github.com/carlosperate/docker-microbit-toolchain at this commit from Carlos Atencio, a Micro:Bit foundation employee, and that just absolutely worked:
# Get examples.
git clone https://github.com/bbcmicrobit/micropython
cd micropython
git checkout 7fc33d13b31a915cbe90dc5d515c6337b5fa1660
# Get Docker image.
docker pull ghcr.io/carlosperate/microbit-toolchain:latest
# Build setup to be run once.
docker run -v $(pwd):/home --rm ghcr.io/carlosperate/microbit-toolchain:latest yt target bbc-microbit-classic-gcc-nosd#https://github.com/lancaster-university/yotta-target-bbc-microbit-classic-gcc-nosd
docker run -v $(pwd):/home --rm ghcr.io/carlosperate/microbit-toolchain:latest make all
sudo chmod -R +666 .
# Build one example.
tools/makecombinedhex.py build/firmware.hex examples/counter.py -o build/counter.hex
# Build all examples.
for f in examples/*; do b="$(basename "$f")"; echo $b; tools/makecombinedhex.py build/firmware.hex "$f" -o "build/${b%.py}.hex"; done
And you can then flash the example you want to run with:
cp build/counter.hex "/media/$USER/MICROBIT/"
What uflash does it to ship its own precompiled firmware.hex which is the part that requires the toolchain, and it then just uses that to build the combined hex in Python.
The cool thing is that now that we have the toolchain, we can also create examples directy in C/C++/assembly: How to compile C/C++ code into a .hex file for the BBC micro:bit? which can likely run much faster.
Previous failed attempts at setting it up myself
The Yotta package manager used by BBC Microbit bit rot almost immediately after it got was discontinued, making pip install yota approaches like: https://flames-of-code.netlify.app/blog/microbit-cpp-1/ very difficult.
The GCC gcc-arm-embedded toolchain PPA ppa:team-gcc-arm-embedded/ppa has also been discontinued: https://askubuntu.com/questions/1243252/how-to-install-arm-none-eabi-gdb-on-ubuntu-20-04-lts-focal-fossa and now you would have to download from an arm.com website.
Atencios' Docker setup explains how to do it though: https://github.com/carlosperate/docker-microbit-toolchain/blob/master/Dockerfile , the key is likely using his magically crafted requirements.txt, likely kept back from the day when things really worked, to avoid the infinitely many dependency issues of yotta. He's on Ubuntu 20.04.
When sharing a git repo between wsl on windows10 and any linux, all files added/changed from wsl get the rw-rw-rw attributes, even if I explicitly do a chmod ug+x file.py before adding. If You do a ls -l in wsl all files are listed with rwxrwxrwx no matter what.
On linux I have to do a find . -name "*.py" -exec chmod ug+x {} \; on every pull/clone
What is the best way to fix this? Are there some settings in WSL? git hooks?
I assume your git repo is somewhere in the windows file system, i.e. in /mnt/c/path/to/git. In this case WSL sets all permissions in order
to best reflect the Windows permissions. (FAQ)
There is currently no way in the stable build to change this behavior. But with
the insider build 17063 the WSL team face this by implementing DrvFs support, which
allows setting the owner and mode of files using chmod/chown, and also
the creation of special files such as fifos, unix sockets and device
files. (Release Notes)
I need to install mbstring (and a few other extensions) for PHP on Cloudbees. Is this possible?
Note that I'm using an updated PHP version as described here:
https://developer.cloudbees.com/bin/view/DEV/PHP+Builds
I don't think scripts have sudo access, so I can't simply use the package manager. I don't think these extensions exist as PEAR packages either. So I'm stumped.
Here is the response from Cloudbees support. Seems to work fine, just make sure you don't have any spaces in your Jenkins build path!
Our provided PHP versions don't have mbstring module activated. You will need to build your own PHP version to get it. To be sure your custom PHP build works on Cloudbees slave, you can build it with a Jenkins job on your instance (with various --with-XXX or --without-XXX options).
We are ourselves doing something like this with a script like
# Download
regex='.*(RC|alpha|beta).*'
if [[ $version =~ $regex ]]; then
wget http://downloads.php.net/dsp/php-${version}.tar.bz2
else
wget http://us3.php.net/distributions/php-${version}.tar.bz2
fi
# Unpack
tar xjf php-${version}.tar.bz2
# Build
cd php-${version}
./configure --prefix=/home/jenkins/tools/php/${php_name} \
--with-curl --with-openssl
make && make install
As a side node, you should also take care of specifying a good installation prefix with --prefix. I would choose something like /home/jenkins/tools/php/5.4/.
To store compiled php engine you could generate a tar.gz//bz2 file of target installation directory. Then, store it in your WebDAV directory, which is accessible in /private/{account}/ during a build when "Mount CloudBees DEV#cloud Private WebDav Repository" is checked.
You should add a first step to jobs requiring PHP to extract this archive. As Jenkins workspace is usually cached on DEV#Cloud, you can extract the archive only if it's not already there. That will speed up your build.
I've created a local yum repository for RHEL 7 on a separate server. Then I used the "reposync" command to get the packages from RHN.
reposync --download-metadata --gpgcheck -l --repoid=rhui-REGION-rhel-server-rh-common --download_path=/rhel_security_repo/
reposync --download-metadata --gpgcheck -l --repoid=rhui-REGION-rhel-server-optional --download_path=/rhel_security_repo/
reposync --download-metadata --gpgcheck -l --repoid=rhui-REGION-rhel-server-releases --download_path=/rhel_security_repo/
After that, I executed the following command to create my repo:
createrepo --database /rhel_security_repo/
The repository was created successfully with over than 9000 packages as expected. What I am trying to do now is to have other boxes using this local repository. I've created a yum config file in the other boxes where the baseurl points to this server with the local yum repository.
[security-updates-rhel7]
name=Repository for RHEL7 security updates
baseurl=ip-server
enabled=1
gpgcheck=1
All the servers are able to talk to this server with the local yum repo and they can install packages from it.
The problem is I can't update packages when I run yum update --security:
Example:
yum --disablerepo="*" --enablerepo="security-updates-rhel7" --security update mariadb-libs
Loaded plugins: amazon-id, rhui-lb
--> 1:mariadb-libs-5.5.37-1.el7_0.x86_64 from #rhui-REGION-rhel-server-releases removed (updateinfo)
--> 1:mariadb-libs-5.5.40-2.el7_0.x86_64 from security-updates-rhel7 removed (updateinfo)
No packages needed for security; 1 packages available
Resolving Dependencies
However, if I run the command without --security, I can see available updates:
yum --disablerepo="*" --enablerepo="security-updates-rhel7" update mariadb-libs
Loaded plugins: amazon-id, rhui-lb
Resolving Dependencies
--> Running transaction check
---> Package mariadb-libs.x86_64 1:5.5.37-1.el7_0 will be updated
---> Package mariadb-libs.x86_64 1:5.5.40-2.el7_0 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
==============================================================================================================================
Package Arch Version Repository Size
==============================================================================================================================
Updating:
mariadb-libs x86_64 1:5.5.40-2.el7_0 security-updates-rhel7 753 k
Transaction Summary
==============================================================================================================================
Upgrade 1 Package
Total download size: 753 k
Is this ok [y/d/N]:
It seems I lost the security metadata when I did the reposync.
Any ideas what the problem could be?
Etan has the right idea; those are the two ways we found to get around the issue with RHEL6. You could pull the Redhat metadata straight out of your yum cache and copy it into your local repo, and that works 90% of the time... but 10% it will give you random failures if Redhat happens to be updating a repository while you are syncing it.
Redhat has a guide for how to graft security metadata into your local repo in RHEL5/6, I assume it works similarly in RHEL7. If you have a Redhat Support account, see: https://access.redhat.com/solutions/55654
If you don't, below is my own take on it:
Run your reposync command with --download-metadata and other trimmings, but I would start with one repo at a time and put each one in it's own directory similar to how Redhat does it. ex. mkdir -p /path/to/repo-id && reposync -l -n --download-metadata -r repo-id -p /path/to/repo-id/.
Pull the abcdefghij-updateinfo.xml.gz metadata files from Redhat, which contains security metadata for each repository. Do this by running yum list-sec and then look for it in your local yum cache, under each repository's subdirectory. Probably somewhere in /var/cache/yum/arch/7Server/repo-id.
Run createrepo on just that repository. createrepo -v /path/to/repo-id/
Go into /path/to/repo-id/ and then into the repodata subfolder. Copy in the abcdefghij-updateinfo.xml.gz from your local yum cache into the repodata folder, but rename it to remove the hash at the beginning. Left with a file called updateinfo.xml.gz
Use the modifyrepo command to insert the security metadata into that repo's table of contents (repomd.xml) file.
modifyrepo /path/to/repo-id/updateinfo.xml.gz /path/to/repo-id/