configure_app() {
rox -d "$QUICKAPPS_HOME"
rox -d "$DESKTOP_FILES_DIR"
Xdialog --title "$APPTITLE" --left --infobox "
${_M_13:-Two folders have been opened. One is the QuickApps folder, the other one is the "All applications folder".}
${_M_12:-You can identify them by looking at the window title. To add a shortcut, follow these three easy steps:}

1. ${_M_18:-Create a new folder in the QuickApps folder.}
`gettext "This new folder serves as 'Category' and will appear as a tab in the QuickApps."`

2. ${:M_:-From the 'All applications folder', select then drag and drop the applications you want
into the 'Category' folder you created in step 1. Choose 'Link' when asked.}

3. ${_M_21:-Repeat step 1 and 2 as necessary. When done, click $REBUILD_LINK on the QuickApps folder.}

${_M_11:-Your QuickApps is available from your HOME folder.}
" 0 0 90000
}

Thanks for all these. I'm looking at your changes and I have a few questions.
1. For package-manager - where can I find this "gettext.sh"?
2. For t12s quick-apps, how would translation be handled if in the future the application is modified (e.g. deletion of existing strings, addition of new strings (how do these ${M_xxx} gets generated), changes of existing strings)? Can mo-manager automatically re-create all these changes? I surely hope I don't have to look at them one by one?

2. For t12s quick-apps, how would translation be handled if in the future the application is modified (e.g. deletion of existing strings, addition of new strings (how do these ${M_xxx} gets generated), changes of existing strings)? Can mo-manager automatically re-create all these changes? I surely hope I don't have to look at them one by one?

The tricky part is t12s_xgettext which does that what xgettext does:
create a portable object template file for TEXTDOMAIN At least it tries to do so....
Some rules:
1- In one line of script only one ${_M_}
2- No {} inside ${_M_:-No curly bracket here}
3- No line breaks in ${_M_}, use very long lines, activate Document>Line Wrapping in geany
4 - reload translation file before any ${_M_n:-A $variable inside message}

Adding new message: use just: ${_M_:-new message}
t12s_xgettext will insert the ID number which can be
- an existing one if the message already exists in the TEXTDOMAIN
- or otherwise a new one (last highest number + 1)

Deleting a message: it will not appear in actual TEXDOMAIN.pot

Changing a message: Don't do it. Just remove the ID and change th text, e.g.:

Code:

#MESSAGE="${_M_4711:-Fatdog is just a fat dog}"
MESSAGE="${_M_:-Fatdog is my favorite operating system}"

Then the existing translation
(TEXTDOMAIN.po created by t12s_msgunfmt from translation file /usr/share/locales/<language>/TEXTDOMAIN)
is merged with the actual TEXTDOMAIN.pot by gettext tool msgmerge --no-fuzzy.

The translator will see
- the deleted message commented
- and the translation for new message - msgstr - empty
... almost no difference to working with gettext

Cheers!

I am going to change some of the other scripts to t12s method (using a shell script) maybe just for fun ...

Ah, yes, of course I was being stupid - I didn't check devx. Thanks! This will have to be moved from devx to the base sfs then.

