Jump to content
Read the Funtoo Newsletter: Summer 2023 ×

sputnik

Members
  • Posts

    122
  • Joined

  • Last visited

  • Days Won

    9

Posts posted by sputnik

  1. Well, it's a weird one.  For a month or so I haven't been able to access any funtoo.org ip's, either from browser or ping, whatever.  I was busy with other things and worked out pretty quickly that it was localized on my everyday user laptop and discovered it was related to iptables, by stopping them I could access funtoo.org just fine, so I just lived with that for awhile.

    Today I got serious about it and started removing lines from iptables one by one to find it.  Luckily it was line 2 in INPUT, deleted that and funtoo.org is accessible.  here is what it says:

    Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    num   pkts bytes target     prot opt in     out     source               destination
    2     195M  201G IP4BOGONS  all  --  !lo    *       0.0.0.0/0            0.0.0.0/0
    

    Which goes to:

    Chain IP4BOGONS (1 references)
     pkts bytes target     prot opt in     out     source               destination         
     883K  102M RETURN     all  --  *      *       10.0.0.0/8           0.0.0.0/0           
       18  1008 RETURN     all  --  *      *       172.16.0.0/12        0.0.0.0/0           
    55910   25M RETURN     all  --  *      *       192.168.0.0/16       0.0.0.0/0           
     109K   25M DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set fullbogons-ipv4 src
    

    I have a cronjob that downloads a list several times a day from http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt and adds them to an ipset list.  It's a list of known "bogons", bogus ip addresses that are being used for...who knows, nothing good for me.  As you can see anything that matches that list doesn't get in the door.

    So my next step was:

    ipset list fullbogons-ipv4|grep "172.97.103.36"
    

    Nope, no match.  Then I went to http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt and looked for 172.97.103.36 there.  Nope, ain't there either.  But still, for some reason it's apparently matching something somewhere on that list.  I can't explain it, but there it is.  Zero problems with any other ip's.  I've solved this for now by putting in a RETURN above the drop for 172.97.103.36, but I wanted to make the devs aware of it.  I've been using this iptables setup for a couple of years, this is the 1st time anything like this has happened.  I see on the front page of the wiki that Drobbins has been migrating containers to that address, the timing matches this problem.

  2. There was a similar question in Gentoo a while back, the fellow was going to be on board a ship with no network for 6 months.  I can't find it now, but not important, j-g- has good ideas.  Especially if you have a similar computer at home <whereever> that is on the network, you can just hand carry the flash drive back & forth with the package files.  I have a machine here with all of portage on flash drive, an ancient computer with a tiny HD.  Portage doesn't care where it's DIR's are.  But if you have to chroot and use qemu then: Door #2, yes it will be a pain because it will take so long to build packages in qemu emulation mode.  If that were the case I would update portage to reflect the latest packages and take the DISTFILES to the remote machine, let it find them in $DISTFILES and build them itself.  Assuming your _home machine had the same packages installed, else you'd have to manually d/l them.  It certainly won't be painless, but you can minimize the pain.

  3.  

     

     
     
    Section "InputClass"
    Identifier "keyboard-all"
    Driver "eudev"
    Option "Xkbmodel "pc102"
    Option "XkbLayout" "latam"
    Option "XkbVariant" "basic"
    MatchIsKeyboard "on"
    EndSection

     

    Aren't you missing a quote?  Shouldn't Option "Xkbmodel "pc102" be Option "Xkbmodel" "pc102"?

  4. Yes, I agree with you.  I get lazy because android is so inherently insecure in so many ways, it seems almost hopeless.  I'll have to sniff that out & shut it off too.

    I always seek out those programs that are the least intrusive, but I find ES File Explorer too handy.  I used to use Xposed on my phone, but it was too wimpy (ancient), although I have a newer one now, only 4 years old  :P .  Maybe I'll go back to that.

  5. Hmm, I do the same with screen as you describe with byobu all the time.  Detach, relog in, screen -r, why there it is, still running away!  Even multiple sessions.  It cares not about the machine you are coming from, same user/same screens.

    But the more the merrier.  I notice great polarization with these types of programs, tmux users aren't fond of screen and vice-versa.  Whichever you like, that's the one for you!  I also use dtach on my embedded devices for things that run 24/7, a much smaller memory footprint, although limited to one session.

    +1 on JuiceSSH for android, love it.  ES File Explorer for android is also great, much better than any other file manager I've seen, including the one in Cyanogenmod, an FTP client too, so you don't need another client for that.  More cool stuff than I know what to do with.

    SSH Server on android works well for me too.  You can set it up to start in the background at boot, I have more ways to log into my androids than Uncle Sam...

  6. The only thing that grabs me is you don't want NetworkManager and dhcpcd both.  If you're using NetworkManager delete dhcpcd from rc.  Otherwise more or less what I have, don't know about the busybox stuff, did you add that?  I don't have it.  Here's mine:

    # rc-update
           NetworkManager |      default                 
                    acpid |      default                 
                alsasound | boot                         
                   autofs |      default                 
                bluetooth |      default                 
                 bootmisc | boot                         
                  chronyd |      default                 
               consolekit |      default                 
             cups-browsed |      default                 
                    cupsd |      default                 
                     dbus |      default                 
                    devfs |                       sysinit
            device-mapper | boot                         
                  distccd |      default                 
                    dmesg |                       sysinit
                    fcron |      default                 
                     fsck | boot                         
                     fuse |      default                 
                      gpm |      default                 
                  hddtemp |      default                 
                   hdparm |      default                 
                 hostname | boot                         
                  hwclock | boot                         
                ip6tables |      default                 
                    ipset |      default                 
                 iptables |      default                 
                  keymaps | boot                         
                killprocs |              shutdown        
        kmod-static-nodes |                       sysinit
               lm_sensors |      default                 
                    local |      default                 
               localmount | boot                         
                      lvm | boot                         
                  metalog |      default                 
            microcode_ctl | boot                         
                  modules | boot                         
                 mount-ro |              shutdown        
                     mtab | boot                         
                 netif.lo |                       sysinit
                 netmount |      default                 
                      nfs |      default                 
                 nfsmount |      default                 
           openvpn.client |      default                 
                  postfix |      default                 
                  preload |      default                 
                   procfs | boot                         
              qemu-binfmt |      default                 
                     root | boot                         
                    samba |      default                 
                savecache |              shutdown        
                     sshd |      default                 
                     swap | boot                         
                swapfiles | boot                         
                   sysctl | boot                         
                    sysfs |                       sysinit
             termencoding | boot                         
             tmpfiles.dev |                       sysinit
           tmpfiles.setup | boot                         
                     udev |                       sysinit
               udev-mount |                       sysinit
           udev-postmount | boot default                 
                  urandom | boot                         
                      xdm |      default
    
  7. That's going to be the place, xorg.conf.  Are you using fglrx?  If so, I believe they (like Nvidia) have quite a comprehensive manual that comes down with the driver.  And I don't mean man ati (or whatever), although that could be helpful too.  In there will be lots of reading pleasure for you, with many possible additions to xorg.conf to solve this problem or that.  

    I have nvidia, the manual is located in /usr/share/doc/nvidia-drivers-<version>.  I have access to an AMD machine, but it's offline currently, but that may be a good place to look (/usr/share/doc).  equery f ati-drivers will show it also.

    If you're using the open source drivers I don't know, but a quick web search should be helpful.

    Oh, and man xorg.conf may help too.

  8. I run xfs here and hibernate just fine.  I don't quite agree with threesixes about the fsck being immature, although I can understand how he gets that impression.  It has it's own checking program, xfs_repair, to just check without modifying you run xfs_repair -n <partition>.  But it's definitely less descriptive as to errors, or maybe they are just arcane to me.  I've been running xfs for about 3 years now and no serious issues, however, it is touchy about things like abrupt power failures.  But running the check facility immediately after seems to make them happy, again no issues here in 3 years.

    My last experience with btrfs was about that time, about 3 years ago, it was a wild adventure!  But I don't know where it's at today.  I think all of it really boils down to how fast do you need your disks to operate?  Are they being accessed alot with the way you use your machine or not?  Use huge files alot?  If none of that seems to be you then even ext4 will probably suit you just fine.

    Yes, lvm supports snapshots too and you are already running it.  And ZFS is quite popular around here, it has really outstanding snapshot capabilities.

    I believe the only thing you buy with pure64 setup is saving some disk space, but I've never seriously looked into it, as you say, skype and some others would be unhappy.  Same with the Python 3 idea, only more so, there are many, many programs still using Python 2.  There may be some headaches but I don't think you have a choice.

    That's a pretty speedy machine, you won't have any problem with virtualization, although you could certainly use more memory.  I'm using a core 2 duo laptop here with 4G and I run virtualbox just fine.  qemu is pretty slow though, hmm, I'll have to check that.

    Webkit & GTK are pretty intensive compiles but without more info we could only guess about that.  j-g- has good suggestions, especially since you have no swap.  You can of course, easily add swap without reinstalling.

  9. I use iptables and AFAIK that's the way to do it, really on any distro.  After all, you can immediately stop and start at will.  Manually starting like that will give you immediate feedback if something's wrong, i.e. it will verbally complain and just not start usually.  

    When testing new statements, just INSERT or APPEND them live, with iptables already running.  You'll get instant feedback.  After everything works you can do iptables-save to save the current rules in memory.  Conversely you can do iptables-restore to dump any new changes.  Yeah, but I dunno, sometimes it doesn't work all that logically, I like to back up the /var/lib/iptables/rules-save file just in case, I've got a lot of rules.  :P   Save and restore have messed me up more than once.

    The rules are written to /var/lib/iptables/rules-save, so if you are concerned about losing lots of previous work you can easily make copies of that file and replace it after changes.  Or you can manually test/back-out the changes one by one.  After you are happy with all rc-update add iptables default will auto-start the iptables on boot.

    I do know what you mean about the initial "hey, you gotta save some rules first" thing, frankly I forget how I got past that.  I guess you could just create /var/lib/iptables/rules-save with something like this in it:

     -A INPUT -s 192.168.0.0/24 -j ACCEPT
    

    (or whatever your subnet address is) and go from there, just delete that later if you don't want it.  Once you have some rules saved you won't see that again.

  10. I use this:

    $ cat screensaver_toggle
    
    #!/bin/bash
    
    #Mike Johnson
    #toggle the screensaver on/off
    #place icon in panel to indicate when off
    
    DPMS=$(xset -q|grep "DPMS is"|cut -d " " -f5)
      	
    	if [ $DPMS = "Enabled" ]; then
    	lxpanelctl exit && lxpanel -p screensaver_off &
    	xset -dpms
    	xset s off
    	S_STRING="         Screensaver Disabled"
    	DISPLAY_COLOR="red"
        else
    	lxpanelctl exit && lxpanel -p default &
    	xset dpms
    	xset s on
    	S_STRING="         Screensaver Enabled"
    	DISPLAY_COLOR="orange"
        fi
    # Clean up any running aosd_cat processes
    killall aosd_cat &> /dev/null
    # Display the desired text
    echo "$S_STRING" | aosd_cat -n "Georgia Italic 70" -u 1500 -o 300 -R $DISPLAY_COLOR -S black -f 300 -e 4 -p 3 -x 300
    

    Along with a couple of other files, it places an icon in my panel I can click to return to screensaver enabled mode and prints large letters across the screen telling me the status using x11-libs/libaosd.  But you don't need all that foo-foo, the xset statements do it all.  The s directive turns on/off the screensaver (display of screen), the dpms (energy-star) turns the backlight on & off.  I have it tied to a hotkey so I can control it all with a keystroke.

    The panel icon is a little more intricate, but if you want the large letters on the screen you just need to : USE="pango" emerge -av x11-libs/libaosd and use the above code (comment out the lxpanel lines).

  11. I have a Toshiba TE2000, it's a P4, 15 years old and keeps on ticking, even the CDROM!  I don't think you'll find this is much of an issue once you get over the initial install, it's not that horribly slow.

    I believe LXDE is a good choice, mine is openbox with  lxpanel, etc., I think LXDE IS openbox if I remember correctly.

    The biggest help you can give it is to use ccache and DISTCC - if you have other machines to help.  ccache irregardless of other machines.  Lots of info about those at the wikis and forums.

    swamprabbit's suggestion is excellent too.  There is also the tinderbox, the developer says it's not maintained anymore, but it seems to have recent activity: http://tinderbox.dev.gentoo.org/.  Binary compiles of many packages.  I've never used tinderbox, but I do use the binary browsers, they are a very time consuming compile.

    Also if you can spare a few bucks, mine was 1GB ram, I got 2GB on ebay for something like $12-13, new even.  That helped it alot.

    It's likely you have a tiny HD, if need be it's easy to put /usr/portage on a usb stick.  Or if you do have other machines you can just link to /usr/portage through NFS or samba, that's what I do here.

    Oh, 1 more thing you can do if you increase memory size.  You can run /var/tmp/portage as a ramdisk, should be much faster than storing intermediary compiled programs on disk, reading them back, etc. (although I must confess lately I'm not so sure).  To do this you make an entry like this in /etc/fstab:

    tmpfs			/var/tmp/portage tmpfs		size=2G         0 0
    

    Don't worry about the 2G, it's smart and only uses what's available for the ramdisk.

    However, a handful of packages cannot fit into such a small size and you will have to make exceptions for them thusly:

    cat /etc/portage/package.env
    
    app-office/libreoffice						notmpfs.conf
    app-text/poppler							notmpfs.conf
    
    cat /etc/portage/env/notmpfs.conf
    PORTAGE_TMPDIR="/var/tmp/notmpfs"
    

    Then portage will use a "real" temporary directory for those packages.  These are examples only, for example, you would almost surely want libreoffice-bin, the compiled version is the king of long compile times.  You'll find out what needs to be added to package.env when it says "out of disk space" when it fails ;)

  12. I really don't have a clue, like most package managers, there is bookkeeping stuff in /var/cache, but the easy way out may be to emerge -1 portage, since it's obviously out of kilter.  Worth a shot.  Oh and you might try revdep-rebuild, same philosophy.

    I have a Dockstar and a Pogoplug, I feel your pain.

  13. I'm just guessing here, but I think it is due to trying to make a "generic" initramfs.  Note that both 3.19 versions are working fine as you reported.  I build a new initramfs for each kernel, I think I tried that in the beginning and found out what you are having trouble with.  Also, there's this:

    boot # diff initramfs-funtoo-4.0.0 initramfs-funtoo-4.0.1
    Binary files initramfs-funtoo-4.0.0 and initramfs-funtoo-4.0.1 differ
    
    boot # ls -l init*
    -rw------- 1 root root 8367938 Apr 28 18:58 initramfs-funtoo-4.0.0
    -rw------- 1 root root 8366709 Apr 30 05:25 initramfs-funtoo-4.0.1
    
    
     

    My initramfs' in the boot dir.  Yet they were made in exactly the same way, no changes to dracut.conf, only the kernel referred to dracut changed.  I believe there is more of a difference than just a "0" changed to a "1".  Anyhow, easy to check.

  14. Hmm, well you've got me there then.  I specify the kernel line as I suggested and I'm running 4.0.1 just fine.

    Of course, the best way to not have those "crufty *.olds" not show up is to delete them before running boot-update, solves the problem and keeps things clean, but that's up to you.

    So it seems something is different about your 4.0.1, I agree, man boot.conf says you should be able to do it that way.

  15. Life is too short for ugly desktops!

    I'm with you Duncan, and I really love that cityscape you have in the desktops thread.

    1st, I don't know of that which you ask.  Although I'm sure there is an easy way to find the predominant color in your picture in Gimp or something I don't know that either.  But it seems to me you can probably come close with just your eyeballs.

    I imagine you have looked over Gnome Look and those sorts of collections for themes.

    I use Emerald rather than GTK and it has the Emerald Theme Manager that allows you to set the colors, for one thing (many other options too).  Although it appears to me that Emerald is a (now) forgotten step-child of GTK I'm not aware of any such thing for GTK.  So I just find an Emerald theme at Gnome Look that's close enough then modify it.

    Your question peaked my interest and I did find something that may be interesting though:

    http://gnomecc.sourceforge.net/

    Sounds like it may do what you want, sans the color picker.  Much like the Emerald Theme Manager.

    I hope someone else can chime in with some better ideas.

     

    Edit: This will find your predominant color

  16. The startup script thing is easy.  In /etc/local.d I believe there is a little doc explaining, but you simply create a file called /etc/local.d/<whatever>.start.  It's executed on startup as privileged user (chmod 744 <whatever>.start as root).  Just put your echo instruction in there, it'll happen at every boot.  Hmm, maybe have to make it a bash script, mine is but not sure that's necessary.  Well, you can just paste this in, no need to understand code  ;)

    #!/bin/bash
    echo 1 > /sys/block/sda/device/queue_depth
    
  17. Hmm, kinda late, but I just wanted to point out that I did have the problem in hibernate mode and it's definitely hibernation, powered off.  And yeah, the restart in the 77ethernet file does the trick.  So I guess that code executes for suspend and hibernation?  Hope I'm not misleading people here, it was ages ago I hunted that down.

  18. Sorry guys, been busy, haven't been watching this.

    @Sandro: Not sure what you are showing, can you give more info?  It looks like you are trying to do something with the plugins and fusion icon.  They are not applicable at all to compiz anymore, only the old 0.8.8 which isn't even in the tree anymore.  In fact, if you do eix compiz, virtually everything listed is utterly useless except for compiz itself.  The configs, plugins, fusion, no longer used, all built into the one compiz package now.  I hope that helps.  Oleg said he fixed the problem you were having, so compiz should emerge fine now.  I'll watch here now though, in case you have a problem.

    @threesixes: Well, same thing, I'm not quite sure what you mean by "icon method", unless you mean the old fusion icon.  That was literally a bandaid because compiz 0.8.8 would crash, so they made that icon so that you could easily restart it.  Hey, you can't make this stuff up, I ain't kiddin'.  Compiz is my desktop manager here, two years, no crashes!  So you see, not needed.

    If you mean you want to use it "occasionally" or something, easy enough.  You start compiz at the command line (well, I do it in .xinitrc):

    compiz --replace
    

    And NOTHING else, in spite of old info you may see on the web, no longer true.  So easy enough I think to make a little icon if that's what you want, maybe write the code to toggle between it and some other decorator?

  19. Well that seems to be the magic.  Just cleaned out my hosts file, commented out all those aliases in /etc/conf.d/hostname, reboot, and perfect.  Indeed those warnings in the host were leftover from before, not there on this write.

    Hopefully we'll get a new bug feature to keep us entertained soon.

    Once again you've helped me so I didn't have to use my brain.  Thank you.

  20. That is interesting gnuisance.  Sounds like we go back to the old methods?  Perhaps I missed that last time I did dispatch-conf.

    It's still duping like crazy here, so I'm gonna try that.

    And yet it still says this in /etc/hosts:

    #
    # DO NOT EDIT THIS FILE BY HAND; YOUR CHANGES WILL BE OVERWRITTEN
    #
    # Define alias-to-address mappings in /etc/conf.d/hostname
     
    Maybe left over from before
×
×
  • Create New...