I downloaded Cinnarch and have it running on a virtual machine. I tried to install Self, only to find that it was already installed. So I tried playing around with it, but there's a problem. Numbers, strings, etc. work, but I can't send any messages. I can't add 1 + 1. The only advancedish thing I've been able to accomplish is make new objects. What can I do to get my Self system fully working?
Self is similar to Smalltalk in that you need both a virtual machine, and the default distribution of objects. There are a very small number of default primitive methods, and a parser built into the VM itself to help bootstrapping. You need to get the Self equivalent of the standard library/environment.
You can either:
go to http://selflanguage.org/download/index.html and download a .snap file, then start it by running Self -s filename.snap A snapshot is a frozen collection of objects like a Smalltalk image file.
Clone the sources from https://github.com/russellallen/self, cd into the objects directory and run Self -f worldBuilder.self This will build the default snapshot from source. If you want to open a GUI development environment, do 'desktop open'.
Either way should get you to a prompt which gives the right answer to 3 + 4.
Related
Thank you for taking the time to read this. I am trying to complete a Lab for one of my classes and I am having an issues creating a new Metasploitable VM. I introduced an error when editing a file in the last one and had to delete it.
I am using a VMDK, obtained from SourceForge. The first machine installed with no issues. When trying to create a second machine I continually get "Can't overwrite medium..." comment when finishing the set-up.
So far I have tried:
Checking the destination folder for any existing files and folders (hidden too).
Redownloading Metasploitable
Assigning a new name to the VM, using different specs, etc.
Restarting my PC.
What I don't understand is that the error is stating, if I am not mistaken, that it is trying to overwrite the VMDK in my downloads file... when I am trying to save it in c:\Users\natsu\VirtualBox VMs. I have triple checked all fields before running the installer. I do not understand why this is happening, considering the first Metasploitable machine I had installed with absolutely no issues.
]
I have designed a GUI that I want to run as soon as I turn on my Raspberry Pi. It is currently set up to automatically log in as user on startup, but if that makes the process more difficult I can change that. My Raspi runs on Raspbian 10 (buster), which has made things difficult since I can only find tutorials for Raspbian 8 or so.
I have tried modifying autostart folder, but it is not in the same location as it was in previous Raspbian versions and doesn't seem to be working the way it used to. Tutorials have said to create a .desktop file in /home/pi/.config/autostart but I don't have a .config folder, or at least it's hidden. For me, autostart is in /etc/xdg/autostart and when I try to create a new file here using nano in the terminal, I get the message [Directory '/etc/xdg/autostart' is not writable] and it doesn't save my file.
I have also tried calling my script in /etc/rc.local but it did nothing. Some have said it doesn't work for GUIs.
Here's what I type into terminal:
$ nano /etc/xdg/autostart/gui.desktop
and a new file pops up, but at the bottom I get the warning [Directory '/etc/xdg/autostart' is not writable]
How can I get my GUI script to run on startup with Raspbian 10 (buster)?
There are a number of issues here, first when you are looking at tutorials recognize that Linux distros are built in layers, for simplicity let's say your "layer stack" looks like this: kernel, systemd, x11, xdg, lxde. The kernel boots, then starts systemd, which then starts x11 (and a lot of other stuff), x11 starts xdg (and some other stuff, I think), lxde is started by either x11 or xdg I'm not sure which.
You want to add something to this process, you can do it at the kernel level (bad idea), at they systemd level (probably not right unless its a daemon), at the x11 level (still probably bad as you still don't have a user session yet), or at the xdg or lxde level.
xdg is probably the right place as it has all you need ( a gui, a user session) while being common (xdg will still work if you switch window managers, probably)
With that out of the way, why isn't your solution of modifying xdg working? It's because '/etc/xdg/autostart' is a system configuration directory. Any changes made to it will apply to all users. You may want this, but the system is trying to protect other users on your system and only allows root to make changes to everyone. If you want to do that use "sudo" (documented elsewhere on stack exchange and the internet). If you want to do it just for you use ~/.config/autostart, (https://wiki.archlinux.org/index.php/XDG_Autostart) you might need to create that directory with "mkdir ~/.config/" and then "emacs ~/.config/autostart"
Would it be better to have the python program run in a terminal window from startup? That way you would see what it is doing in case of errors.
If so, perhaps check this out https://stackoverflow.com/a/61730679/7575617
By the way, in the file manager, hit CTRL+H to toggle viewing hidden files and folders.
I am trying to diagnose a few issues with ssl connectivity with Leingen. I am trying to find what SSL Key Store and Trust Store is being Used by Leingen,
I am behind a corporate firewall and we have self signed certificates deployed on all our desktops . I am running lein.bat on a windows 10.
Hence I have to start Leingen with java -Djavax.net.debug=true option.
The :jvm-opts in the project.clj wont work -- I need to make sure the Liengen's JVM is started with this option
You can set leiningen JVM options by setting LEIN_JVM_OPTS environment variable before running lein in the same terminal session.
The lein command is just a shell script which eventually invokes java with various options. You can edit this script to see what options are used and/or to modify them.
As Piotrek mentioned, the LEIN_JVM_OPTS environment variable is the canonical way of passing options to the jvm in which lein runs. You can see it used on line 372 of the source code.
For your case:
> export LEIN_JVM_OPTS='-Djavax.net.debug=true'
> lein clean
> lein run
Since you're running windows, you'll want to actually look at the lein.bat file. You'll still need to update LEIN_JVM_OPTS, but how you go about it will be a bit different. If you're using windows command terminal (cmd.exe) you will want to use the set command.
set LEIN_JVM_OPTS="-Djavax.net.debug=true"
The command is likely different if you're using powershell, and you can likely find out how to set that on this page on environment variables.
I can't seem to ssh into any instances that are created from a snapshot of an openSUSE instance that's created within Google Cloud (ie: not from a snapshot created locally and then uploaded). I've tested this with three different openSUSE instances, 2 that I had been working on and one that I created only to test this on, and none have been able to produce snapshots that produce instances that allow ssh. To be clear, the instances created from the snapshots start up perfectly fine and show no issues from the console, but neither the console's built in ssh nor any other ssh client (putty, mobaxterm) gets anything more than a time out error. I have successfully created instances from both a Windows and Debian snapshots that I have created myself, so I'm confident it's an issue with the specific OS.
Steps to reproduce:
Create an instance based off of the openSUSE image
Create a snapshot based off of the instance you just created
Create an instance based off of the snapshot you just created
Attempt, and fail, to connect to the instance via ssh
Any help with this would be much appreciated, and thank you very much in advance.
I was able to reproduce your issue. I'll report it to Google. If your run the command
gcloud compute instances get-serial-port-output <your-new-instance>
You will notice that there's an error indicating that couldn't find the disk.
SUSE has fixed the issue yesterday on SLES distros. The following new images are now available (bug-exempt):
sles-11-sp3-v20150310
sles-12-v20150310
We are still working on a fix to openSUSE, and we still don't have a fix for existing instances.
A procedure to address running instances has been posted:
https://forums.suse.com/showthread.php?6142-Image-from-snapshot-will-not-boot&p=26957#post26957
The above post contains all the details, the procedure below addresses the question about "what to do with running instances."
SUSE Linux Enterprise Server 11 SP3 (sles-11-sp3)
1.) Edit /etc/sysconfig/bootloader
In the "DEFAULT_APPEND" assignment replace "root=/dev/disk/by-id.." with "root=/dev/sda1". Reform the same substitution for the "FAILSAFE_APPEND" assignment.
Add NON_PERSISTENT_DEVICE_NAMES=1 to the end of the line, after "quiet"
2.) Edit /etc/fstab
Replace "/dev/disk/by-id..." with "/dev/sda1"
3.) Edit /boot/menu.lst
Replace "root=/dev/disk/by-id.." with "root=/dev/sda1" and "disk=/dev/disk/by-id/..." with "disk=/dev/sda" in both options.
Add NON_PERSISTENT_DEVICE_NAMES=1 to the end of the line starting with "kernel"
4.) Reboot the instance
5.) Execute mkinitrd
6.) Edit /etc/udev/rules.d/70-persistent-net.rules (if it exists)
Remove the mac address condition, "ATTR{address}==.....", from the rules.
SUSE Linux Enterprise Server 12 (sles-12)
1.) Edit /etc/sysconfig/bootloader
In the "DEFAULT_APPEND" assignment replace "root=/dev/disk/by-id.." with "root=/dev/sda1" and "disk=/dev/disk/by-id/..." with "disk=/dev/sda". Perform the same substitution for the "FAILSAFE_APPEND" assignment.
Add NON_PERSISTENT_DEVICE_NAMES=1 to the end of the line, after "quiet"
2.) Edit /etc/fstab
Replace "/dev/disk/by-id..." with "/dev/sda1"
3.) Edit /etc/default/grub
In the "GRUB_CMDLINE_LINUX_DEFAULT" assignment replace "root=/dev/disk/by-id.." with "root=/dev/sda1" and "disk=/dev/disk/by-id/..." with "disk=/dev/sda".
Add NON_PERSISTENT_DEVICE_NAMES=1 to the end of the line, after "quiet"
4.) Create a new grub configuration (SLES 12)
export GRUB_DISABLE_LINUX_UUID=true
grub2-mkconfig > /boot/grub2/grub.cfg
5.) Execute mkinitrd
6.) Edit /etc/udev/rules.d/70-persistent-net.rules (if it exists)
Remove the mac address condition, "ATTR{address}==.....", from the rules.
A new openSUSE 13.2 image has been published that addresses the issue as well. New instances started from opensuse-13-2-v20150315 will work with no issues with the snapshot feature in GCE. For running instances use the process outlined for SUSE Linux Enterprise 12, that should work. I did not test the procedure on openSUSE.
I have access to a remote Solaris terminal which crashes occasionally, and I have to ask someone with physical access to boot the machine up, which it does successfully. I would like to know which tools/files should I look at to find out the cause of the crash so that I can make the necessary configuration changes and avoid it in the future.
What tools you can use will depend on what version of solaris you have running and what the actual problem
is. The first thing to do is check the system console (which it sounds like you don't have access to) and the /var/adm/messages file. This file is updated with system messages and the newest will appear at the end.
Next, you can look for a system core file. If a core file is created, it would be in /var/crash/hostname where "hostname" is the name of the machine.
If you have an actual core file in the /var/crash/hostname directory, this set of commands will give you a good
string to search google with:
# cd /var/crash/hostname
Replace "hostname" with the hostname of your machine.
# mdb -k unix.0 vmcore.0
If you have multiple core files, select the most recent version.
> ::status
This should give you a panic message, cut and paste that into google and see what you can find.
For more core file analysis read this:
http://cuddletech.com/blog/pivot/entry.php?id=965