Quote:
BTW, I had appended
Code:
# update database for locate
updatedb &
to /etc/rc.d/rc.local
but it did not work, my 1st try was:
Code:
# locate gettext.sh
locate: warning: database `/var/state/locatedb' is more than 8 days old (actual age is 21,6 days)
/aufs/devsave/bootupi18n/puppyrcd_i18n/usr/bin/gettext.sh
/aufs/devsave/dotpup_i18n/usr/bin/gettext.sh
/aufs/pup_ro10/usr/bin/gettext.sh
/usr/bin/gettext.sh
#
Should I better use $HOME/Startup for this?

Someone commented in earlier post that you need to create /var/state before running updatedb.

L18L wrote:
jamesbond wrote:
2. For t12s quick-apps, how would translation be handled if in the future the application is modified (e.g. deletion of existing strings, addition of new strings (how do these ${M_xxx} gets generated), changes of existing strings)? Can mo-manager automatically re-create all these changes? I surely hope I don't have to look at them one by one?

The tricky part is t12s_xgettext which does that what xgettext does:
create a portable object template file for TEXTDOMAIN At least it tries to do so....
Some rules:
1- In one line of script only one ${_M_}
2- No {} inside ${_M_:-No curly bracket here}
3- No line breaks in ${_M_}, use very long lines, activate Document>Line Wrapping in geany
4 - reload translation file before any ${_M_n:-A $variable inside message}

Adding new message: use just: ${_M_:-new message}
t12s_xgettext will insert the ID number which can be
- an existing one if the message already exists in the TEXTDOMAIN
- or otherwise a new one (last highest number + 1)

Deleting a message: it will not appear in actual TEXDOMAIN.pot

Changing a message: Don't do it. Just remove the ID and change th text, e.g.:
Code:
#MESSAGE="${_M_4711:-Fatdog is just a fat dog}"
MESSAGE="${_M_:-Fatdog is my favorite operating system}"

Then the existing translation
(TEXTDOMAIN.po created by t12s_msgunfmt from translation file /usr/share/locales/<language>/TEXTDOMAIN)
is merged with the actual TEXTDOMAIN.pot by gettext tool msgmerge --no-fuzzy.

The translator will see
- the deleted message commented
- and the translation for new message - msgstr - empty
... almost no difference to working with gettext

This sounds good. Where does these t12s tools are, I suppose they are not part of momanager? I can put them into devx if you like.
I have one more question - the POT file created by t12s, is it compatible with POT file created by the real msgformat? (I guess not ...)

I have reviewed package-manager's script, I think the gettext method shouldn't have any impact on performance (and if it does, we can always move the slowness outside of a loop). Before you go on commmitting more time on this, which way do you reckon you want to go - gettext of t12s? Speed-wise I think t12s is faster, but gettext is the "standard" method ... I'm slightly leaning towards gettext for two reasons:
- standard
- the gtk-server uses gettext, so if the script is done by t12s that means there are *two* sets of strings to be translated.
Now, I'm not doing the translation so I'm not sure whether the last statement has any impact at all in the translation part. In anyway, I'll go with the method that you choose, but I'd rather we choose one or the other (not both).

EDIT: Package manager localisation is checked in.

EDIT: I wanted to click the quote button but pressed the Edit button and destroyed this original post. Managed to recover it but the formatting is all gone, so be it.

EDIT: Just want to say that I run some unscientific test with localised package manager, it is 2times slower and unlocalised one. Seems to be "bash" slowness - if I unset LC_MESSAGES then everything runs as fast as before (even with eval_gettext left intact)... have to find other ways to optimise it._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.Last edited by jamesbond on Sun 22 Dec 2013, 13:50; edited 2 times in total

I am trying to configure Linux kernel to prevent certain kinds of attacks using sysctl command, but I got some errors

Code:

sysctl -w kernel.sysrq = 0

error: "kernel.sysrq" is an unknown key

Code:

sysctl -w kernel.exec-shield=1

error: "kernel.exec-shield" is an unknown key

Code:

sysctl -w net.ipv4.tcp_syncookies = 1

error: "net.ipv4.tcp_syncookies" is an unknown key

Code:

sysctl -w net.ipv4.proxy_arp=1

"net.ipv4.proxy_arp" is an unknown key

Probably the settings can't be set because those functions were not enabled in FatDog64 kernel.
Is there any script available to compile and update a FatDog64 kernel? If this is not possible could be these functions enabled for the next FatDog64 distro?
Anyway the possibility to compile and replace the kernel for this distro would be great. If anyone knows a good tutorial for doing this it would be a great help.
Thank you!

net.ipv4.proxy_arp --> working here if you change it to net.ipv4.conf.all.proxy_arp

Quote:

Anyway the possibility to compile and replace the kernel for this distro would be great. If anyone knows a good tutorial for doing this it would be a great help.

We do that all the time, but short on the time to write anything. Basically Fatdog's kernel stuff are stored in two places: vmlinuz, and kernel-modules.sfs. The latter contains all kernel modules, and it is located inside initrd. Here is a simplified example, in short a short 13 steps
1. Load one of Fatdog's kernel-source sfs. # this saves your from getting a vanilla kernel and patching it
2. cd /usr/src/linux-xxxx (xxx=latest kernel version from the sfs)
3. make oldconfig
4. make menuconfig # and make your changes
5. make bzImage modules
6. cp arch/x86/boot/bzImage /path/to/fatdog/vmlinuz # this is the kernel, copy it to your fatdog installation
7. make modules_install INSTALL_MOD_PATH=modules
8. cp -a /lib/firmware modules/lib # this copies existing firmware, add more as needed
9. mksquashfs modules kernel-modules.sfs -comp xz -Xbcj x86 -noappend # this creates the kernel-modules.sfs
10. filemnt /path/to/your/initrd # rox window will open with contents of initrd
11. # copy the new kernel-modules.sfs to that rox window
12. # click "repack-initrd" from rox window to rebuild initrd
13. Done._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

net.ipv4.proxy_arp --> working here if you change it to net.ipv4.conf.all.proxy_arp

Quote:

Anyway the possibility to compile and replace the kernel for this distro would be great. If anyone knows a good tutorial for doing this it would be a great help.

We do that all the time, but short on the time to write anything. Basically Fatdog's kernel stuff are stored in two places: vmlinuz, and kernel-modules.sfs. The latter contains all kernel modules, and it is located inside initrd. Here is a simplified example, in short a short 13 steps
1. Load one of Fatdog's kernel-source sfs. # this saves your from getting a vanilla kernel and patching it
2. cd /usr/src/linux-xxxx (xxx=latest kernel version from the sfs)
3. make oldconfig
4. make menuconfig # and make your changes
5. make bzImage modules
6. cp arch/x86/boot/bzImage /path/to/fatdog/vmlinuz # this is the kernel, copy it to your fatdog installation
7. make modules_install INSTALL_MOD_PATH=modules
8. cp -a /lib/firmware modules/lib # this copies existing firmware, add more as needed
9. mksquashfs modules kernel-modules.sfs -comp xz -Xbcj x86 -noappend # this creates the kernel-modules.sfs
10. filemnt /path/to/your/initrd # rox window will open with contents of initrd
11. # copy the new kernel-modules.sfs to that rox window
12. # click "repack-initrd" from rox window to rebuild initrd
13. Done.

Kernel Exec Shield was created with the aim of reducing the risk of worm or other automated remote attacks on Linux systems
http://en.wikipedia.org/wiki/Exec_Shield.
So, using your great tutorial I want to enable it in FatDog64 kernel. Maybe for the next kernel in RC2 it would be integrated by default.

Quote:

net.ipv4.tcp_syncookies --> working here

Tried again but the same result
error: "net.ipv4.tcp_syncookies" is an unknown key
Are you using the same kernel from FatDog64 RC1? Maybe you use a new version of kernel.
Since it helps to prevent syn flood attacks it would be great to can be enabled via sysctl. I will try to identify the setting that enables it in make menuconfig and put it in the new kernel.

Quote:

net.ipv4.proxy_arp --> working here if you change it to net.ipv4.conf.all.proxy_arp

I will do that, I suppose it should have the same results.
Regarding compiling a new kernel I woud like also to patch the kernel with grsecurity http://en.wikibooks.org/wiki/Grsecurity.
For this i will download a vanilla kernel and apply the patch but I should also apply FatDog64 specific patches, using unofficial Fatdog64 kernel build instructions. Do you think that Grsecurity will work for FatDog64?

Kernel Exec Shield was created with the aim of reducing the risk of worm or other automated remote attacks on Linux systems
http://en.wikipedia.org/wiki/Exec_Shield.
So, using your great tutorial I want to enable it in FatDog64 kernel. Maybe for the next kernel in RC2 it would be integrated by default.

Ah, I see. ExecShield seems to be very old, the latest patches were from 2006 and for early kernel 2.6 series.

Quote:

Quote:

net.ipv4.tcp_syncookies --> working here

Tried again but the same result
error: "net.ipv4.tcp_syncookies" is an unknown key
Are you using the same kernel from FatDog64 RC1? Maybe you use a new version of kernel.

I do use a newer version of the kernel (I always run the latest Fatdog version - to test it beforehand and make sure that we don't release a dud) but I don't think it makes a difference, Fatdog's kernel configs only vary slighly between versions.

Quote:

Since it helps to prevent syn flood attacks t would be great to can be enabled via sysctl. I will try to identify the setting that enables it in make menuconfig and put it in the new kernel.

The setting is CONFIG_SYN_COOKIES, you can check whether it is supported by typing this: "zcat /proc/config.gz | grep SYN_COOKIES", if you see something it has already been enabled.

Quote:

Quote:

net.ipv4.proxy_arp --> working here if you change it to net.ipv4.conf.all.proxy_arp

I will do that, I suppose it should have the same results.

It is in fact the same thing. The kernel changes its configuration space overtime. I don't know where you get your security recommendations but they seem to be very old. Btw - enabling proxy_arp has nothing to do with security, it has everything to do with network bridging. Do you know what you're doing?

For this i will download a vanilla kernel and apply the patch but I should also apply FatDog64 specific patches, using unofficial Fatdog64 kernel build instructions. Do you think that Grsecurity will work for FatDog64?

Fatdog's kernel is basically vanilla + aufs patches. Nothing else (well, sometimes we do backports patches for newer kernels, but most of the time don't). You can try applying grsecurity patches to Fatdog's kernel directly. Only if they don't work then you can try vanilla. In anycase, good luck._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

What I am trying to do is to harden FatDog64 in order to run server applications on it. Having a server that starts as a frugal install is assuring that is not compromised. Hardening the host with a good firewall and other good security measures keep this server safe for a sufficient amount of time (ex: a few days), this period of time being enough for some projects where a server must start and run securely.

I found a project about hardening linux on http://wiki.securix.org/doku.php and http://www.securix.org and I'm trying to implement some of them in FatDog64. From what you said me some of them are deprecated.
I'm a novice in linux so it will be difficult but I hope to have some results.

Anyway the idea of hardening FatDog64 for running server applications seems ok to me because we have hundreds of puppy distros but none of them can't be used for this.
Maybe an experimented user can think about starting a project for having a hardened puppy distro, focused on security not on desktop applications.
I choose FatDog64 because is multiuser and server applications can be run as spot user, this being a great advantage.

If you have some other ideas that can satisfy these needs I will be glad to try them.

My recommendation is to run the server virtualised. Fatdog offers many choices here.
1. VirtualBox -
2. Qemu/KVM - same as virtualbox, probably a bit faster but no GUI (shinobar used to create one long time ago, not sure whether it is still working)
3. UML - you asked for this before, did it or did it not work for you?
4. New in rc1 is LXC support (sandbox-lxc). rc2 will offer LXC with user namespaces.

My recommendation is to run the server virtualised. Fatdog offers many choices here.
1. VirtualBox -
2. Qemu/KVM - same as virtualbox, probably a bit faster but no GUI (shinobar used to create one long time ago, not sure whether it is still working)
3. UML - you asked for this before, did it or did it not work for you?
4. New in rc1 is LXC support (sandbox-lxc). rc2 will offer LXC with user namespaces.

cheers!

I have UML working already. I coudn't start spot as default user in UML, always it starts as root. In my understanding having one server application running as root being compromised will compromise other applications fro VM also. Anyway a restart of the VM will eliminate the problem.

I'm not afraid about infecting the host distribution because I always will use in RAM mode with Puppy. I just want to secure the distro as much as I can against internet attacks. I will never use browser, or even X and I will start the distro as spot with nox. But I want to be sure that I have as much security as I can.

I applied already grsecurity patch FatDog64 sources with success and I'm trying to get a new kernel (version 3.11.4).

I have UML working already. I coudn't start spot as default user in UML, always it starts as root.

Ah yes, you need to customise the application startup script (ie automatically su to non-root when the app starts). You can tell start-uml.sh to run a script when UML starts up (using START_CMD) and this script can drop down to non-root and do other stuff as needed.

Quote:

In my understanding having one server application running as root being compromised will compromise other applications fro VM also.

True, the trick is to run exactly ONE app in ONE VM.

Quote:

I will start the distro as spot with nox.

Don't use spot. spot is root's surrogate. Create a new user (mkuser.sh or from the user manager) and use it instead.

Quote:

I applied already grsecurity patch FatDog64 sources with success and I'm trying to get a new kernel (version 3.11.4).

...This sounds good. Where does these t12s tools are, I suppose they are not part of momanager? I can put them into devx if you like.

They are part of momanager.

Quote:

I have one more question - the POT file created by t12s, is it compatible with POT file created by the real msgformat? (I guess not ...)

msgid and msgstr are compatible, header and comments differ.

Quote:

...Speed-wise I think t12s is faster, but gettext is the "standard" method ... I'm slightly leaning towards gettext for two reasons:
- standard
- the gtk-server uses gettext, so if the script is done by t12s that means there are *two* sets of strings to be translated.
Now, I'm not doing the translation so I'm not sure whether the last statement has any impact at all in the translation part. In anyway, I'll go with the method that you choose,

but I'd rather we choose one or the other (not both).[/quote]
Because of "not both" it is a fast decision: gettext only because of gtk-server
Exception: jwm_create is sort of t12s (it is the ancestor)
BTW, puppy's fixmenus fixes menus
your replacement fixes jwm menu only....

Quote:

EDIT: Just want to say that I run some unscientific test with localised package manager, it is 2times slower and unlocalised one. Seems to be "bash" slowness - if I unset LC_MESSAGES then everything runs as fast as before (even with eval_gettext left intact)... have to find other ways to optimise it.

I have found a "test bed"

Code:

### show main window and enter main loop
gtk gtk_widget_show $MAIN_WINDOW
[b]time[/b] populate_all_pkg
populate_installed_pkg
while true; do

Maybe forget LC_MESSAGES at all
and use just
LANG=C
and
read LANG < $HOME/.fatdog/language

Using LC_MESSAGES is a little bit faster than using LANG.
15.7 sec vs. 17.1 sec on my box
only ()
It is not worth to deviate from common use in puppy: LANG only (no LC_MESSAGES)

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum