This is super easy, just press the ‘Windows’ key (flag) and the ‘Full Stop’ key (.) on your keyboard at the same time to pop-up the emoji selector.
After all these years, I just found this feature! It was mentioned in a VSCode YouTube tutorial that I watched yesterday.
Assuming that your Django container is already running under Docker, find out what it’s ‘Container ID’ is.
$ docker ps CONTAINER ID IMAGE ... fb3aabc8e123 django-web ...
In the above example the Container ID is fb3aabc8e123.
Now you can easily execute commands inside that container.
$ docker exec -it fb3aabc8e123 sh
The ‘-it’ option executes the command in an Interactive Terminal.
The ‘sh’ at the end of the command is the program to run, in this case it the system shell program. You could use ‘bash’ on a Linux machine if that’s your preference.
Now that you have a shell running in the Django container, you can run the command to create the admin user account.
# python ./manage.py createsuperuser
The easiest way to have Django run a migration inside a Docker container is to get Docker to run a new container to perform the task.
Using ‘run’ instead of ‘exec’ works if there is a start-up script like entrypoint.sh that prevents the container from starting until the migration has been completed (egg-chicken-egg).
E.g. I have a Django app called ‘web’ defined in docker-compose.yml , my terminal’s current working directory is the Django container folder where manage.py is resident.
$ docker compose run web ./manage.py migrate
This probably works similarly with Podman, I just haven’t tried it yet to verify.
I noticed today that the FreeBSD ZFS pool that I created on my laptop SSD was not configured for TRIM. TRIM enables the SSD to recover space from previously written to blocks that have since had files deleted. This can help maintain performance of the SSD as it fills with data.
My pool is called zroot, so the command to check the value of the TRIM setting is:
$ zpool get autotrim zroot
The command to switch on automatic TRIM is:
$ zpool set autotrim=on zroot
Originally written in 2018. This post has been languishing in drafts for a couple of years. I may complete it someday.
I acquired three old Netgear GSM7224 switches for my lab network some time ago and I pulled them off the shelf recently to use in a project I am currently working on. I wish I had actually checked them out fully when I first acquired them because it has cost me a week or so in time to get them useable in a reasonably secure test network. I did not anticipate the problems getting older high-end Netgear products to work securely in a network environment with up to date patched hosts.
If you are trying to make use of ageing Netgear GSM7224 Gigabit Ethernet Managed Switches you may find this article useful. Some of this may even be relevant to other network equipment running similar firmware Eg. Sun Netra.
I spent a little time getting familiar with one of the switches on my bench. I used a laptop running Ubuntu 18.04 with a USB Serial adapter and a 9-pin null modem serial cable connected to the switch’s console port on the front panel. As these were second hand switches I didn’t have knowledge of the existing admin password. Resetting the password was at the top of the task list but until then it was time to do some basic surveilance on the switch using nmap. These are my initial observations.
All three of my switches had noisy fans. Each has two 40x40x10mm 5VDC 2-pin fans inside and one in each had partially seized which was causing a lot of noise.
Opening the case was just a bit of screwdriver work to remove the rack mounting ears and then the screws holding the case together. All of the externally visible screws have to be removed to open the case. The cover slides of rearwards with a slight upward tilt. Once inside I could see the fans that need replacing.
I opted for cheap replacement fans sourced from eBay but I probably should have put more thought into that decision at the time. Within a few months the replacement fans started getting noisy.
I connected a 9-pin null modem serial cable that I use for console access to the switch and to a USB serial adapter plugged into my laptop.
I use Minicom as a terminal emulator to access my switch consoles. Ctrl-A in Minicom gains access to its configuration menu. The connection was configured for /dev/ttyUSB0 at 9600,n,8,1. After saving the settings the switch console login prompt appeared.
My Netgear switches were all purchased used without documentation or being reset to factory defaults. I tried logging in as admin with various popular passwords without luck. Fortunately, rebooting the switches with Minicom still connected and running reveals a boot menu. Select option 2 to access a configuration menu. From here the switch can be reset to factory defaults without needing a password.
I downloaded the ‘latest’ firmware from Netgear and setup a TFTP server on my laptop to serve the new firmware image. The firmware’s README describes the process to upgrade and although it takes a while silently updating there is eventually some confirmation on screen and the job is done.
I was having problem getting the SNTP client to synchronise time with the NTP servers that I had specified to use. That was until I tried this configuration command that worked…
(GSM7224) (config)# sntp client mode unicast
I also had some problems getting recent SSH clients to work. PuTTY on a Windows machine was useful as is still support SSH v1.
Port scanning the switch revealed that tcp 4242 appears to be used by the switch’s Java client interface. As I am not using the Java client it can be closed using:
no ip http java
More to follow…
I never expected that I would upgrade one of my elderly Dell GX240 PCs again, but today I did. I have two GX240 tower PCs. One of them has been used as a firewall for five years, the other as it’s fallback spare. I retired both of them a few weeks ago, replacing them with Dell PowerEdge 840 servers. Yes, they are old too, but not as old as the GX240.
I have been planning to upgrade my parent’s firewall with a PowerEdge 840 but I’m working on a project at the moment and can’t really spare one of my modified super quiet ones. I had a job lot of old CPUs arrive today and an intel SL7EY was in the bundle. I soon realized that this was the high end processor for the GX240 and quickly decided that perhaps a GX240 would go on for a bit longer at my parents house.
I stripped down both GX240s and rebuilt one using the best bits from each. I will save the other for spares and scrap them both eventually but for now the best of them gets a 2.8Ghz Pentium 4 with 512KB cache. To my dissapointment, a very large number of the new processor’s pins were bent. It took about an hour or so of work with a magnifying glass and craft knife to carefully straighten them enough for the socket to accept the processor. The PC was booted up with the new CPU and it was correctly recognised in the BIOS setup. A successful upgrade!
The 2.6Ghz Celeron has performed really well and I’m interested to see if the additional 200 Mhz and 384KB of cache that the 2.8Ghz Pentium 4 has make a noticeable difference. I didn’t take any benchmarks before and after, this was just a case of making use of a surprise ‘windfall’. I’m not expecting anything as amazing as the last processor upgrade but I think it was worthwhile doing.
I have just acquired a used 4-port D-Link fast ethernet PCI board from a seller on eBay. I have been looking for one of these for my ‘new’ firewall for ages and was about to give up.
The firewall is an old crate of a Dell GX240 with PCI slots but it still has plenty of grunt to do what I need without consuming too much power. It’s one of the old Dells that I bought years ago for peanuts that has been upgraded with a 2.6Ghz Celeron.
I have been experienting with a Broadcom crypto accelerator in pfSense and I was about to give up on the GX240 and move up to a newer old machine with PCI-X slots.
The BCM5821 already delivers 24x performance improvent on 2048 bit RSA in the 33Mhz PCI bus and I am intrigued to find out how fast it will go in a 64 bit, 66Mhz slot. Now that I have the D-Link, I will crack on with the original plan and save the PCI-X upgrade for later.
More to follow…
WARNING: This article relates to the dropbear package version 2012.55 and not the updated package 2012.55-1 that now includes the ability to login with keys. It is no longer necessary to use these instructions to modify the dropbear installation on your FOXSAT-HDR. The instructions on how to generate and distribute client keys are still valid.
I have just upgraded the functionality of my Humax FOXSAT-HDR with some custom firmware. The new firmware came with Telnet active but I prefer to use SSH with RSA or DSA keys. Dropbear is the installable package that provides SSH for the custom firmware but I couldn’t find any documentation with the firmware that explained how to get it working with client keys.
Following an evening of research and experimentation, I found a way of getting it to work. Ubuntu/Linux/BSD users can use this process to configure Dropbear on the FOXSAT-HDR to use SSH authorized_keys instead of passwords. I worked around the read-only file system by changing the root account home directory to /tmp.
Install Dropbear on your custom firmware FOXSAT-HDR using opkg or the web interface. Test that it works using a password. Dropbox appears to be configured to use only the root account. From my Ubuntu machine I login from a terminal session using:-
ssh root@foxsat-hdr
When you are happy it is working OK. Open another terminal session and create a DSA public key file on your Ubuntu PC. The file will be ~/.ssh/id_dsa.pub
cd
cd .ssh
ssh-keygen -t dsa
ls
Copy the key(s) to the FOXSAT-HDR. You may already have a public RSA key present in the .ssh folder.
scp id_*.pub root@foxsat-hdr:/tmp
If you are not already logged in to the FOXSAT-HDR via SSH, do so now to create the two authorized_keys files required.
cd /opt/etc
mkdir .ssh
chmod 700 .ssh
cd .ssh
cat /tmp/id_*.pub >> authorized_keys
chmod 600 authorized_keys
ln -s /opt/etc/.ssh/authorized_keys /opt/etc/.ssh/authorized_keys2
Create an init.d script to fix the keys on startup. The root account will have it’s home directory moved to /tmp so that the hidden key folder can be found in there. The ‘echo’ command line is quite long and ends in ‘fix’, it is not two lines.
echo -e "#!/bin/sh\n\nln -s /opt/etc/.ssh /tmp/.ssh">/opt/etc/init.d/S55sshpubkeyfix
chmod 755 /opt/etc/init.d/S55sshpubkeyfix
Now edit the password file using vi to change the root account home directory from ‘/’ to ‘/tmp’. If you don’t know how to use vi, read this first. Otherwise, here is a command list to refresh your memory.
cp /opt/etc/passwd /opt/etc/passwd.old
vi /opt/etc/passwd
When you have saved the file. Check it, then reboot if it is good.
cat /opt/etc/passwd
reboot
Your FOXSAT-HDR will reboot and you should be able to login using SSH. This time switch on debugging to check the authentication sequence during login. If it works, you will not have to use a password to establish a secure shell.
ssh -vv root@foxsat-hdr
Telnet can be deactivated using ‘Service Management’ in the web interface.
If you want to use SSH from another Ubuntu PC it is easy to copy its DSA client key to the FOXSAT-HDR now that the authorized_keys file has been created.
ssh-keygen -t dsa
ssh-copy-id root@foxsat-hdr
This could be incorporated into the Dropbear package if the maintainer emptied the authorized_keys file (zero length) before sealing the package file. Users would then only need to use ssh-keygen and ssh-copy-id to make use of the additional security.
I have been using my Humax FOXSAT-HDR since I bought it new in 2009 and functionally it hasn’t changed much bar the addition of BBC and ITV catch-up TV services. I have always hoped that the manufacturer would issue a DLNA server upgrade to the firmware, but it never came. That is until today…
While searching the internet to find if the Freesat+ YouTube player was available for the FOXSAT-HDR, I found a custom firmware distribution that has been in development and use for some years that could be used to provide web access and DLNA services.
There is no dedicated website for the firmware but it appears the www.avforums.com is the place to go for community support and the latest downloads.
The version that I downloaded and installed was v4.1.1 . It came in a RAR file that I decompressed into a folder on one of my Ubuntu machines. I copied the files to a 1.1GB USB stick formatted FAT32 as advised in the README but it wouldn’t boot the new firmware installer. I found another stick that was 985MB when formatted and it worked perfectly. The installation was exactly as described in the instructions and when the FOXSAT-HDR rebooted there was no visible change other than the firmware version being displayed on the front panel during boot up.
Pointing a web browser at the box, I continued to install the full web interface. When complete I could see that the DLNA server was an installable package but I couldn’t get the package list to update from the web interface. No problem, I telneted into the box and used the command line instead.
opkg update
opkg list
opkg install dropbear
I installed dropbear so that I could deactivate Telnet and use SSH instead. More on this later.
After installing dropbear via the command line the web interface tabs for ‘Installed’, ‘Available’ and ‘Upgrades’ worked but the main ‘Update package list from internet’ still doesn’t work from the web interface.
I am currently experimenting with MediaTomb uPNP to serve recordings to my son’s PS3 but I think I will try the TwonkyMedia 5 DLNA server as originally planned. Twonky charge 15 Euros for the licence activation but I guess it’s probably worth it.
If you wish to rollback to the original firmware, you will need an installable image of it. I found one that I could download v1.00.21 from here.
3 May 2015
I should have updated this a long time ago as I have since upgraded my Foxsat-HDR to v4.1.2 and then on to v4.1.3
I am really impressed with the current version. Everything works well as flashed and with the addition of some of my own custom modifications to get it working with my WDTV-Live box.