SAMI package management

edited October 13 in KLayout Support

Hi @Matthias ,

It seems on sami.klayout.org it's not possible anymore to set the package name, is that intentional?

I remember before it was possible?

This has caused http://sami.klayout.org/preview?url=git+https://github.com/gdsfactory/metainfo-ports.git+klayout[v0.1.0] to get this really ugly name (because it uses some of the folder structure as the name) :neutral:

Best,
Sebastian

P.S. Also I have noticed I am getting regular 500 on sami.klayout.org (even in KLayout), is there a failover, or is the server currently just getting hammered and therefore crashes?

Comments

  • Hi Sebastian,

    yes, there are attacks, I assume, and they seem to intensify. The 500 is not generated by my application - they seem to come from some proxy or firewall around my virtual server instance. Specifically access from Asia appears to suffer from issues there. I'm sorry for the inconvenience, but I don't see traces of these events in my logs, so I cannot debug that. I can try to reboot the server and complain to my hoster, but I have some doubts this will be a sustainable solution.

    After all, there are wars going on. I think we should be happy it's only 500 and not a bombshell or some killer drone dropping on our heads.

    Regarding the name: there never was a field to edit the name. The name is taken from the "name" tag in the grain.xml file. Like "xsection" here:

    <?xml version="1.0" encoding="utf-8"?>
    <salt-grain>
     <name>xsection</name>
    ...
    </salt-grain>
    

    You only have to supply the project URL.

    Best regards,

    Matthias

  • Ah, I see, thanks. I think I set the name this weird at some point because SVN required it at some point to resolve the subfolder path. But yeah, I'll happily change that :P.

    Regarding the server:

    If you are interested, there are possibilities to make it more resilient through e.g. CDNs (cloudflare for example offers free DoS protection through their CDN, but I am not intimately familiar with how it works, but I'd be happy to look into it if you would like).

    Something that also to consider is basically protecting the backend/apache by configuring a firewall tool such as fail2ban (e.g. ban an IP for 10min from connecting on 80/443 if more than 100 connections are made within 10 seconds or similar).

    All up to you. I have done such work before mostly for my own things, but I'd be happy to look into any of it if you would like me to. But all up to you, I can live with the occasional 500 ;). It was the apache that was throwing the 500, but usually that just means the backend is either rejecting the connection or just not available.

  • edited October 16

    I am not sure if the problem is on my server itself, or whether it is a load balancing problem on my hoster side. I am using a virtual instance and maybe it is sharing CPU time with someone malicious or a parallel instance is being under attack. The application itself is trivial (MySql, Rails) and reponse times are typically in the range of 200ms and logs are pretty clean. No traces of issues inside the application. Rebooting or restarting the server helps for a while.

    I am in touch with them my hoster's technical staff. Maybe they can help, but I am not optimistic about that.

    Matthias

Sign In or Register to comment.